[U-Boot] Need help to get u-boot running on the taskit stamp9g20
Hello @all,
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.
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<------------------------------------------
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. ;-)
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.
Thank you very much,
Markus Hubig
Dear Markus Hubig,
In message CAGws1Ttp+LsKa18DpmWz-Q4d94sEeM84rOJZ+9=kS_YnGx0-Dw@mail.gmail.com you wrote:
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
Congrats - you got already pretty far. You have the console working, so you can add printf() lines to the code where you suspect issues...
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. ;-)
Attach a JTAG debugger and fire up GDB. If you see resets after regular intervals, then check if ther eis some watchdog running.
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.
Sorry, but it doesn't work like that. We don't read such attachments. Please see http://www.denx.de/wiki/U-Boot/Patches is you really want to submit a patch, and see http://catb.org/esr/faqs/smart-questions.html#code
Best regards,
Wolfgang Denk
On Thu, Jul 12, 2012 at 08:07:17AM +0200, Wolfgang Denk wrote:
In message CAGws1Ttp+LsKa18DpmWz-Q4d94sEeM84rOJZ+9=kS_YnGx0-Dw@mail.gmail.com you wrote:
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.
Sorry, but it doesn't work like that. We don't read such attachments. Please see http://www.denx.de/wiki/U-Boot/Patches is you really want to submit a patch, and see http://catb.org/esr/faqs/smart-questions.html#code
Got it ...
Thanks, Markus
Dear Markus Hubig,
On 11.07.2012 21:28, Markus Hubig wrote:
Hello @all,
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.
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 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.
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.
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.
Another not related question: What is your Bachelor thesis about? Is there some space to implement some basic SPL for u-boot on at91?
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 ...
Best regards
Andreas Bießmann
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?
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
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.
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?
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" ... ;-)
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"? Is this intended to replace the AT91Bootstrap?
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.
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 ...
Many thanks, Markus
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
On Fri, Jul 13, 2012 at 01:04:46AM +0200, Andreas Bießmann wrote:
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:
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
Hmm OK I disabled the watchdog and enabled debugging and now this is what I get at the first boot after flashing:
| RomBOOT | | | U-Boot 2012.04.01-00003-gab465ef-dirty (Jul 18 2012 - 15:08:22) | | U-Boot code: 23F00000 -> 23F30130 BSS: -> 23F71E28 | CPU: AT91SAM9G20 | Crystal frequency: 18.432 MHz | CPU clock : 396.288 MHz | Master clock : 132.096 MHz | Starting dram_init! | dram_init finished! | monitor len: 00071E28 | ramsize: 04000000 | Top of RAM usable for U-Boot at: 24000000 | Reserving 455k for U-Boot at: 23f8e000 | Reserving 640k for malloc() at: 23eee000 | Reserving 36 Bytes for Board Info at: 23eedfdc | Reserving 144 Bytes for Global Data at: 23eedf4c | New Stack Pointer is: 23eedf40 | RAM Configuration: | Bank #0: 20000000 64 MiB | relocation Offset is: 0008e000 | WARNING: Caches not enabled | monitor flash len: 00035750 | Starting board_init! | Starting stamp9G20_nand_hw_init! | stamp9G20_nand_hw_init finished! | Starting stamp9G20_macb_hw_init! | stamp9G20_macb_hw_init finished! | board_init finished! | Now running in RAM - U-Boot at: 23f8e000
The red LED is on and I can't input anything.
Starting with the second boot I get stuff like that ...
| HhW,.]Z��.]X[�N�&��+ˋօ�}���хjR4х���:ɂ�兹�}��}���с2���͡���jR4E��ѥ����х���:ɂ | �Յ��}��}���хjR�stamp9G20_macb_hw_init finished!board_init finished!
Any hints? I stuck here ...
Cheers, Markus
On Wed, Jul 18, 2012 at 03:21:00PM +0200, Markus Hubig wrote:
Hmm OK I disabled the watchdog and enabled debugging and now this is what I get at the first boot after flashing:
| RomBOOT | | | U-Boot 2012.04.01-00003-gab465ef-dirty (Jul 18 2012 - 15:08:22) | | U-Boot code: 23F00000 -> 23F30130 BSS: -> 23F71E28 | CPU: AT91SAM9G20 | Crystal frequency: 18.432 MHz | CPU clock : 396.288 MHz | Master clock : 132.096 MHz | Starting dram_init! | dram_init finished! | monitor len: 00071E28 | ramsize: 04000000 | Top of RAM usable for U-Boot at: 24000000 | Reserving 455k for U-Boot at: 23f8e000 | Reserving 640k for malloc() at: 23eee000 | Reserving 36 Bytes for Board Info at: 23eedfdc | Reserving 144 Bytes for Global Data at: 23eedf4c | New Stack Pointer is: 23eedf40 | RAM Configuration: | Bank #0: 20000000 64 MiB | relocation Offset is: 0008e000 | WARNING: Caches not enabled | monitor flash len: 00035750 | Starting board_init! | Starting stamp9G20_nand_hw_init! | stamp9G20_nand_hw_init finished! | Starting stamp9G20_macb_hw_init! | stamp9G20_macb_hw_init finished! | board_init finished! | Now running in RAM - U-Boot at: 23f8e000
The red LED is on and I can't input anything.
OK now I managed to plug a JTAG Adapter with OpenOCD to the PortuxG20. But what now? How can I find out where I stuck?
Cheers, Markus
On Fri, Jul 20, 2012 at 03:08:51PM +0200, Markus Hubig wrote:
On Wed, Jul 18, 2012 at 03:21:00PM +0200, Markus Hubig wrote:
Hmm OK I disabled the watchdog and enabled debugging and now this is what I get at the first boot after flashing:
| RomBOOT | | | U-Boot 2012.04.01-00003-gab465ef-dirty (Jul 18 2012 - 15:08:22) | | U-Boot code: 23F00000 -> 23F30130 BSS: -> 23F71E28 | CPU: AT91SAM9G20 | Crystal frequency: 18.432 MHz | CPU clock : 396.288 MHz | Master clock : 132.096 MHz | Starting dram_init! | dram_init finished! | monitor len: 00071E28 | ramsize: 04000000 | Top of RAM usable for U-Boot at: 24000000 | Reserving 455k for U-Boot at: 23f8e000 | Reserving 640k for malloc() at: 23eee000 | Reserving 36 Bytes for Board Info at: 23eedfdc | Reserving 144 Bytes for Global Data at: 23eedf4c | New Stack Pointer is: 23eedf40 | RAM Configuration: | Bank #0: 20000000 64 MiB | relocation Offset is: 0008e000 | WARNING: Caches not enabled | monitor flash len: 00035750 | Starting board_init! | Starting stamp9G20_nand_hw_init! | stamp9G20_nand_hw_init finished! | Starting stamp9G20_macb_hw_init! | stamp9G20_macb_hw_init finished! | board_init finished! | Now running in RAM - U-Boot at: 23f8e000
The red LED is on and I can't input anything.
OK now I managed to plug a JTAG Adapter with OpenOCD to the PortuxG20. But what now? How can I find out where I stuck?
Hmm ok .. JTAG & GDB is kind of a future wappon for me, don't know how to handle. But using the old'n'good "trace code" debugging, I managed to find out where my u-boot stops. It's in
arch/arm/lib/board.c: =====================
| debug("malloc stuff start\n"); | /* The Malloc area is immediately below the monitor copy in DRAM */ | malloc_start = dest_addr - TOTAL_MALLOC_LEN; | mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN); | debug("malloc stuff finished\n");
It never reaches the second debug output. Digin a bit deeper I found in
common/dlmalloc.c =================
| void mem_malloc_init(ulong start, ulong size) | { | mem_malloc_start = start; | mem_malloc_end = start + size; | mem_malloc_brk = start; | debug("bevor memset"); | memset((void *)mem_malloc_start, 0, size); | debug("after memset\n"); | }
here it also never reaches the second debug output.
And the only setting I found in my board support code (stamp9g20.h) that is obviously realated to this "malloc-thing" is:
| #define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE \ | + 128*1024, 0x1000) | #define CONFIG_SYS_GBL_DATA_SIZE 128 | #define CONFIG_STACKSIZE (32*1024)
but this values are all copied from the original (and once working) patch from taskit ...
Any thoughts?
Cheers, Markus
Dear Markus Hubig,
In message 20120720142655.GB20267@imko.de you wrote:
And the only setting I found in my board support code (stamp9g20.h) that is obviously realated to this "malloc-thing" is:
| #define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE \ | + 128*1024, 0x1000) | #define CONFIG_SYS_GBL_DATA_SIZE 128
See commit 25ddd1f and get rid of CONFIG_SYS_GBL_DATA_SIZE
but this values are all copied from the original (and once working) patch from taskit ...
once working = now obsoleted.
Best regards,
Wolfgang Denk
On Sun, Jul 22, 2012 at 12:03:25AM +0200, Wolfgang Denk wrote:
Dear Markus Hubig,
In message 20120720142655.GB20267@imko.de you wrote:
And the only setting I found in my board support code (stamp9g20.h) that is obviously realated to this "malloc-thing" is:
| #define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE \ | + 128*1024, 0x1000) | #define CONFIG_SYS_GBL_DATA_SIZE 128
See commit 25ddd1f and get rid of CONFIG_SYS_GBL_DATA_SIZE
but this values are all copied from the original (and once working) patch from taskit ...
once working = now obsoleted.
Hmm OK. I got rid of this config setting. But I'm actually not a single step further... I looked at every single commit of the at91sam9260ek code to get a understanding what the problem is but didn't get a clue ...
Is it the nand? If I don't enable #DEBUG u-boot mostly stops at the "NAND: "-Prompt. But the nand stuff in my stam9g20.c file is actually the same as in at91sam9260ek.c:
| static void stamp9g20_nand_hw_init(void) | { | struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC; | struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX; | unsigned long csa; | | /* Assign CS3 to NAND/SmartMedia Interface */ | csa = readl(&matrix->ebicsa); | csa |= AT91_MATRIX_CS3A_SMC_SMARTMEDIA; | writel(csa, &matrix->ebicsa); | | /* Configure SMC CS3 for NAND/SmartMedia */ | writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) | | AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0), | &smc->cs[3].setup); | writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(3) | | AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3), | &smc->cs[3].pulse); | writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5), | &smc->cs[3].cycle); | writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE | | AT91_SMC_MODE_EXNW_DISABLE | | AT91_SMC_MODE_DBW_8 | | AT91_SMC_MODE_TDF_CYCLE(2), | &smc->cs[3].mode); | | /* Configure RDY/BSY */ | at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1); | | /* Enable NandFlash */ | at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1); | | }
Is it a relocation problem? If I enable #DEBUG u-boot mostly stops at the relocation prombt here:
| relocation Offset is: 0007c000
or here:
| relocation Offset is: 0007e000 | WARNING: Caches not enabled | monitor flash len: 00035820 | Now running in RAM - U-Boot at: 23f7e000
I looked at every single byte on the internet an I found some information that in order to get this bad-ass relocation to work, one needs to adapt at91bootstrap to work with u-boot. Could this be my problem? At the moment I'm using the original at91bootstrap from taskit.
Here is what I think the problem could, maybe, be:
1. Board gets powered on. 2. at91bootstrap magically starts. 3. It reads IMG_SIZE from IMG_ADDRESS and writes it to JUMP_ADDR in RAM. - IMG_ADDRESS is where I write u-boot to inside NAND? - IMG_SIZE should be the size of u-boot.bin? (exactly or is a bigger size OK?) - JUMP_ADDR is where u-boot is relocated to in RAM. Should be CONFIG_SYS_TEXT_BASE? 4. at91bootstrap sets the PC to JUMP_ADDR and starts u-boot.
Since IMG_SIZE in at91bootstrap is not the size of my new u-boot.bin it crashes after relocation!
I tried to build at91bootstrap_3.x from https://github.com/linux4sam/at91bootstrap but it didn't work. What is the preferred version to use? Orig from atmel? 3.x 2.x?
Cheers, Markus
On Tue, Jul 24, 2012 at 05:43:28PM +0200, Markus Hubig wrote:
I looked at every single byte on the internet an I found some information that in order to get this bad-ass relocation to work, one needs to adapt at91bootstrap to work with u-boot. Could this be my problem? At the moment I'm using the original at91bootstrap from taskit.
Here is what I think the problem could, maybe, be:
- Board gets powered on.
- at91bootstrap magically starts.
- It reads IMG_SIZE from IMG_ADDRESS and writes it to JUMP_ADDR in RAM.
- IMG_ADDRESS is where I write u-boot to inside NAND?
- IMG_SIZE should be the size of u-boot.bin? (exactly or is a bigger size OK?)
- JUMP_ADDR is where u-boot is relocated to in RAM. Should be CONFIG_SYS_TEXT_BASE?
- at91bootstrap sets the PC to JUMP_ADDR and starts u-boot.
Since IMG_SIZE in at91bootstrap is not the size of my new u-boot.bin it crashes after relocation!
Year! This was exactly my problem! Building a new at91bootstrap with a bigger IMG_SIZE solved it. Now U-Boot starts up!
Im getting closer to a patch! ;-)
Cheers, Markus
participants (3)
-
Andreas Bießmann -
Markus Hubig -
Wolfgang Denk