[U-Boot-Users] Support for softcore ethernet chips
Hi,
I have a board which uses a softcore ethernet chip, so before for example U-Boot is able to do networking some binary firmware has to be loaded into the device.
What's the preferred method to do this? I didn't find other boards in the U-Boot code but maybe missed something.
Seen from a technical point of view it would be the best solution to just link the firmware somewhere into the U-Boot image, but I would be interested how this is generally seen wrt. GPL issues. I don't think that this creates a derivative work, taken that it is just being bit-banged into the hardware by some GPL code, which is not different from what the Linux firmware interface does, but anyway. It has to be located somehow, and spending another flash sector just for some 40KiB would be uggly.
Robert
Hello Robert,
in message 20051115183458.GX1099@pengutronix.de you wrote:
I have a board which uses a softcore ethernet chip, so before for example U-Boot is able to do networking some binary firmware has to be loaded into the device.
What's the preferred method to do this? I didn't find other boards in the U-Boot code but maybe missed something.
See for example the FPGA support code which does something similar - load some images into a FPGA.
Seen from a technical point of view it would be the best solution to just link the firmware somewhere into the U-Boot image, but I would be
I'm not sure if this is really the best solution; it may be a good thing to have the firmware image separated and be able to replace it without needing to replace U-boot.
interested how this is generally seen wrt. GPL issues. I don't think
My opinion is that linking is linking, and code is code. But I am not a lawyer (Thank goodness!). There are nearly twenty boards which include some binary firmware images (search for "fpgadata.c" files), but in my (limited( understanding this is just a hardware description, not code. Now "binary firmware" may be something different. It sounds very much like code to me.
Which license is used for this firmware?
that this creates a derivative work, taken that it is just being bit-banged into the hardware by some GPL code, which is not different
Unless somebody with a better understanding of the legal aspects ex- plains to me that I'm wrong (and why), then I will not complain about hardware definitions like FPGA images; but code (even for a different CPU) should be GPLed.
Just providing a loader that loads the image from some external storage is IMHO the better approach anyway.
from what the Linux firmware interface does, but anyway. It has to be located somehow, and spending another flash sector just for some 40KiB would be uggly.
This depends on your sector size ;-) Also, you can locate the image in one of your file system images und use U-Boot to laod it - we have support for FAT/VFAT, ext2, JFFS2, cramfs, and reiser - you should find something that matches your setup.
Best regards,
Wolfgang Denk
On Tue, Nov 15, 2005 at 10:12:17PM +0100, Wolfgang Denk wrote:
See for example the FPGA support code which does something similar - load some images into a FPGA.
Ah, ok.
I'm not sure if this is really the best solution; it may be a good thing to have the firmware image separated and be able to replace it without needing to replace U-boot.
Generally yes, but in this case replace most probably means that you need to get a replacement, which would be difficult without a working network card, taken that we won't fall back to the stonage where we morsed firmware images over a serial line ;)
My opinion is that linking is linking, and code is code. But I am not a lawyer (Thank goodness!). There are nearly twenty boards which include some binary firmware images (search for "fpgadata.c" files), but in my (limited( understanding this is just a hardware description, not code. Now "binary firmware" may be something different. It sounds very much like code to me.
Well, it is some kind of generic communication hardware engine; not really microcode, not really vhdl. Something inbetween and very, very weird. I've no idea what exactly, but you can make it behave like ethernet, like CAN, profinet, interbus, sercos or whatever...
Which license is used for this firmware?
For the ethernet firmware: free beer. I suppose it's the only one relevant for U-Boot, because when Linux is running the rest can be separated in a clean way using the firmware interface.
Unless somebody with a better understanding of the legal aspects ex- plains to me that I'm wrong (and why), then I will not complain about hardware definitions like FPGA images; but code (even for a different CPU) should be GPLed.
Just providing a loader that loads the image from some external storage is IMHO the better approach anyway.
Ok, that's also my understanding. Let's see it like a hardware device where the developers forgot to make the functionality persistent ;)
This depends on your sector size ;-) Also, you can locate the image in one of your file system images und use U-Boot to laod it - we have support for FAT/VFAT, ext2, JFFS2, cramfs, and reiser - you should find something that matches your setup.
Seen from a functionality point of view I would like to load it from jffs2, but if you have crashed your flash image you would not be able to load a new one via ethernet. The firmware works; so I see no reason to exchange it later, or at least no reason which wouldn't also justify exchanging the U-Boot image as well.
Thanks, Robert
participants (2)
-
Robert Schwebel -
Wolfgang Denk