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

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

[Markus Hubig]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: portuxg20.patch
Type: application/octet-stream
Size: 18039 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120711/12f93f45/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-at91-Add-support-for-taskit-AT91SAM9G20-boards.patch
Type: application/octet-stream
Size: 19093 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120711/12f93f45/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-First-try-to-adapt-the-old-patch-to-the-new-uboot.patch
Type: application/octet-stream
Size: 19498 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120711/12f93f45/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Cleaning-up-the-code-a-bit.patch
Type: application/octet-stream
Size: 7348 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120711/12f93f45/attachment-0003.obj>

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Just about every computer on the market today runs Unix,  except  the
Mac (and nobody cares about it).                   - Bill Joy 6/21/85

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

[Markus Hubig]

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

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

[Andreas Bießmann]

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

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

[Markus Hubig]

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

[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

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

[Markus Hubig]

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

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

[Markus Hubig]

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

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

[Markus Hubig]

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

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Until you walk a mile in another man's moccasins, you  can't  imagine
the smell.

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

[Markus Hubig]

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

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

[Markus Hubig]

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:
> 
> 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!

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