On 24/11/2011 07:57, Tapani Utriainen wrote: > On Wed, 23 Nov 2011 10:26:54 +0100 > Stefano Babic <sba...@denx.de> wrote: > > Stefano, >
Hi Tapani, > Some comments regarding your u-boot patch for TAM3517/Twister. Thanks - please add always the mailing list as CC, we are currently review the patches, and your review has a big importance. > > First, I like the separation between the module and the baseboard. Adding > new baseboards seems easier this way. Of course, this might add complexity > in a different way, but is preferrable over the alternative. Good. Thanks. > > Second, instead of pointing out "problems" with comments,tabs and spaces in > your patch source code -- I tested it. Nice - this means you have also tested the patches. If you agree, I will add a "Tested-by" signature with your name to the patches. > Using your u-boot.bin on Twister, USB devices do not work in linux. Using > the u-boot.bin I submitted this issue disappears. The setup is otherwise the > same (same x-loader, u-boot settings, kernel and userland). > > This might be due to Ilya's EHCI patch (required to compile your u-boot), > or something not properly setup in the kernel. What do you think? > (Issue is reproducible for instance using the 2.6.32 kernel we have on > our homepage). There are several things here. First, USB is not working at all in the u-boot.bin you submit, due to a lot of different reasons (wrong controller, wrong MUX setup) - this means that your u-boot makes nothing with USB, in any case it does not set up correctly the HW. When Linux starts, it finds the USB controller as after reset, and this is a big difference. The kernel you have relies maybe on some reset values, and this does not happen with my patches because the EHCI controller was already set. The issue you reports means that the kernel does not configure completely the controller when it starts, and some registers maintain the values set by U-Boot, maybe not correct for the kernel driver. I will exclude an error in the setup of the MUX in U-boot, because the USB is working, meaning that the pins are correctly routed. By the way, you are running a very old kernel, are you sure there are not patches for the EHCI OMAP driver in the current kernel tree ? > > The third point is your default settings: they do not allow booting via local > media (SD card or NAND flash). TechNexion's opinion is that the default is > to boot via NAND or SD-card, since very few use network boot. Of course, this behavior can be changed. Please post a proposal, if you have any. In the default settings I put a basic environment, using the same variables that are already used on several boards - I know there is neither standard nor rules for a standard environment in U-Boot, but I find nice if different boards maintain the same behavior, using some quite standard commands to boot from network or from storage. I like to have a "net_nfs" (not important which is the chosen name) on all boards I work with, as well as the same commands to boot from internal storage. Apart of that, I considered that twister is an evaluation board, and the customers like to change the way the system boots. And how the storage (I mean NAND here) is partitioned. We could use partition names as "kernel", "rootfs" to split the NAND. In this way, the boot command still works if the customer rearrange the size of partitions with the mtdparts variable. Of course, this wiorks only if in the kernel the mtdparts variable is parsed (CONFIG_MTD_CMDLINE_PARTS must be set). Best regards, Stefano Babic -- ===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
