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.