[U-Boot] {Spam?} u-boot relocation

[U-Boot] {Spam?} u-boot relocation

[Marcel]

Hi,

I updated my u-boot-usb to continue my work on the SAM9 USB parts, but got 
stuck with the following issue :

There seems to be a new relocation scheme. I also added some stuff to make it 
detect the SDRAM, but than I get stuck.

 int dram_init(void)
{
        gd->bd->bi_dram[0].start = PHYS_SDRAM;
        gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
        /* dram_init must store complete ramsize in gd->ram_size */ 
        gd->ram_size = get_ram_size((volatile void *)PHYS_SDRAM, 
PHYS_SDRAM_SIZE);
        dram_init_banksize();
        return 0;
}

Booting looks like this :

U-Boot 2010.12-09749-g8da60f4-dirty (Dec 25 2010 - 18:44:18)

U-Boot code: 73F00000 -> 73F3F6F4  BSS: -> 73F51A8C
monitor len: 00051A8C
ramsize: 08000000
TLB table at: 77ff0000
Top of RAM usable for U-Boot at: 77ff0000
Reserving 326k for U-Boot at: 77f9e000
Reserving 384k for malloc() at: 77f3e000
Reserving 24 Bytes for Board Info at: 77f3dfe8
Reserving 144 Bytes for Global Data at: 77f3df58
New Stack Pointer is: 77f3df50
RAM Configuration:
Bank #0: 70000000 128 MiB
relocation Offset is: 0409e000

Here it stopsand although I have been reading the relocation readme, it 
doesn't give me any clues where to look for. 

My board has 1M NOR flash which holds u-boot. I read something in the readme 
about it, which makes me believe I need some additional things. 

Does anyone have an idea what I can do to get this to boot again ?

Best regards,
Marcel

[U-Boot] {Spam?} u-boot relocation

[Reinhard Meyer]

Dear Marcel,
> Hi,
>
> I updated my u-boot-usb to continue my work on the SAM9 USB parts, but got
> stuck with the following issue :
>
> There seems to be a new relocation scheme. I also added some stuff to make it
> detect the SDRAM, but than I get stuck.
>
>   int dram_init(void)
> {
>          gd->bd->bi_dram[0].start = PHYS_SDRAM;
>          gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
This is accessing bss before relocation. BSS does not exist then.
>          /* dram_init must store complete ramsize in gd->ram_size */
>          gd->ram_size = get_ram_size((volatile void *)PHYS_SDRAM,
> PHYS_SDRAM_SIZE);
>          dram_init_banksize();
This function, if defined, is called automagically. Normally, with single
DRAM bank AT91SAM9 designs the default weak function provided by u-boot is
sufficient:
void __dram_init_banksize(void)
{
	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
	gd->bd->bi_dram[0].size =  gd->ram_size;
}
void dram_init_banksize(void)
	__attribute__((weak, alias("__dram_init_banksize")));

Don't define this function in your board file!!!
>          return 0;
> }
Please have a look at the emk/top9000 board for what is needed:

int dram_init(void)
{
	gd->ram_size = get_ram_size(
		(void *)CONFIG_SYS_SDRAM_BASE,
		CONFIG_SYS_SDRAM_SIZE);
	return 0;
}

/* NO dram_init_banksize() !!! */

Note also that the defines have changed to have a CONFIG_SYS_ prefix.
Change your board definition accordingly.

Best Regards,
Reinhard

[U-Boot] {Spam?} u-boot relocation

[Marcel]

