[U-Boot] at91rm9200 linking problem (?)

[U-Boot] at91rm9200 linking problem (?)

[Marcin Górski]

Hello,

I'm trying to port U-Boot to ARM&EVA board (with AT92RM9200 cpu). I'm a little bit confused about usage of CONFIG_SYS_TEXT_BASE macro. As mentioned many times before U-Boot shouldn't be run from RAM, so I set CONFIG_SYS_TEXT_BASE to point a DataFlash memory. But when I do that not only .text section but also .data and .bss sections are linked to flash memory. When I run U-Boot I get "prefetch_abort" exception (which I believe is due to invalid memory location access). On the other hand, when I set  CONFIG_SYS_TEXT_BASE to point to RAM location U-Boot hangs just after the start:

U-Boot> go 0x22000000
## Starting application at 0x22000000 ...

U-Boot 2011.03 (Jun 20 2011 - 00:56:19)

DRAM:  1 MiB

To load a new image I use an old version of U-Boot (1.1.6) that was previously installed on this board.  This is the very first time when I use U-Boot , any suggestion will be appreciated.
Best regards,
Marcin 

[U-Boot] at91rm9200 linking problem (?)

[Andreas Bießmann]

Dear Marcin G?rski,

Am 20.06.2011 10:36, schrieb Marcin G?rski:
> Hello,
> 
> I'm trying to port U-Boot to ARM&EVA board (with AT92RM9200 cpu). I'm a little bit confused about usage of CONFIG_SYS_TEXT_BASE macro. As mentioned many times before U-Boot shouldn't be run from RAM, so I set CONFIG_SYS_TEXT_BASE to point a DataFlash memory. But when I do that not only .text section but also .data and .bss sections are linked to flash memory. When I run U-Boot I get "prefetch_abort" exception (which I believe is due to invalid memory location access). On the other hand, when I set  CONFIG_SYS_TEXT_BASE to point to RAM location U-Boot hangs just after the start:

unfortunately I did not get at91rm9200ek working to boot from NOR flash
or dataflash correctly. I'm working on that, but only in my rare spare
time. If you get it working, please tell it to me.

> U-Boot> go 0x22000000
> ## Starting application at 0x22000000 ...
> 
> U-Boot 2011.03 (Jun 20 2011 - 00:56:19)
> 
> DRAM:  1 MiB
> 
> To load a new image I use an old version of U-Boot (1.1.6) that was previously installed on this board.  This is the very first time when I use U-Boot , any suggestion will be appreciated.

That is Ok, but you need to SKIP_LOWLEVEL_INIT (or similar) to prevent
the start.S to re-initiate the SDRAM (which was done by the first
loader, u-boot 1.1.6 here).

You need to link your new U-Boot to an address somewhere in SDRAM (e.g.
0x22000000, if your system has more than 32MiB) and then use the first
stage loader (u-boot 1.1.6 here) to transfer the new u-boot exactely to
that address! But keep in mind to _not_ touch the SDRAM configuration if
you have some data in SDRAM ;)

You can use the at91bootstarp as first stage bootloader in future. But I
recommend you to invest some time to get U-Boot as SPL working on that
architecture.

regards

Andreas Bie?mann

[U-Boot] at91rm9200 linking problem (?)

[Andreas Bießmann]

Dear Marcin G?rski,

please no TOFU, use inline quoting (and send also to the list).

Am 20.06.2011 11:39, schrieb Marcin G?rski:
> Hello,
> 
> I already use CONFIG_SKIP_LOWLEVEL_INIT to prevent U-Boot from reinitilizing
> hardware. My board has 128MB RAM, so 0x22000000 address is not a problem.

Ok so far.

> Have you got any ideas why U-Boot cannot correctly detect RAM size (it shows
> "DRAM:  1 MiB") and crashes after that?

How do you setup your gd_t? Have you written a correct 'int dram_init()'
in your board code (see board/atmel/at91rm9200ek/at91rm9200ek.c for
example)?

> To compile it I also had to add 3 macros to the configuration file:
> CONFIG_SYS_INIT_RAM_ADDR,

