* 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
Attachment:
pgpAaII0nZoG8.pgp
Description: PGP signature
