On Thu, Feb 28, 2013 at 6:51 PM, Lennart Sorensen <[email protected]> wrote:
> Using a kernel as essentially a bootloader to me is the opposite of > your goal of making the lines of code less for your startup process. > You have made it huge by using a linux kernel for what should be a simple > boot loader problem. u-boot began as a mind-f**k merge of parts of uclibc (or equivalent), some userspace code and the linux kernel. the problem lennart is that in order to do enough "bring-up" to do the kinds of tasks that you're expecting to do - such as initialise a screen, a usb, a serial, an sd/mmc, a this, a that - you actually need to do *exactly* the same job that the linux kernel already does. [except that there happens to be in some devices some additional low-level initialisation such as "bring up the DDR3 RAM interface and tell it to switch on and to use 8 banks of 4 @ a clock rate of 400mhz" and so on, but those kinds of things aren't that hard to add to the linux kernel early initialisation phase...] the *specific* problem that u-boot has, as has been illustrated by the builds of u-boot distributed by default with the OpenRD Ultimate, is that the people who "just grab a version of u-boot, any version of u-boot", fail to provide the features which people expect to have, such as "recognise the SD/MMC card properly" or in the case of OpenRD Ultimate, "fail to recognise the eSATA interface properly". yet, once booted, the linux kernel that is on them *does* properly recognise the SD/MMC card and the eSATA interface. so there is version discrepancy... because the maintainers of u-boot fail to keep up-to-date their cut/pasted versions of the linux kernel drivers that access specific hardware. using kexec actually allows you to write a boot-up application in userspace, and test it in userspace. l. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/capweedwlghoerid4s2nbphckgkrp83a1hz12ucwizpof_un...@mail.gmail.com
