[U-Boot] Two U-Boot versions on same device
Strange question but I am using an OMAP 3530 and the boot process currently is from TI's X-Loader to U-Boot to Linux.
What I want is to have two different versions of U-Boot, an extremely optimized and small one (to reduce boot time) but then also a debug version that has a built in device test suite and allows updating of the Linux kernel.
The optimized version would boot first and then check if a GPIO is set, if so then it would boot into the debug U-Boot to perform tests or software updates.
Anyone do anything like this or is it even possible?
Thanks.
El Fri, Mar 05, 2010 at 07:09:11AM -0500 Rishi Dhupar ha dit:
Strange question but I am using an OMAP 3530 and the boot process currently is from TI's X-Loader to U-Boot to Linux.
What I want is to have two different versions of U-Boot, an extremely optimized and small one (to reduce boot time) but then also a debug version that has a built in device test suite and allows updating of the Linux kernel.
The optimized version would boot first and then check if a GPIO is set, if so then it would boot into the debug U-Boot to perform tests or software updates.
Anyone do anything like this or is it even possible?
i think it should be possible, but i wonder if you really need this. do you have hard data that suggest that the test suite or allowing to update the linux slows down U-Boot significantly?
in my environment i use scripts stored in environment variables to update the kernel and the rootfs, afaik this doesn't add any overhead at all. the test suite you mentioned might be a different issue depending on its size, as it has to be copied from flash to RAM at boot time. if it's just adds a few kB i think it shouldn't be relevant, especially on your high-profile system
best regards
The size differences are substantial. 170 K for the regular uboot binary and about 1.1 MB for the uboot binary with diagnostic software.
On Fri, Mar 5, 2010 at 7:31 AM, Matthias Kaehlcke matthias@kaehlcke.netwrote:
El Fri, Mar 05, 2010 at 07:09:11AM -0500 Rishi Dhupar ha dit:
Strange question but I am using an OMAP 3530 and the boot process
currently
is from TI's X-Loader to U-Boot to Linux.
What I want is to have two different versions of U-Boot, an extremely optimized and small one (to reduce boot time) but then also a debug
version
that has a built in device test suite and allows updating of the Linux kernel.
The optimized version would boot first and then check if a GPIO is set,
if
so then it would boot into the debug U-Boot to perform tests or software updates.
Anyone do anything like this or is it even possible?
i think it should be possible, but i wonder if you really need this. do you have hard data that suggest that the test suite or allowing to update the linux slows down U-Boot significantly?
in my environment i use scripts stored in environment variables to update the kernel and the rootfs, afaik this doesn't add any overhead at all. the test suite you mentioned might be a different issue depending on its size, as it has to be copied from flash to RAM at boot time. if it's just adds a few kB i think it shouldn't be relevant, especially on your high-profile system
best regards
-- Matthias Kaehlcke Embedded Linux Developer Barcelona
There is no passion to be found playing small - in settlingfor a life that is less than the one you are capable of living (Nelson Mandela) .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
On Fri, Mar 5, 2010 at 1:14 PM, Rishi Dhupar rishid@gmail.com wrote:
The size differences are substantial. 170 K for the regular uboot binary and about 1.1 MB for the uboot binary with diagnostic software.
On Fri, Mar 5, 2010 at 7:31 AM, Matthias Kaehlcke matthias@kaehlcke.netwrote:
El Fri, Mar 05, 2010 at 07:09:11AM -0500 Rishi Dhupar ha dit:
Strange question but I am using an OMAP 3530 and the boot process
currently
is from TI's X-Loader to U-Boot to Linux.
two options: a) something called configuration header - which will allow you to boot from NAND kind of devices straight to SDRAM. b) try barebox.. I used to have something as small as 32k when it was called u-boot-v2.. Regards, Nishanth Menon
On 05/03/2010 12:09, Rishi Dhupar wrote:
Strange question but I am using an OMAP 3530 and the boot process currently is from TI's X-Loader to U-Boot to Linux.
What I want is to have two different versions of U-Boot, an extremely optimized and small one (to reduce boot time) but then also a debug version that has a built in device test suite and allows updating of the Linux kernel.
The optimized version would boot first and then check if a GPIO is set, if so then it would boot into the debug U-Boot to perform tests or software updates.
Anyone do anything like this or is it even possible?
Certainly possible. Fairly trivial. Just put two builds in your flash and ramload the larger one when required - just like when testing a new version of U-Boot before committing to flash.
But is it really worth the hassle? Is the network code really that large, or startup time really significantly longer in your 'debug' version?
I.
participants (4)
-
Ian Jeffray -
Matthias Kaehlcke -
Nishanth Menon -
Rishi Dhupar