| Message ID | 74CDBE0F657A3D45AFBB94109FB122FF173BE1A33E@HQMAIL01.nvidia.com |
|---|---|
| State | New, archived |
| Headers | show |
* Stephen Warren wrote: > Thierry Reding wrote at Friday, October 14, 2011 12:59 PM: > > * Stephen Warren wrote: [...] > > U-Boot mainline support is another point on my TODO list. Getting the latest > > mainline code with the patches you mention (I assume you are referring to the > > patch series by Simon Glass and Tom Warren) to work would be a good step in > > that direction. > > I branched from: git://git.denx.de/u-boot.git master at commit > 0841ca90f22d73b0ea4642ef1ce33d879bb2f3ff. > > I applied the following: > > http://patchwork.ozlabs.org/patch/115862/ > http://patchwork.ozlabs.org/patch/115864/ > http://patchwork.ozlabs.org/patch/115865/ > http://patchwork.ozlabs.org/patch/115860/ > http://patchwork.ozlabs.org/patch/115863/ > http://patchwork.ozlabs.org/patch/115861/ > > http://patchwork.ozlabs.org/patch/119321/ > http://patchwork.ozlabs.org/patch/119322/ > http://patchwork.ozlabs.org/patch/119323/ > http://patchwork.ozlabs.org/patch/119324/ > http://patchwork.ozlabs.org/patch/119325/ > > http://patchwork.ozlabs.org/patch/118184/ > > I applied the following to hack the default environment so I could boot from > SD cards layed out how mine are; you'll probably need to tweak this a bunch: > > diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h > index 07546a4..f30f569 100644 > --- a/include/configs/tegra2-common.h > +++ b/include/configs/tegra2-common.h > @@ -104,9 +104,19 @@ > > /* Environment information */ > #define CONFIG_EXTRA_ENV_SETTINGS \ > - "console=ttyS0,115200n8\0" \ > - "mem=" TEGRA2_SYSMEM "\0" \ > - "smpflag=smp\0" \ > + "bootcmd=run usb0_boot ; run usb1_boot ; run mmc1_boot ; run mmc0_boot\0" \ > + "bootdelay=2\0" \ > + "loadaddr=0x00500000\0" \ > + "scriptaddr=0x408000\0" \ > + "script_img=/u-boot/boot.scr.uimg\0" \ > + "mmc0_boot=setenv devnum 0; run mmc_boot;\0" \ > + "mmc1_boot=setenv devnum 1; run mmc_boot;\0" \ > + "usb0_boot=usb start 0; run usb_boot;\0" \ > + "usb1_boot=usb start 1; run usb_boot;\0" \ > + "scr_boot=fatload ${devtype} ${devnum}:c ${scriptaddr} ${script_img};source ${scriptaddr};read ${devtype} ${devnum}:${kernelpart} ${scriptaddr} 0 10;source ${scriptaddr};\0" \ > + "mmc_boot=mmc dev ${devnum};setenv devtype mmc;setenv devname mmcblk${devnum}p;run scr_boot;\0" \ > + "usb_boot=setenv devtype usb;setenv devnum 0;setenv devname sda;run scr_boot;\0" \ > + "platform_extras=lp0_vec=0x2000@0x1C406000 kcrashmem=0x100000@0x02000000 mem=384M@0M nvmem=128M@384M mem=511M@512M\0" \ > > #define CONFIG_LOADADDR 0x408000 /* def. location for kernel */ > #define CONFIG_BOOTDELAY 2 /* -1 to disable auto boot */ > > In order to actually use the resultant u-boot.bin, it's pretty simple if you > already have nvflash working with burn fastboot. > > 1) Edit flash.cfg (or whatever config file you pass to nvflash to define > The partitions and their content) and replace the filename entry in the > EBT partition with u-boot.bin. > > 2) I personally remove all the partition entries in flash.cfg except for > BCT, PT, EBT. This will avoid nvflash flashing your Android/... filesystem. > If you want your filesystem in the same flash, don't do this. > > Then, run nvflash just like you would normally. Okay, I've been able to build U-Boot and setup some scripts that should automate the nvflash procedure according to your instructions. I'll have to wait until I get back to work on Monday to see whether it actually works, though. > > Have you done any testing with the NVIDIA binary blobs when booting this way? > > The latest information I have from our NVIDIA contacts is that fastboot or > > quickboot are required, for some reason, to make HW accelerated video > > decoding and 3D rendering work. > > It's possible the binary drivers accidentally rely on the bootloader > having configured some piece of HW. > > However, in general, the bootloader product you use shouldn't affect > whether the binary drivers work. > > In particular, the binary drivers certainly work after the ChromeOS > U-Boot boots a board. > > Coincidentally, right before seeing your email, I just tried mainline > U-Boot on Seaboard with our Linux4Tegra alpha 1 release, and while X > started, I couldn't see anything on screen. This did previously work > with some old version of ChromeOS's U-Boot. So, there's certainly some > missing HW initialization somewhere. Right, I'll probably run into the same problems then. But if it can actually make the system boot, it's enough to prepare some patches on top for mainline support. I've just caught up with most of my email backlog and I'm looking forward to testing the device-tree support in U-Boot that's recently been posted. > BTW, you might also want to take a look at NVIDIA's web forums: > > http://developer.nvidia.com/beta-forum > > While I'm personally happy to answer your questions here, (I work for > a group dedicated to making general Linux support on Tegra) you may find > more people aimed at this kind of support on those forums. I'm not > active on those forums though. I'm not a big fan of forums, but I guess I should check it out. A co-worker has actually done more work with the binary drivers and I don't know how much I will be involved there either, but I will make sure to pass the information on. > I hope this all helps! Yes, very helpful indeed! Thanks again. Thierry
* Thierry Reding wrote: > * Stephen Warren wrote: > > Thierry Reding wrote at Friday, October 14, 2011 12:59 PM: > > > * Stephen Warren wrote: > [...] > > > U-Boot mainline support is another point on my TODO list. Getting the latest > > > mainline code with the patches you mention (I assume you are referring to the > > > patch series by Simon Glass and Tom Warren) to work would be a good step in > > > that direction. > > > > I branched from: git://git.denx.de/u-boot.git master at commit > > 0841ca90f22d73b0ea4642ef1ce33d879bb2f3ff. > > > > I applied the following: > > > > http://patchwork.ozlabs.org/patch/115862/ > > http://patchwork.ozlabs.org/patch/115864/ > > http://patchwork.ozlabs.org/patch/115865/ > > http://patchwork.ozlabs.org/patch/115860/ > > http://patchwork.ozlabs.org/patch/115863/ > > http://patchwork.ozlabs.org/patch/115861/ > > > > http://patchwork.ozlabs.org/patch/119321/ > > http://patchwork.ozlabs.org/patch/119322/ > > http://patchwork.ozlabs.org/patch/119323/ > > http://patchwork.ozlabs.org/patch/119324/ > > http://patchwork.ozlabs.org/patch/119325/ > > > > http://patchwork.ozlabs.org/patch/118184/ > > > > I applied the following to hack the default environment so I could boot from > > SD cards layed out how mine are; you'll probably need to tweak this a bunch: > > > > diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h > > index 07546a4..f30f569 100644 > > --- a/include/configs/tegra2-common.h > > +++ b/include/configs/tegra2-common.h > > @@ -104,9 +104,19 @@ > > > > /* Environment information */ > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > - "console=ttyS0,115200n8\0" \ > > - "mem=" TEGRA2_SYSMEM "\0" \ > > - "smpflag=smp\0" \ > > + "bootcmd=run usb0_boot ; run usb1_boot ; run mmc1_boot ; run mmc0_boot\0" \ > > + "bootdelay=2\0" \ > > + "loadaddr=0x00500000\0" \ > > + "scriptaddr=0x408000\0" \ > > + "script_img=/u-boot/boot.scr.uimg\0" \ > > + "mmc0_boot=setenv devnum 0; run mmc_boot;\0" \ > > + "mmc1_boot=setenv devnum 1; run mmc_boot;\0" \ > > + "usb0_boot=usb start 0; run usb_boot;\0" \ > > + "usb1_boot=usb start 1; run usb_boot;\0" \ > > + "scr_boot=fatload ${devtype} ${devnum}:c ${scriptaddr} ${script_img};source ${scriptaddr};read ${devtype} ${devnum}:${kernelpart} ${scriptaddr} 0 10;source ${scriptaddr};\0" \ > > + "mmc_boot=mmc dev ${devnum};setenv devtype mmc;setenv devname mmcblk${devnum}p;run scr_boot;\0" \ > > + "usb_boot=setenv devtype usb;setenv devnum 0;setenv devname sda;run scr_boot;\0" \ > > + "platform_extras=lp0_vec=0x2000@0x1C406000 kcrashmem=0x100000@0x02000000 mem=384M@0M nvmem=128M@384M mem=511M@512M\0" \ > > > > #define CONFIG_LOADADDR 0x408000 /* def. location for kernel */ > > #define CONFIG_BOOTDELAY 2 /* -1 to disable auto boot */ > > > > In order to actually use the resultant u-boot.bin, it's pretty simple if you > > already have nvflash working with burn fastboot. > > > > 1) Edit flash.cfg (or whatever config file you pass to nvflash to define > > The partitions and their content) and replace the filename entry in the > > EBT partition with u-boot.bin. > > > > 2) I personally remove all the partition entries in flash.cfg except for > > BCT, PT, EBT. This will avoid nvflash flashing your Android/... filesystem. > > If you want your filesystem in the same flash, don't do this. > > > > Then, run nvflash just like you would normally. > > Okay, I've been able to build U-Boot and setup some scripts that should > automate the nvflash procedure according to your instructions. I'll have to > wait until I get back to work on Monday to see whether it actually works, > though. I'm unable to make this work. I've done as you said, branched from the commit you mentioned and applied the patches you listed. Then ran: $ make CROSS_COMPILE=... O=build/harmony harmony_config $ make CROSS_COMPILE=... O=build/harmony -j8 And flashed the resulting u-boot.bin like you described, by replacing the fastboot.bin in the configuration with u-boot.bin. When rebooting the device (I used a Harmony for this testing obviously) there's nothing. No output on the serial line. Flashing fastboot.bin I can at least see some debugging output. I also tried to update the TEXT_BASE, which seems to be 0x00108000 for fastboot, and 0x00E08000 for U-Boot, but that didn't make a difference. Any ideas on what could be the problem? I'm not quite sure where these values come from. Are they hard-coded in the boot ROM? And how does it know from which NAND partition to load the bootloader? Thanks, Thierry
Thierry Reding wrote at Monday, October 17, 2011 4:27 AM: > * Thierry Reding wrote: > > * Stephen Warren wrote: > > > ... [U-Boot patch/build instructions] > > > Then, run nvflash just like you would normally. > > > > Okay, I've been able to build U-Boot and setup some scripts that should > > automate the nvflash procedure according to your instructions. I'll have to > > wait until I get back to work on Monday to see whether it actually works, > > though. > > I'm unable to make this work. I've done as you said, branched from the commit > you mentioned and applied the patches you listed. Then ran: > > $ make CROSS_COMPILE=... O=build/harmony harmony_config > $ make CROSS_COMPILE=... O=build/harmony -j8 > > And flashed the resulting u-boot.bin like you described, by replacing the > fastboot.bin in the configuration with u-boot.bin. When rebooting the device > (I used a Harmony for this testing obviously) there's nothing. No output on > the serial line. Flashing fastboot.bin I can at least see some debugging > output. > > I also tried to update the TEXT_BASE, which seems to be 0x00108000 for > fastboot, and 0x00E08000 for U-Boot, but that didn't make a difference. Any > ideas on what could be the problem? Ah yes, sorry, I'd forgotten about that. The default load address for fastboot and U-Boot is different. I don't know why, but apparently U-Boot doesn't work when built with a load address that matches fastboot. I believe we have a bug filed to investigate why, but I don't know any more details. > I'm not quite sure where these values come from. Are they hard-coded in the > boot ROM? And how does it know from which NAND partition to load the > bootloader? These addresses exist in a couple places: * In the BCT, which tells the boot ROM the SDRAM address where the boot- loader should be copied to, and what the entry point is. * Hard-coded into nvflash, and the fastboot.bin used during the flashing process. Hence, internally, I believe we use nvflash/fastboot.bin that have been specifically recompiled to support U-Boot's load address. Thinking about this some more, I think we have shipped those rebuilt versions outside NVIDIA in a publically accessible place. I'll follow up internally and see if we have, or what we can do about it. Sorry for sending you on a wild goose chase.
* Stephen Warren wrote: > Thierry Reding wrote at Monday, October 17, 2011 4:27 AM: > > * Thierry Reding wrote: > > > * Stephen Warren wrote: > > > > ... [U-Boot patch/build instructions] > > > > Then, run nvflash just like you would normally. > > > > > > Okay, I've been able to build U-Boot and setup some scripts that should > > > automate the nvflash procedure according to your instructions. I'll have to > > > wait until I get back to work on Monday to see whether it actually works, > > > though. > > > > I'm unable to make this work. I've done as you said, branched from the commit > > you mentioned and applied the patches you listed. Then ran: > > > > $ make CROSS_COMPILE=... O=build/harmony harmony_config > > $ make CROSS_COMPILE=... O=build/harmony -j8 > > > > And flashed the resulting u-boot.bin like you described, by replacing the > > fastboot.bin in the configuration with u-boot.bin. When rebooting the device > > (I used a Harmony for this testing obviously) there's nothing. No output on > > the serial line. Flashing fastboot.bin I can at least see some debugging > > output. > > > > I also tried to update the TEXT_BASE, which seems to be 0x00108000 for > > fastboot, and 0x00E08000 for U-Boot, but that didn't make a difference. Any > > ideas on what could be the problem? > > Ah yes, sorry, I'd forgotten about that. > > The default load address for fastboot and U-Boot is different. I don't > know why, but apparently U-Boot doesn't work when built with a load > address that matches fastboot. I believe we have a bug filed to investigate > why, but I don't know any more details. > > > I'm not quite sure where these values come from. Are they hard-coded in the > > boot ROM? And how does it know from which NAND partition to load the > > bootloader? > > These addresses exist in a couple places: > > * In the BCT, which tells the boot ROM the SDRAM address where the boot- > loader should be copied to, and what the entry point is. > > * Hard-coded into nvflash, and the fastboot.bin used during the flashing > process. > > Hence, internally, I believe we use nvflash/fastboot.bin that have been > specifically recompiled to support U-Boot's load address. > > Thinking about this some more, I think we have shipped those rebuilt > versions outside NVIDIA in a publically accessible place. I'll follow > up internally and see if we have, or what we can do about it. Sorry for > sending you on a wild goose chase. I've been working some on getting our boards to boot from a device tree. Unfortunately, the U-Boot issue seems to be more of a problem than I anticipated. Since the mainline U-Boot doesn't run properly, I was going to use the one shipped with Vibrante. As it turns out, that version is rather old and doesn't have proper DT support for ARM yet. So I tried to switch to the Chromium tree in the meantime but I cannot get it to work either. Not standalone and not with quickboot as stage1. So I'm running a little out of options. I'm reluctant to backport complete DT support to the Vibrante version and I'm a short on time anyway, so figuring out why the Chromium tree won't boot is not really an option either. Are there any news on these rebuilt versions of nvflash that you mentioned? Thierry
Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM: ... > I've been working some on getting our boards to boot from a device tree. > Unfortunately, the U-Boot issue seems to be more of a problem than I > anticipated. Since the mainline U-Boot doesn't run properly, ----------==========----------==========----------==========----------========== What issues are you having? I assume you're referring to something more than just getting stuff flashed with nvflash. > Are there any news on these rebuilt versions of nvflash that you mentioned? Sorry, not yet.
* Stephen Warren wrote: > Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM: > ... > > I've been working some on getting our boards to boot from a device tree. > > Unfortunately, the U-Boot issue seems to be more of a problem than I > > anticipated. Since the mainline U-Boot doesn't run properly, > > ----------==========----------==========----------==========----------========== > What issues are you having? I assume you're referring to something more > than just getting stuff flashed with nvflash. Flashing U-Boot is not the problem, but when booting the device, there's no output whatsoever on the debug port. That's what I meant in one of the previous mails. nvflash says it's loading fastboot.bin at address 0x00108000, and quickboot seems to use the same load address. However, U-Boot is built with CONFIG_SYS_TEXT_BASE set to 0x00E08000. If it is loaded to the same address as fastboot/quickboot it obviously cannot run. So I went ahead and built U-Boot (both mainline and the one from the Chromium repo) with a load address of 0x00108000 - to no avail. I'm starting to think that perhaps I'm completely overlooking something obvious. When I use the Vibrante U-Boot, I get normal U-Boot output on the debug port when I flash it as stage 2 for quickboot. The other versions of U-Boot don't work in that setup. None of the three versions boot when flashed standalone (substituting u-boot.bin for fastboot.bin in the nvflash configuration file). I would guess that at least with quickboot as stage 1 I should be able to get serial output from the mainline U-Boot. Would it be helpful to move the discussion to the U-Boot mailing list instead? It's sort of off-topic here. Thierry
Thierry Reding wrote at Thursday, October 20, 2011 1:08 PM: > * Stephen Warren wrote: > > Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM: > > ... > > > I've been working some on getting our boards to boot from a device tree. > > > Unfortunately, the U-Boot issue seems to be more of a problem than I > > > anticipated. Since the mainline U-Boot doesn't run properly, > > > > What issues are you having? I assume you're referring to something more > > than just getting stuff flashed with nvflash. > > Flashing U-Boot is not the problem, but when booting the device, there's no > output whatsoever on the debug port. That's what I meant in one of the > previous mails. nvflash says it's loading fastboot.bin at address 0x00108000, > and quickboot seems to use the same load address. However, U-Boot is built > with CONFIG_SYS_TEXT_BASE set to 0x00E08000. If it is loaded to the same > address as fastboot/quickboot it obviously cannot run. So I went ahead and > built U-Boot (both mainline and the one from the Chromium repo) with a load > address of 0x00108000 - to no avail. OK, I built U-Boot with load address 0x00108000 and also see nothing at boot. So, I've reproduced at least one of your problems. (This is with an Android-style nvflash that configures the BCT to tell the CPU to load/boot the bootloader at address 0x00108000, so this should work.) So, I've added this observation into the bug I filed. I'll let you know once we've had a chance to investigate and/or solve this. Sorry this isn't working yet; it's pretty early days for U-Boot on Tegra outside of ChromeOS, which uses the modified nvflash and hence doesn't hit these issues.
* Stephen Warren wrote: > Thierry Reding wrote at Thursday, October 20, 2011 1:08 PM: > > * Stephen Warren wrote: > > > Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM: > > > ... > > > > I've been working some on getting our boards to boot from a device tree. > > > > Unfortunately, the U-Boot issue seems to be more of a problem than I > > > > anticipated. Since the mainline U-Boot doesn't run properly, > > > > > > What issues are you having? I assume you're referring to something more > > > than just getting stuff flashed with nvflash. > > > > Flashing U-Boot is not the problem, but when booting the device, there's no > > output whatsoever on the debug port. That's what I meant in one of the > > previous mails. nvflash says it's loading fastboot.bin at address 0x00108000, > > and quickboot seems to use the same load address. However, U-Boot is built > > with CONFIG_SYS_TEXT_BASE set to 0x00E08000. If it is loaded to the same > > address as fastboot/quickboot it obviously cannot run. So I went ahead and > > built U-Boot (both mainline and the one from the Chromium repo) with a load > > address of 0x00108000 - to no avail. > > OK, I built U-Boot with load address 0x00108000 and also see nothing at boot. > So, I've reproduced at least one of your problems. > > (This is with an Android-style nvflash that configures the BCT to tell the CPU > to load/boot the bootloader at address 0x00108000, so this should work.) > > So, I've added this observation into the bug I filed. I'll let you know once > we've had a chance to investigate and/or solve this. > > Sorry this isn't working yet; it's pretty early days for U-Boot on Tegra > outside of ChromeOS, which uses the modified nvflash and hence doesn't hit > these issues. I was able to get my hands on the nvflash source code, so I may be able to get this to work myself. Any hints as to what exactly was changed? Was it only the load/entry address. You mention that nvflash configures the BCT; in what way. A quick glimpse at the source code doesn't show any modifications being done to the loaded BCT file. On the other hand, since obviously the paperwork is okay to get the nvflash sources, perhaps I could ask my NVIDIA contacts to provide the ChromeOS variant of nvflash. Does it have a special name internally that I should refer to? Thierry
* Stephen Warren wrote: > Thierry Reding wrote at Thursday, October 20, 2011 1:08 PM: > > * Stephen Warren wrote: > > > Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM: > > > ... > > > > I've been working some on getting our boards to boot from a device tree. > > > > Unfortunately, the U-Boot issue seems to be more of a problem than I > > > > anticipated. Since the mainline U-Boot doesn't run properly, > > > > > > What issues are you having? I assume you're referring to something more > > > than just getting stuff flashed with nvflash. > > > > Flashing U-Boot is not the problem, but when booting the device, there's no > > output whatsoever on the debug port. That's what I meant in one of the > > previous mails. nvflash says it's loading fastboot.bin at address 0x00108000, > > and quickboot seems to use the same load address. However, U-Boot is built > > with CONFIG_SYS_TEXT_BASE set to 0x00E08000. If it is loaded to the same > > address as fastboot/quickboot it obviously cannot run. So I went ahead and > > built U-Boot (both mainline and the one from the Chromium repo) with a load > > address of 0x00108000 - to no avail. > > OK, I built U-Boot with load address 0x00108000 and also see nothing at boot. > So, I've reproduced at least one of your problems. > > (This is with an Android-style nvflash that configures the BCT to tell the CPU > to load/boot the bootloader at address 0x00108000, so this should work.) > > So, I've added this observation into the bug I filed. I'll let you know once > we've had a chance to investigate and/or solve this. > > Sorry this isn't working yet; it's pretty early days for U-Boot on Tegra > outside of ChromeOS, which uses the modified nvflash and hence doesn't hit > these issues. I've been able to make limited progress on this. I've been able to successfully run a mainline U-Boot (c30a15e) with the patches you mentioned previously applied on top. However, this currently only works as quickboot payload. Standalone is not working yet. However this allows booting a mainline kernel with device tree support. So while the nvflash issues are sorted out, I have something I can get work done with. Thierry
Thierry Reding wrote at Monday, October 24, 2011 11:58 PM: ... > I was able to get my hands on the nvflash source code, so I may be able to > get this to work myself. Any hints as to what exactly was changed? Was it > only the load/entry address. You mention that nvflash configures the BCT; in > what way. A quick glimpse at the source code doesn't show any modifications > being done to the loaded BCT file. > > On the other hand, since obviously the paperwork is okay to get the nvflash > sources, perhaps I could ask my NVIDIA contacts to provide the ChromeOS > variant of nvflash. Does it have a special name internally that I should > refer to? FYI, I'm going to follow up with Thierry off-list, since any support for nvflash source code isn't going to be useful to list users.
Thierry Reding wrote at Thursday, October 20, 2011 1:08 PM: > * Stephen Warren wrote: > > Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM: > > ... > > > I've been working some on getting our boards to boot from a device tree. > > > Unfortunately, the U-Boot issue seems to be more of a problem than I > > > anticipated. Since the mainline U-Boot doesn't run properly, > > > > What issues are you having? I assume you're referring to something more > > than just getting stuff flashed with nvflash. > > Flashing U-Boot is not the problem, but when booting the device, there's no > output whatsoever on the debug port. Just to close the loop on this in the mailing list archives, the issue is now solved. The specific fix was to add "USE_PRIVATE_LIBGCC=yes" to the make command used to build U-Boot. And just for the record (Thierry was already trying this), CONFIG_SYS_TEXT_BASE must match those nvflash and fastboot.bin expect, which is 0x00108000 for the binaries shipped with our Linux4Tegra alpha 1 release.
diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h index 07546a4..f30f569 100644 --- a/include/configs/tegra2-common.h +++ b/include/configs/tegra2-common.h @@ -104,9 +104,19 @@ /* Environment information */ #define CONFIG_EXTRA_ENV_SETTINGS \ - "console=ttyS0,115200n8\0" \ - "mem=" TEGRA2_SYSMEM "\0" \ - "smpflag=smp\0" \ + "bootcmd=run usb0_boot ; run usb1_boot ; run mmc1_boot ; run mmc0_boot\0" \ + "bootdelay=2\0" \ + "loadaddr=0x00500000\0" \ + "scriptaddr=0x408000\0" \ + "script_img=/u-boot/boot.scr.uimg\0" \ + "mmc0_boot=setenv devnum 0; run mmc_boot;\0" \ + "mmc1_boot=setenv devnum 1; run mmc_boot;\0" \ + "usb0_boot=usb start 0; run usb_boot;\0" \ + "usb1_boot=usb start 1; run usb_boot;\0" \ + "scr_boot=fatload ${devtype} ${devnum}:c ${scriptaddr} ${script_img};source ${scriptaddr};read ${devtype} ${devnum}:${kernelpart} ${scriptaddr} 0 10;source ${scriptaddr};\0" \ + "mmc_boot=mmc dev ${devnum};setenv devtype mmc;setenv devname mmcblk${devnum}p;run scr_boot;\0" \ + "usb_boot=setenv devtype usb;setenv devnum 0;setenv devname sda;run scr_boot;\0" \ + "platform_extras=lp0_vec=0x2000@0x1C406000 kcrashmem=0x100000@0x02000000 mem=384M@0M nvmem=128M@384M mem=511M@512M\0" \ #define CONFIG_LOADADDR 0x408000 /* def. location for kernel */ #define CONFIG_BOOTDELAY 2 /* -1 to disable auto boot */