[U-Boot] microblaze: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value (25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
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
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
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
participants (2)
-
Michal Simek -
Wolfgang Denk