On Sunday, December 26, 2010 02:38:04 pm Reinhard Meyer wrote:
> Dear Marcel,
> 
> > Hi,
> > 
> > I updated my u-boot-usb to continue my work on the SAM9 USB parts, but
> > got stuck with the following issue :
> > 
> > There seems to be a new relocation scheme. I also added some stuff to
> > make it detect the SDRAM, but than I get stuck.
> > 
> >   int dram_init(void)
> > 
> > {
> > 
> >          gd->bd->bi_dram[0].start = PHYS_SDRAM;
> >          gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
> 
> This is accessing bss before relocation. BSS does not exist then.

At what point bss does exist ?
Forgive me for not having a clue on this. I started working on u-boot to make 
USB working a while ago. I almost had that working but unfortunately had to go 
away for a while for business. Now that I can continue I usually first update 
to keep up with the latest things, but this is not always easy if things break 
completely.

> >          /* dram_init must store complete ramsize in gd->ram_size */
> >          gd->ram_size = get_ram_size((volatile void *)PHYS_SDRAM,
> > 
> > PHYS_SDRAM_SIZE);
> > 
> >          dram_init_banksize();
> 
> This function, if defined, is called automagically. Normally, with single
> DRAM bank AT91SAM9 designs the default weak function provided by u-boot is
> sufficient:
> void __dram_init_banksize(void)
> {
> 	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> 	gd->bd->bi_dram[0].size =  gd->ram_size;
> }
> void dram_init_banksize(void)
> 	__attribute__((weak, alias("__dram_init_banksize")));
> 
> Don't define this function in your board file!!!

I got rid of the call in my board file.

> >          return 0;
> > 
> > }
> 
> Please have a look at the emk/top9000 board for what is needed:
> 
> int dram_init(void)
> {
> 	gd->ram_size = get_ram_size(
> 		(void *)CONFIG_SYS_SDRAM_BASE,
> 		CONFIG_SYS_SDRAM_SIZE);
> 	return 0;
> }
> 
> /* NO dram_init_banksize() !!! */
> 
> Note also that the defines have changed to have a CONFIG_SYS_ prefix.
> Change your board definition accordingly.
> 
> Best Regards,
> Reinhard

I currently only have this : 
int dram_init(void)
{
	gd->ram_size = get_ram_size(
		(void *)CONFIG_SYS_SDRAM_BASE,
		CONFIG_SYS_SDRAM_SIZE);
	return 0;
}

I defined CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_SDRAM_SIZE but I gave them the 
same address and size as my previous PHYS_SDRAM and PHYS_SDRAM_SIZE.

It doesn't change anything so far, so I must have missed some things I guess.
I'll continue reading and hope I find something. I do however feel  like I'm 
wasting my time on this one.

Thanks for your reply,
Marcel

[U-Boot] {Spam?} u-boot relocation

[Reinhard Meyer]

Dear Marcel,
> On Sunday, December 26, 2010 02:38:04 pm Reinhard Meyer wrote:
>> Dear Marcel,
>>
>>> Hi,
>>>
>>> I updated my u-boot-usb to continue my work on the SAM9 USB parts, but
>>> got stuck with the following issue :
>>>
>>> There seems to be a new relocation scheme. I also added some stuff to
>>> make it detect the SDRAM, but than I get stuck.
>>>
>>>    int dram_init(void)
>>>
>>> {
>>>
>>>           gd->bd->bi_dram[0].start = PHYS_SDRAM;
>>>           gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
>>
>> This is accessing bss before relocation. BSS does not exist then.
>
> At what point bss does exist ?
After Relocation.
> Forgive me for not having a clue on this. I started working on u-boot to make
> USB working a while ago. I almost had that working but unfortunately had to go
> away for a while for business. Now that I can continue I usually first update
> to keep up with the latest things, but this is not always easy if things break
> completely.
>
>>>           /* dram_init must store complete ramsize in gd->ram_size */
>>>           gd->ram_size = get_ram_size((volatile void *)PHYS_SDRAM,
>>>
>>> PHYS_SDRAM_SIZE);
>>>
>>>           dram_init_banksize();
>>
>> This function, if defined, is called automagically. Normally, with single
>> DRAM bank AT91SAM9 designs the default weak function provided by u-boot is
>> sufficient:
>> void __dram_init_banksize(void)
>> {
>> 	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
>> 	gd->bd->bi_dram[0].size =  gd->ram_size;
>> }
>> void dram_init_banksize(void)
>> 	__attribute__((weak, alias("__dram_init_banksize")));
>>
>> Don't define this function in your board file!!!
>
> I got rid of the call in my board file.
>
>>>           return 0;
>>>
>>> }
>>
>> Please have a look at the emk/top9000 board for what is needed:
>>
>> int dram_init(void)
>> {
>> 	gd->ram_size = get_ram_size(
>> 		(void *)CONFIG_SYS_SDRAM_BASE,
>> 		CONFIG_SYS_SDRAM_SIZE);
>> 	return 0;
>> }
>>
>> /* NO dram_init_banksize() !!! */
>>
>> Note also that the defines have changed to have a CONFIG_SYS_ prefix.
>> Change your board definition accordingly.
>>
>> Best Regards,
>> Reinhard
>
> I currently only have this :
> int dram_init(void)
> {
> 	gd->ram_size = get_ram_size(
> 		(void *)CONFIG_SYS_SDRAM_BASE,
> 		CONFIG_SYS_SDRAM_SIZE);
> 	return 0;
> }
>
> I defined CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_SDRAM_SIZE but I gave them the
> same address and size as my previous PHYS_SDRAM and PHYS_SDRAM_SIZE.
Give them the *correct* values; however I assume they are correct.

