[U-Boot] Need help to get u-boot running on the taskit stamp9g20

[Andreas Bießmann]

Dear Markus Hubig,

On 12.07.12 17:49, Markus Hubig wrote:
> On Thu, Jul 12, 2012 at 11:28:13AM +0200, Andreas Bießmann wrote:
>> On 11.07.2012 21:28, Markus Hubig wrote:
>>> as part of my bachelor thesis I'm working with the stamp9g20 / portuxg20
>>> board from taskit (http://www.taskit.de/produkte/stamp9g20/index.htm). I
>>> have a patch for a older version (2010.somewhat) of u-boot to get it running
>>> on this board, but this patch is not working anymore.
>>
>> well, there where a lot of architectural changes (renames, drop of old
>> code, ...) in at91 around 2011. This is still work in progress, however
>> nothing happened since Reinhard gave up. I hope to bring this to an end
>> this year.
> 
> Hmm, is there some documentation I can about the changes?

Well, there was some written down in doc/README.at91*. I dunno if this
covers all the changes made. AFAIR there was a huge renaming effort for
all the atmel specific defines. In detail: rename all the AT91_* to
ATMEL_* cause of AVR32 (which is another architecture) share the same
defines for drivers like atmel_nand a.s.o.
On the other hand there was a lot of rumor in arm tree cause of the new
relocation implemented somewhere end of 2010.

>>> Now I'm in the process of adapting this patch to the new u-boot. Up to now
>>> I can compile a u-boot.bin and download it to the board. But after starting up
>>> the new u-boot I just see this on the serial port
>>>
>>> ---8<------------------------------------------
>>> U-Boot 2012.04.01-00001-gadcb359-dirty (Jul 11 2012 - 19:24:58)
>>>
>>> CPU: AT91SAM9G20
>>> Crystal frequency:   18.432 MHz
>>> CPU clock        :  396.288 MHz
>>> Master clock     :  132.096 MHz
>>> DRAM:  64 MiB
>>> WARNING: Caches not enabled
>>> NAND:  RomBOOT
>>> ---8<------------------------------------------
>>
>> So something went wrong in nand_init()? Two things you should do:
>>  a) as Wolfgung suggested previously: disable the Watchdog
> 
> Is this something I can do within my u-boot configuration file? Like so:
> 
> #undef CONFIG_AT91SAM9_WATCHDOG
> #undef CONFIG_HW_WATCHDOG

Just do not define these. You maybe hit some watchdog event while in
nand_init(). As Wolfgang suggested do not enable the watchdog at all, at
least while in this early stage of bringing the board up.

>>  b) check for the 'NAND Ready' Pin (use some oscilloscope);
>>     alternatively just remove the CONFIG_SYS_NAND_READY_PIN R/B should
>>     be handled by the nand_base driver in another way then.
> 
> Hmm I have the PortuxG20 (mini PC) so I'm not sure if I have access to
> this pin ... will check this.

You defined it in your patch, so it is there. Therefore atmel_nand
provides that R/B feature and the code nand implementation waits for a
level change on that pin. So removing this define may also solve the
problem. You need to check whether it is
 a) really connected to that pin
 b) does the pin what you expect (doing level change on R/B change of
    NAND)?

>>> and the board is rebooting every some seconds. I'm not able to give it some
>>> input via the keyboard. I think maybe there are just some small bits missing
>>> but I'm a bit lost now ... maybe some of you can have a look and can give me
>>> some advice. ;-)
>>
>> enable debug for all the drivers/mtd/nand files, put in some more debug
>> printouts where necessary.
> 
> Is there a "#define DEBUG" kind of thing?

Well, there are different types of debug mechanism in u-boot yet. Some
use the well known debug() macro which can be enabled by defining DEBUG
at the very beginning of a file. Some others copied from linux kernel
use the well known printk() which is a synonym for printf() provided by
u-boot. It depends on the code, maybe you also need to add some
printouts to get a feeling how it behaves.

>>> I include the old patch (portuxg20.patch) and the three patches I made in this
>>> email. My patches are based on u-boot v2012.04.01.
>>
>> Please send the patches in line, Wolfgang already sent a pointer
>> describing ho to achieve this.
> 
> Ups got a bit lazy these days with emails, but I resurrected my good old
> mutt so there will be no more "faux pas" ... ;-)

Just using 'git send-email' would be enough.

>> Another not related question: What is your Bachelor thesis about? Is
>> there some space to implement some basic SPL for u-boot on at91?
> 
> My thesis is about to build a small embedded linux logger device on top of
> the stamp9g20 platform. But more generally it's about making a starting point
> and getting some experience for further embedded linux development in my
> company.
> 
> With SPL you mean a "Second Program Loader"?

Yes (in short).
Longer answer is ...
Nowadays processors have some logic in it to boot from different media,
mostly called the ROM code. With these you are not longer stuck to NOR
flash which allows arbitrary access to memory addresses. You may know
the at91 way to boot from serial flash or maybe have seen some
mmc/sd-card bootup or at least nand boot up you are currently working
on. To get these devices up you will need some code which is loaded by
the ROM code firstly to setup very vital stuff to get a bigger set of
program code into the device, we call it the SPL.

> Is this intended to replace the
> AT91Bootstrap?

That is the idea, hopefully there are some others sharing my mind.
One of the important things for embedded devices is the boot time.
U-Boot, however, is a feature rich boot loader which eats a lot of time
for setting up some useful stuff while developing but mostly needless
for running a device in field.
The whole thing started somewhere in 2010 I think, I remember about some
TI first stage boot loader called X-loader which is in some way
comparable to u-boot. AFAIR there was a lot of work done by Tom Rini -
an TI employee - and Simon Schwarz - a student who wrote his bachelor
thesis about boot time saving for embedded linux devices at corscience -
to get the first OMAP devices working without X-loader code to bring up
the device from reset.
Beside that another approach came up. If you can bring up your board to
u-boot with some spl you can just copy any payload from a source to a
destination and branch it. So why don't copy the linux kernel to save
the time at boot up used by the u-boot (AFAIR this can be around a
second for some devices, as measured by Simon).
Well this approach is quite obvious and used by others too. AFAIK there
is something similar in AT91bootstrap (I have only heard about that,
never seen).
So why don't add that feature to u-boot? It would be like having the
feature rich command line while developing and just switch over to a
fast booting device by - well, depends on the setup - doing nothing (you
could define a switch to enable the u-boot in favor of the preferred
payload) by the same code (go and ask your QA whether they want to
qualify two or only one set of code ;).

> Generally I can't answer your question by now, since I know to little about
> the u-boot ... my first goal is to get a running u-boot and the stamp into
> mainline.

Would be great, please send proper patches.

>> I'm looking forward to get proper patches for the stamp9g20 to have this
>> device mainlined. Unfortunately Taskit has not tried to bring their
>> devices to mainline in the past. Therefore I think this would be your
>> task if you (or the company you working for) want this device supported
>> by u-boot mainline code. I don't want to summarize all the advantages,
>> you just hit one problem of out of tree code ...
> 
> I'm in contact with taskit, but since there newer boards don't use u-boot
> it's not in there main focus to get there boards mainlined ...

I know about that fact ... I own a portux920 which is unfortunately also
not mainlined.

Best regards

Andreas Bießmann