El jue, 13-10-2011 a las 23:56 +0200, Henrik Nordström escribió: > tor 2011-10-13 klockan 17:32 -0400 skrev Jon Masters: > > > The question is not about supporting "u-boot", it's about supporting > > "u-boot build for board X". So the package (if indeed it is a package) > > would be for MLO (x-loader) and u-boot for a specific e.g. TI board > > because the image has to contain the bootloader. Really, I would rather > > we find a way to compose images for boards without getting into the > > u-boot business at all. Hopefully, we can just pull in some plumbing > > gunk into our image compose and tried it like prebuilt firmware. > > By default Fedora policy we can't distribute boot firmware blobs built > by others. It may be possible to get an exception for this, but do not > feel right. > > What we can provide is scripts which enables the user to pull the image > together from the needed pieces (even downloading them as needed). > > > > Should Fedora for ARM officially support for some well known boards? > > > > Thanks for asking it. I thought we'd already pretty much decided to > > "support" TrimSlice and PandaBoard/BeagleBoard for example. > > Agreed. > > GuruBox, OpenRD etc should probably be in the list as well, if there is > contributors willing to provide the needed details. > > > I think we should provide a bootloader, but not firmware. Once the two > > are (correctly) separated, this will be awesome. Until then, we can > > provide a pre-built u-boot for specific boards by pulling it in as > > "firmware". I really don't see the difference between this and pulling > > in WiFi firmware that is Open Source (but not recompiled). > > There is a very big difference in which CPU executes the firmware. See > the debate around qemu & system firmwares which have left Fedora qemu > without support for several targets at the moment even with all the > firmwares completely open source. In most cases simply because Fedora > lacks the needed cross-compilers for compiling the target system > firmware. completely different issue we dont support sparc and ppc because the qemu system implementations do not work correctly and don't emulate hardware actually supported by fedora. anyway its been discussed to death already. Dennis _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