CONFIG_SYS_TEXT_BASE must be set to the address u-boot is loaded to by the initial
bootstrap (or directly the NOR address if it is starting from there).

U-boot will relocate itself to top of RAM. Therefore CONFIG_SYS_TEXT_BASE should
not be near top of RAM to avoid overlap.
>
> It doesn't change anything so far, so I must have missed some things I guess.
> I'll continue reading and hope I find something. I do however feel  like I'm
> wasting my time on this one.

I have the same frustration sometimes, however changes are not done to frustrate
people but to make things better and more straightforward. Progress sometimes
means making significant changes to get rid of ballast...

Best Regards,
Reinhard

[U-Boot] {Spam?} u-boot relocation

[Marcel]

On Sunday, December 26, 2010 09:10:13 pm Reinhard Meyer wrote:
> > I defined CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_SDRAM_SIZE but I gave them
> > the same address and size as my previous PHYS_SDRAM and PHYS_SDRAM_SIZE.
> 
> Give them the *correct* values; however I assume they are correct.
> 
> CONFIG_SYS_TEXT_BASE must be set to the address u-boot is loaded to by the
> initial bootstrap (or directly the NOR address if it is starting from
> there).

I guess that's the case because bootstrap boots u-boot.

> U-boot will relocate itself to top of RAM. Therefore CONFIG_SYS_TEXT_BASE
> should not be near top of RAM to avoid overlap.

Since I don't understand this, I guess there may be more to this.
In my case CONFIG_SYS_TEXT_BASE is 0x73F00000

I get this :

 U-Boot 2010.12-09749-g8da60f4-dirty (Dec 26 2010 - 20:44:27)

U-Boot code: 73F00000 -> 73F3F7AC  BSS: -> 73F51B8C
CPU: AT91SAM9G45
Crystal frequency:       12 MHz
CPU clock        :      400 MHz
Master clock     :  133.333 MHz
monitor len: 00051B8C
ramsize: 08000000
TLB table at: 77ff0000
Top of RAM usable for U-Boot at: 77ff0000
Reserving 326k for U-Boot at: 77f9e000
Reserving 384k for malloc() at: 77f3e000
Reserving 24 Bytes for Board Info at: 77f3dfe8
Reserving 144 Bytes for Global Data at: 77f3df58
New Stack Pointer is: 77f3df50
RAM Configuration:
Bank #0: 70000000 128 MiB
relocation Offset is: 0409e000

How is 0409e000 near top of my RAM ?
How does it get this value ?


> > It doesn't change anything so far, so I must have missed some things I
> > guess. I'll continue reading and hope I find something. I do however
> > feel  like I'm wasting my time on this one.
> 
> I have the same frustration sometimes, however changes are not done to
> frustrate people but to make things better and more straightforward.
> Progress sometimes means making significant changes to get rid of
> ballast...
> 
> Best Regards,
> Reinhard

I know changes are for the better and that's why I try to keep in line with 
git. It's not always easy as I travel a lot and sometimes there are 2-3 months 
between updates. That's sometimes so long that things get broken, like this 
time.

