[fedora-arm] U-Boot?

Jon Masters jcm at redhat.com
Thu Oct 13 21:32:54 UTC 2011


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.




More information about the arm mailing list