Why this? I guess you mean CONFIG_SYS_SDRAM_BASE here.

> CONFIG_SYS_INIT_RAM_SIZE and
> CONFIG_SYS_INIT_SP_ADDR.  Can this cause this problem?

SYS_INIT_SP_ADDR is required, if you see 'DRAM: ...' output it is likely
to be a correct value for you. I guess your gd_t parameters for SDRAM
size are not correct which leads to a wrong relocation address and
therefore relocate_code() fails.

regards

Andreas Bie?mann

[U-Boot] at91rm9200 linking problem (?)

[Marcin Górski]

>> To compile it I also had to add 3 macros to the configuration file:
>> CONFIG_SYS_INIT_RAM_ADDR,
> 
> Why this? I guess you mean CONFIG_SYS_SDRAM_BASE here.
> 
Yes, my mistake.

>> CONFIG_SYS_INIT_RAM_SIZE and
>> CONFIG_SYS_INIT_SP_ADDR.  Can this cause this problem?
> 
> SYS_INIT_SP_ADDR is required, if you see 'DRAM: ...' output it is likely
> to be a correct value for you. I guess your gd_t parameters for SDRAM
> size are not correct which leads to a wrong relocation address and
> therefore relocate_code() fails.


Yes, I've fixed gd_t parameter but the result hasn't changed.

All behaviour described so far relates to at91rm9200dk board. You mentioned trying at91rm9200ek board, so I switched to it, but I have problems with with compilation when data flash memory is used (I need it to store environment settings). So I tried not to store environment settings by defining CONFIG_ENV_IS_IN_NOWHERE and comment out all data flash configs, but I end up with multiple undefined references (to flash, spi and dataflash). How did you make your board to run only in RAM omitting flash configuration?

regards,
Marcin

[U-Boot] at91rm9200 linking problem (?)

[Andreas Bießmann]

Dear Marcin G?rski,

Am 21.06.2011 15:19, schrieb Marcin G?rski:
>>> CONFIG_SYS_INIT_RAM_SIZE and
>>> CONFIG_SYS_INIT_SP_ADDR.  Can this cause this problem?
>>
>> SYS_INIT_SP_ADDR is required, if you see 'DRAM: ...' output it is likely
>> to be a correct value for you. I guess your gd_t parameters for SDRAM
>> size are not correct which leads to a wrong relocation address and
>> therefore relocate_code() fails.
> 
> 
> Yes, I've fixed gd_t parameter but the result hasn't changed.

Ok ... can you debug the board_init_f/relocate_code/board_init_r functions?
Where is your relocate_code() destination address (it is calculated in
board_init_f())?
Is relocate_code() reached?
Does the fixup loop's run? (don't forget to reload symbol file as
described in doc/README.arm-relocation)
Is board_init_r() reached?
...

> All behaviour described so far relates to at91rm9200dk board.

at91rm9200dk uses the deprecated arm920t/at91rm9200 stuff and is known
to be broken currently! The arm920t/at91rm9200 code will be deleted in
near future! (and so at91rm9200dk board, if you have one handy please
try to get it working with arm920t/at91 files). If your board uses
arm920t/at91rm9200 configuration please convert it to arm920t/at91 ASAP!

> You mentioned trying at91rm9200ek board, so I switched to it,
> but I have problems with with compilation when data flash memory is used
> (I need it to store environment settings).

Sorry, I can not help here cause I didn't get dataflash working with
at91rm9200ek yet.

> So I tried not to store environment settings
> by defining CONFIG_ENV_IS_IN_NOWHERE and comment out all data flash configs, but I end up
> with multiple undefined references (to flash, spi and dataflash).

> How did you make your board to run only in RAM omitting flash configuration?

Well I own an at91rm9200ek and use the at91rm9200ek_ram_config to build
(is mainline). The NOR flash booting is currently broken but getting
this working is my next target.

Dataflash for at91 targets in principle is currently somewhat
broken/unreliable/defective API (there was a discussion these days,
search the list).

regards

Andreas Bie?mann