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