[U-Boot] Adding support to Technexion TAM3517 SOM

[Stefano Babic]

On 24/11/2011 07:57, Tapani Utriainen wrote:
> On Wed, 23 Nov 2011 10:26:54 +0100
> Stefano Babic <sbabic at 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: office at denx.de
=====================================================================