Since I follow the list only when I' back in my home county I miss out a great 
deal of the communication. I just update from git and hope for the best and 
start working from there. I probably was quite unfortunate with my timing this 
time.

Thanks for your reply. I'm not sure yet if I get things correct but any clue 
certainly helps.

Best regards,
Marcel

[U-Boot] {Spam?} u-boot relocation

[Albert ARIBAUD]

Le 26/12/2010 22:09, Marcel a ?crit :

> relocation Offset is: 0409e000
>
> How is 0409e000 near top of my RAM ?
> How does it get this value ?

This is an offset, a difference of addresses, not an absolute address. 
And since it is rather big, it means the original and relocated 
locations are far enough from each other.

Amicalement,
-- 
Albert.

[U-Boot] {Spam?} u-boot relocation

[Simon Glass]

Hi,

(Is there documentation about this somewhere? - I couldn't find it). I
assume your board is hanging during relocation.

You could try putting this function back (but without the __ prefix)

void dram_init_banksize(void)
{
       gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
       gd->bd->bi_dram[0].size =  gd->ram_size;
}

Regards,
Simon

On Mon, Dec 27, 2010 at 2:02 AM, Albert ARIBAUD <albert.aribaud@free.fr>wrote:

> Le 26/12/2010 22:09, Marcel a ?crit :
>
> > relocation Offset is: 0409e000
> >
> > How is 0409e000 near top of my RAM ?
> > How does it get this value ?
>
> This is an offset, a difference of addresses, not an absolute address.
> And since it is rather big, it means the original and relocated
> locations are far enough from each other.
>
> Amicalement,
> --
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] {Spam?} u-boot relocation

[Marcel]

On Tuesday, December 28, 2010 05:48:20 pm Simon Glass wrote:
> Hi,
> 
> (Is there documentation about this somewhere? - I couldn't find it). I
> assume your board is hanging during relocation.
> 
> You could try putting this function back (but without the __ prefix)
> 
> void dram_init_banksize(void)
> {
>        gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
>        gd->bd->bi_dram[0].size =  gd->ram_size;
> }

Unfortunately no change by doing this, but thanks for the suggestion.

Regards,
Marcel

[U-Boot] {Spam?} u-boot relocation

[Marcel]

On Thursday, December 30, 2010 08:38:36 pm Marcel wrote:
> On Tuesday, December 28, 2010 05:48:20 pm Simon Glass wrote:
> > Hi,
> > 
> > (Is there documentation about this somewhere? - I couldn't find it). I
> > assume your board is hanging during relocation.
> > 
> > You could try putting this function back (but without the __ prefix)
> > 
> > void dram_init_banksize(void)
> > {
> > 
> >        gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> >        gd->bd->bi_dram[0].size =  gd->ram_size;
> > 
> > }
> 
> Unfortunately no change by doing this, but thanks for the suggestion.

I tried gdb, but the output doesn't get me much further. It detects an infinite 
loop, but 

BFD: /arm/u-boot-usb/u-boot: invalid string offset 37 >= 0 for section `'
BFD: /arm/u-boot-usb/u-boot: invalid string offset 1 >= 0 for section `'
BFD: /arm/u-boot-usb/u-boot: invalid string offset 20 >= 0 for section `'
BFD: /arm/u-boot-usb/u-boot: invalid string offset 82 >= 0 for section `'
BFD: /arm/u-boot-usb/u-boot: invalid string offset 67 >= 0 for section `'
BFD: /arm/u-boot-usb/u-boot: invalid string offset 32 >= 0 for section `'
BFD: /arm/u-boot-usb/u-boot: invalid string offset 53 >= 0 for section `'
Remote debugging using localhost:65501
_start () at start.S:56
56              b       reset
Current language:  auto; currently asm
(gdb) c
Continuing.
_start () at start.S:56
56              b       reset
Infinite loop detected       
(gdb)

I have no cpu_init_f, is this normal ?

(gdb) b board_init_f
Breakpoint 1 at 0xe20: file board.c, line 283.
(gdb) b cpu_init_f
Function "cpu_init_f" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

Regards,
Marcel