Post deleted by Toxic[Q]

[Satori]

Ik ben aan het pogen de gnu gcc compiler op mijn pc aan de gang te maken. Ik heb daaarvoor inmiddels een goed werkende unix-shell omgeving, incl mbv cygwin gemaakt. (Alleen vi ontbrak, maar die had ik zelf nog liggen).

 

Ik moet dus nu in staat zijn de cross-compiler te installeren.

 

Mijn vraag heeft te maken met de powerpc versie.

Ik kan de volgende target opties kiezen:

 

powerpc-*-*

You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.

--------------------------------------------------------------------------------

powerpc-*-elf, powerpc-*-sysv4

PowerPC system in big endian mode, running System V.4.

--------------------------------------------------------------------------------

powerpc-*-linux-gnu*

You will need binutils 2.13.90.0.10 or newer for a working GCC.

--------------------------------------------------------------------------------

powerpc-*-netbsd*

PowerPC system in big endian mode running NetBSD. To build the documentation you will need Texinfo version 4.1 (NetBSD 1.5.1 included Texinfo version 3.12).

--------------------------------------------------------------------------------

powerpc-*-eabiaix

Embedded PowerPC system in big endian mode with -mcall-aix selected as the default.

--------------------------------------------------------------------------------

powerpc-*-eabisim

Embedded PowerPC system in big endian mode for use in running under the PSIM simulator.

--------------------------------------------------------------------------------

powerpc-*-eabi

Embedded PowerPC system in big endian mode.

--------------------------------------------------------------------------------

powerpcle-*-elf, powerpcle-*-sysv4

PowerPC system in little endian mode, running System V.4.

--------------------------------------------------------------------------------

powerpcle-*-eabisim

Embedded PowerPC system in little endian mode for use in running under the PSIM simulator.

--------------------------------------------------------------------------------

powerpcle-*-eabi

Embedded PowerPC system in little endian mode.

--------------------------------------------------------------------------------

powerpcle-*-winnt, powerpcle-*-pe

PowerPC system in little endian mode running Windows NT.

 

 

 

VRAAG:

Welk target systeem moet ik opgeven tbv de build van gcc ??

 

 

Groeten

Satori

 

[Ronaldd]

Citaat:

VRAAG:
Welk target systeem moet ik opgeven tbv de build van gcc ??

De cdk gebruikt als target 'powerpc-tuxbox-linux-gnu' dat kan je gebruiken als target voor de compiler.

Even een waarschuwing, het is niet makkelijk een native compiler te crosscompileren. Veel sucecss ermee.

Ronald

[Satori]

Ik lees inderdaad overal dat het niet makkelijk is. Een simpele native c-compiler voor de powerpc zou ook prettig zijn, maar die heb ik nog nergens kunnen vinden en dus ben ik met een alternatief begonnen.

Ik hou me echter aanbevolen voor een simple (ala turbo-c in dos mode bijv) powerpc compiler.

 

Groeten

Satori

 

[Ronaldd]

De makkelijkste methode is de Dreambox_Native_Development. van turnstok. Dit heeft wel als nadeel dat de gebouwde software niet gegarandeerd draait op een dreambox zonder deze environment ook niet als je de software compileerd met een prefix van bijf /hdd/local oid. Het heeft wel als voordeel dat je heel veel debian packages kan gebruiken zonder te hoeven compileren.

 

De beste methode (naar mijn idee) zou zijn een compiler en linker te maken die overweg kan met header en libraries in bijf /hdd/local ipv /usr/include en /lib. Ben daar al een paar dagen mee bezig om dat te maken, nog steeds zonder success.

 

Ronald

[Gast]

Citaat:

... Dit heeft wel als nadeel dat de gebouwde software niet gegarandeerd draait op een dreambox zonder deze environment ook niet als je de software compileerd met een prefix van bijf /hdd/local oid. Het heeft wel als voordeel dat je heel veel debian packages kan gebruiken zonder te hoeven compileren.

De beste methode (naar mijn idee) zou zijn een compiler en linker te maken die overweg kan met header en libraries in bijf /hdd/local ipv /usr/include en /lib. Ben daar al een paar dagen mee bezig om dat te maken, nog steeds zonder success.

Ik begrijp echt niet waarom dat allemaal nodig is. Als je Debian onder een chroot environment opstart ben je toch klaar?

[Gast]

Hi turnstok ,

 

Citaat:

- How do I read directly from the infrared port (not using rc0)?

 

Why do you want to do this? I had a look at dream.o to see how it works. Ofcourse this information should better come from dream.

 

