On Thu, 2011-10-13 at 21:22 +0200, Henrik Nordström wrote: > Been a rather intense discussion regarding U-Boot on IRC today, and time > for some reflections and a little decision to be taken. Well, maybe ;) > In stage3 we do have an u-boot package which provides uboot images for > pandaboard, trimslice, beagleboard and some more. The pandaboard > requires u-boot on the boot media, while on trimslice the vendor > provided u-boot is in reality quite sufficient and stored separately in > a nor flash chip. > > Several (myself included) thinks it would be good if Fedora fully > supported some boards, with both kernel & up to date bootloader > (u-boot). But u-boot is not a fedora package today and will require both > willing maintainers and package review to happen. 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. I don't want us to be in the business of shipping what should be in the firmware just because on some current generation systems we don't really have an alternative. In the future, many systems will boot using UEFI and not have U-Boot, even in the embedded case (this is a *good* thing - U-Boot is lovely and we all have fond memories, but it is a moving target with a million different forks), and we will use GRUB2. That will be a joyous day, but until then, we just need an interim hack solution. > 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. > Do you think Fedora should provide the bootloader for well known boards > where the required board support is merged mainline? 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). Hopefully we can work with Dennis and others to find a solution that will let us pull in bits during image composes. Perhaps we have a misc. bits package containing pre-built binary u-boot bits for various boards, all appropriately named. We should not have a "u-boot" package. > Do you know anyone who would be willing to help maintain u-boot within > Fedora? I would be willing to help maintain specific board support, not a general u-boot. I would be quite against us shipping "u-boot" :) > Should u-boot images then also be provided for boards without a trivial > recovery mechanism in case an u-boot update fails? Where there is a risk > of creating bricks if the user do not have jtag access to their board. Like I said, I don't think we should be in the business of providing u-boot at all, other than where it is necessary. Otherwise users will think we're going to upgrade the NAND on their perfectly working board to give them a newer u-boot we don't need to give them, and all because there happens to be a newer version available. > Note: Supporting u-boot on boards without mainline u-boot support is not > an option. Again, I don't think we should be in the business of shipping firmware. We should ship some u-boot (or whatever - might be a different firmware) bits for specific targets, preferably pre-built and treated as firmware. I don't really care if it's upstream or not, I care about supporting specific targets if that is what we want to do :) Thanks, Jon. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
