[U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/05/2013 02:11 PM, Dennis Gilmore wrote:
> On Mon, 5 Aug 2013 15:01:32 -0400
> Tom Rini <trini@ti.com> wrote:
> 
>> On Sat, Aug 03, 2013 at 02:11:04AM -0500, Dennis Gilmore wrote:
>>
>>> Hi all,
>>>
>>> I wanted to start a discussion on defining a unified feature set
>>> that makes it simpler for the different distros to support ARM
>>> systems using u-boot. I have based a lot of my thoughts on how
>>> calxeda ship their systems configured as it works fairly well,
>>> recently i sent in a patch implementing most of what I would like
>>> to see for the wandboard[1]
>>>
>>> right or wrong we want things to be simple for the user and to
>>> largely look like a linux system on x86 would. The user and distro
>>> should never need to worry about memory locations 
>>
>> OK.  But lets remember up front that this is because in x86 land we've
>> got a quite long standing fixed memory map.
>
> yes, but omap, tegra, imx etc all know that they need to start at some
> address 0x0000800, 0x10008000, 0x4000000 etc so the starting point is
> known per soc.

If you can require a recent U-Boot, and place requirements on any U-Boot
that you will support, then you can simply say "${kernel_addr_r}"
instead of writing code to detect which SoC is in use, and manually
coming up with the correct value to use. This is *the* reason I switched
Tegra's default environment over to using the standard kernel_addr_r
variable, so that Tegra boards worked the same as other standardized
boards, and boot scripts could make assumptions re: the existence of the
kernel_addr_r variable, and "just work" the same everywhere.

Similar arguments apply to many other things, such as board name,
calculating DTB filename, etc.

I took a quick look at Fedora's arm-boot-config package. It seems like
it's approach is to detect which U-Boot is present, then create a
boot.scr that will work with it. This script will be different on
different boards due to the differences in U-Boot features etc. The
approach I was assuming was that for distros to support a board, you'd
need a recent upstream U-Boot with certain features enabled (this is
going to be true even if we all go enable PXE support...), hence the
same boot.scr could be used anywhere, hence most of a-b-c could be
radically simplified down to a single code-path. Then, I think the only
thing missing would be some interactive menu stuff to choose which
kernel to boot.

But, if the PXE support provides the interactive menu and solves the
other board-specific issues, then perhaps that's a reasonable approach too.