The ir driver consists of two parts. First there is the low level driver. This one seems to use a general purpose timer (GPT) of the STB chip. It is probably programmed to go off at regular intervals. Irq 11 is used for the timer. This can be seen via cat /proc/interrupts. You can also see the interrupt count increment by cat-ing several times. It also increments without you sending IR signals which also indicates a timer mechanism. So it seems the IR driver is implemented as a polling driver triggered by timer IRQ? For the moment I have no idea how the actual IR signal is read. Maybe the IR hardware is somehow coupled with the timer via some pins on the STB chip. In that case the IR signal could be "read" by looking at the time between IRQ signals. Just guessing here...

 

The second part of the driver sits in between the lower level IR driver and the higher lever driver interfaces: /dev/rawir2 and /dev/dbox/rc0. It registers these 2 character devices and calls register_ir_decoder() on the lower level driver part.

 

I think it works like this: whenever bits come in from the IR hardware, these bits are passed from the lower level part of the driver to the higher level part. This higher level part transforms these bits into IR scan codes: the 16-bit values that are read from /dev/rawir2 and /dev/dbox/rc0.

 

So if you would really want to access the IR signal on a lower level you would have two options:

 

1) write a new higher level part driver that registers itself with register_ir_decoder() and registers its own device file for example /dev/my_ir_device.

 

2) write your own lower level part. This is the most difficult solution.

 

Needless to say this is not a trivial task. Source code from dream would come in handy.

 

Greetz

 

 

[Ronaldd]

Citaat:

Ik begrijp echt niet waarom dat allemaal nodig is. Als je Debian onder een chroot environment opstart ben je toch klaar?

Dat klopt dan ben je klaar zolang je alles maar laat draaien in chroot.

Ronald

[Gast]

@mcduff

 

Thanks for all the information. I feel a busy weekend coming up...

The reason I want to read it directly, is because I am thinking about ways to use the remote control as mouse device or/and 'sms'-based terminal. IMHO the current devices are not suited for this.

[Satori]

Ik heb inmiddels al veel geprobeerd en ook de genoemde procedure gevolgd die je noemt:

Citaat:

Dreambox_Native_Development

.

Maar deze werkt niet goed. Een aantal files die opgehaald moeten worden bestaan niet meer en we komen foutmeldingen over links die niet te maken zijn.

Daarnaast is me nog steeds niet duidelijk of er een werkende c-compiler ter beschikking komt.

Het concept van chroot om je eigen omgeving te creeren is me duidelijk en heb ik ook al met succes uitgeprobeerd.

 

Groeten

Satori

 

[Romeo_]

@Satori,

If the links cannot be created it could be because you are using a windows NFS share or because of bad rights.

[Satori]

@Romeo_

 

Thanks for your reponse. I'm using an NFS mount indeed. I wasn't aware of the consequences regarding links.

So back to my cross-compiler <img src="/ubbthreads/images/graemlins/smile.gif" alt="" /> .

 

Regards,

Satori

 

[Romeo_]

@Satori, use a real linux for your NFS mounts or just a harddisk in your dreambox.. works better for developing.

[Gast]

Hi all,

 

is there any documentation or software to boot via LAN and/or serial port from the BIOS? When in the BIOS the dreambox offers these boot methods besides the default "boot from flash".

 

What is the protocol used and what is the data that is exchanged (cramfs image?).

 

These methods are interesting to test new kernels (the "os" files) without having to flash your DB.

 

Greetz

[Gast]

@Turnstok,

 

Citaat:

- How do you build a new kernel? I have read your statement on kernel compilation (redwood5), but maybe you can help me a little bit further...

 

I'm waiting for this too. To be more precise, I'm waiting for the patches they applied. In fact you have the right to claim the patches or the whole source of the kernel, the "os" file, because the Linux kernel is GPL.

 

Any linux developer knows this. That's why the source you can not release (because of an NDA for example), is put into a seperate module. So in fact you can demand the source of the kernel but not the source of the dream.o module.

 

I would welcome a move from dream to release the source of the kernel or at least the kernel diffs and .config file as they promised. I don't care if it is not packaged very well or if it's difficult to compile. I have enough experience and knowdledge to do so. As I'm sure other people on this forum do as well.

 

Greetz

[Gast]

@myself and other potentially interested readers,

 

I should have experimented before asking the question about booting via serial and/or ethernet from BIOS.

 

If you try to boot with serial connection, the bootloader will tell you how to do it. The file to upload is the kernel "os" file, with the Kermit protocol. After this the kernel is started. This procedure is easily done with Windows HyperTerminal.

 

The transfer via ethernet works with BOOTP and TFTP. The BOOTP server must indicate the filename of the "os" file and the TFTP server must serve this file to the bootloader. I did not get this to work because all the BOOTP servers I tried failed on my Windows2000. Ok, back to Linux...

 

Greetz