[U-Boot] microblaze: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value (25ddd1fb0a2281b182529afbc8fda5de2dc16d96)

[U-Boot] microblaze: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value (25ddd1fb0a2281b182529afbc8fda5de2dc16d96)

[Michal Simek]

Hi Wolfgang,

I have just found that your patch (in subject) break gd/bd pointer for 
Microblaze. I have done patch which fix it but not sure if is correct.

Microblaze uses small space at the end of ram for gd and bd.

For example:
end of ram   0xd7ff ffff
bd           0xd7ff ffc0
gd           0xd7ff ff80

Your patch uses GENERATED_GBL_DATA_SIZE which is aligned size for 
gb_t(0x40) and caused that bd structure (because it is on higher 
addresses) is moved out of ram because gd is on 0xd7ff ffc0. Actual size 
of bd_t is 0x24 but it is no problem to use 0x40 as aligned size.

The main my point is how should look like position of gd/bd.

Maybe will be worth to take a look at monitor,malloc area and stack.

Microblaze uses:
end of ram
bd 0x40
gd 0x40
monitor area
malloc area
stack (grows down)

Is it OK to use this scheme?

I can easily fix this to previous state but will be good to synchronize 
this across archs.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

[U-Boot] microblaze: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value (25ddd1fb0a2281b182529afbc8fda5de2dc16d96)

[Wolfgang Denk]

Dear Michal,

In message <4D106994.10307@monstr.eu> you wrote:
> 
> Maybe will be worth to take a look at monitor,malloc area and stack.
> 
> Microblaze uses:
> end of ram
> bd 0x40
> gd 0x40
> monitor area
> malloc area
> stack (grows down)
> 
> Is it OK to use this scheme?

Sure. You can basicly define this as you like; the general idea is
described in the README; normally we will reserve (dynamically, i. e.
as needed) space for PRAM, shared log buffer and/or video frame
buffer at the upper end of memory, so I would locate bd and gd and
the rest below that - but you don;t support these features so far for
microblaze, then above is fine.

I just would use sizeof() instead of fixed sizes (which tend to be
wrong sometimes ;-)

> I can easily fix this to previous state but will be good to synchronize 
> this across archs.

If you are looking for a reference, use arch/powerpc/lib/board.c,
starting here:

 394         /*
 395          * Now that we have DRAM mapped and working, we can
 396          * relocate the code and continue running from DRAM.
 397          *
 398          * Reserve memory at end of RAM for (top down in that order):
 399          *  - area that won't get touched by U-Boot and Linux (optional)
 400          *  - kernel log buffer
 401          *  - protected RAM
 402          *  - LCD framebuffer
 403          *  - monitor code
 404          *  - board info struct
 405          */


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
If there are self-made purgatories, then we all have to live in them.
	-- Spock, "This Side of Paradise", stardate 3417.7

[U-Boot] microblaze: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value (25ddd1fb0a2281b182529afbc8fda5de2dc16d96)

[Michal Simek]

Dear Wolfgang,

Wolfgang Denk wrote:
> Dear Michal,
> 
> In message <4D106994.10307@monstr.eu> you wrote:
>> Maybe will be worth to take a look at monitor,malloc area and stack.
>>
>> Microblaze uses:
>> end of ram
>> bd 0x40
>> gd 0x40
>> monitor area
>> malloc area
>> stack (grows down)
>>
>> Is it OK to use this scheme?
> 
> Sure. You can basicly define this as you like; the general idea is
> described in the README; normally we will reserve (dynamically, i. e.
> as needed) space for PRAM, shared log buffer and/or video frame
> buffer at the upper end of memory, so I would locate bd and gd and
> the rest below that - but you don;t support these features so far for
> microblaze, then above is fine.

I hope that we will support some of these feature in near future.

> 
> I just would use sizeof() instead of fixed sizes (which tend to be
> wrong sometimes ;-)

of course. There are some references to asm which needs to be resolve at 
first.

> 
>> I can easily fix this to previous state but will be good to synchronize 
>> this across archs.
> 
> If you are looking for a reference, use arch/powerpc/lib/board.c,
> starting here:
> 
>  394         /*
>  395          * Now that we have DRAM mapped and working, we can
>  396          * relocate the code and continue running from DRAM.
>  397          *
>  398          * Reserve memory at end of RAM for (top down in that order):
>  399          *  - area that won't get touched by U-Boot and Linux (optional)
>  400          *  - kernel log buffer
>  401          *  - protected RAM
>  402          *  - LCD framebuffer
>  403          *  - monitor code
>  404          *  - board info struct
>  405          */
> 

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian