Re: [U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page
Dear Trent Piepho, In message [EMAIL PROTECTED] you wrote: The boot page and reset vector need to be at the absolute address 0xf000 and 0xfffc, respectively, when the CPU boots. ... To handle to both different U-Boot image sizes and flash locations, what we do is take the upper bits of the boot page from the location of .text and the lower bits are taken from the absolute address 0xf000. How many bits to take depends on the size of the flash bank. In effect the upper I would like to point out that it is essential that the code must be able to handle the situation where the flash bank size is unknown at compile time, and becomes known anly at runtime when the flash driver probes the actual flash size on the board. This may be not strictly needed for the Freescale evaluation boards, but it is definitely needed for other boards, and we must be able to handle this. The bss segment should go after the end of the u-boot image. Which is only at the fixed address 0 for platforms that don't remap flash. For those I'm not sure what you mean here. Bss becomes significant only after relocation to RAM. By then, it must be located in a valid RAM area. fixed address 0 is no such valid address. Since this part of the linker script is the same for all mpc85xx targets, maybe it should be placed into an include file instead of duplicated? That would make sense, indeed. - .bootpg ADDR(.text) + 0x7f000 : + __flash_mask = 128M - 1; Does the linker actually understand the 128M notation? Interesting - I didn't know that. But - where is the number coming from? I guess that's a hard-wired flash size for this specific board? This is bad, for two reasons: it means we have to maintain the same data in several places (in the linker script plus in the board config file), and second, we cannot handle boards where several size options exist. Flash bank sizes must not be hard wired. 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: [EMAIL PROTECTED] As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page
On Tue, 14 Oct 2008, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: The boot page and reset vector need to be at the absolute address 0xf000 and 0xfffc, respectively, when the CPU boots. ... To handle to both different U-Boot image sizes and flash locations, what we do is take the upper bits of the boot page from the location of .text and the lower bits are taken from the absolute address 0xf000. How many bits to take depends on the size of the flash bank. In effect the upper I would like to point out that it is essential that the code must be able to handle the situation where the flash bank size is unknown at compile time, and becomes known anly at runtime when the flash driver probes the actual flash size on the board. This is an issue for how the local bus controller is programmed and has nothing to do with my patch. The bss segment should go after the end of the u-boot image. Which is only at the fixed address 0 for platforms that don't remap flash. For those I'm not sure what you mean here. Bss becomes significant only after relocation to RAM. By then, it must be located in a valid RAM area. fixed address 0 is no such valid address. One way to avoid editing the linker script when changing the image size is to *link* u-boot with bss at 0. But that only works for boards that have have *linked* the boot page at 0x_f000, it doesn't work for boards, like mpc8572ds, that link the boot page at 0xefff_f000. The way I find address to link bss at works for all boards. - .bootpg ADDR(.text) + 0x7f000 : + __flash_mask = 128M - 1; Does the linker actually understand the 128M notation? Interesting - I didn't know that. If it didn't understand the notation, I sure wouldn't have tested my patches very well! I'm using this on mpc8572ds hardware now. I tested the other platforms and verified that the u-boot image remains unchanged, as it should. But - where is the number coming from? I guess that's a hard-wired flash size for this specific board? This is bad, for two reasons: it means we have to maintain the same data in several places (in the linker script plus in the board config file), and second, we cannot handle boards where several size options exist. This data doesn't exist in the board config file. The linker scripts already in effect contain this data. I have a calculation that uses the flash bank size. What's there now is the result of a calculation that uses the flash bank size. Change the flash mapping and the result changes. The existing scripts depend on the flash mapping just as much as mine does, if not more. Which is not that much of a dependency really. If you look at the comments to the patch, it's only an issue in certain extreme cases that current don't exist. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page
Dear Trent, in message [EMAIL PROTECTED] you wrote: This data doesn't exist in the board config file. The linker scripts already in effect contain this data. I have a calculation that uses the flash bank size. What's there now is the result of a calculation that uses the flash bank size. Change the flash mapping and the result changes. The existing scripts depend on the flash mapping just as much as mine does, if not more. So how do you handle boards where the flash size is unknown at compile-time? 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: [EMAIL PROTECTED] Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, Day of the Dove, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page
On Tue, 14 Oct 2008, Wolfgang Denk wrote: Dear Trent, in message [EMAIL PROTECTED] you wrote: This data doesn't exist in the board config file. The linker scripts already in effect contain this data. I have a calculation that uses the flash bank size. What's there now is the result of a calculation that uses the flash bank size. Change the flash mapping and the result changes. The existing scripts depend on the flash mapping just as much as mine does, if not more. So how do you handle boards where the flash size is unknown at compile-time? You're talking about how the eLBC is programmed. That has nothing to do with my patches! When someone adds code to dynamically program the local bus controller they'll have to figure out what to do. Probably the same way the CPU boots, by defaulting to an 8MB flash bank and then re-programming it later. Obviously the CPU can't find the size of the flash bank before it boots! Using the wrong bank size doesn't actually make much difference. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page
The boot page and reset vector need to be at the absolute address 0xf000 and 0xfffc, respectively, when the CPU boots. However, their location in the U-Boot image is relative to the address that flash is mapped at. For instance, mpc8572ds maps the 128MB flash boot bank to 0xe800, which means the boot page is at 0xe000 in the U-Boot image. Currently the linker scripts use ADDR(.text) + 0x7f000 to location the boot page, but this only works if .text starts 512kB from the end of the flash window, e.g. TEXT_BASE is 0xeff8 for mpc8572ds. If TEXT_BASE is somewhere else, such as when creating a 256kB image, the boot page will be at the wrong location. To handle to both different U-Boot image sizes and flash locations, what we do is take the upper bits of the boot page from the location of .text and the lower bits are taken from the absolute address 0xf000. How many bits to take depends on the size of the flash bank. In effect the upper bits come from the location of the flash bank in the CPU address space and the lower bits come from the fixed location of the boot page within the flash bank. The bss segment should go after the end of the u-boot image. Which is only at the fixed address 0 for platforms that don't remap flash. For those that do it's somewhere else, e.g. on mpc8572ds it's at 0xf000. The easiest way to locate bss is to say it starts 4k after the boot page, since we already put that in the final 4k of the image. Since this part of the linker script is the same for all mpc85xx targets, maybe it should be placed into an include file instead of duplicated? Signed-off-by: Trent Piepho [EMAIL PROTECTED] --- board/freescale/mpc8536ds/u-boot.lds | 11 +-- board/freescale/mpc8540ads/u-boot.lds | 11 +-- board/freescale/mpc8541cds/u-boot.lds | 11 +-- board/freescale/mpc8544ds/u-boot.lds | 12 ++-- board/freescale/mpc8548cds/u-boot.lds | 11 +-- board/freescale/mpc8555cds/u-boot.lds | 11 +-- board/freescale/mpc8560ads/u-boot.lds | 11 +-- board/freescale/mpc8568mds/u-boot.lds | 11 +-- board/freescale/mpc8572ds/u-boot.lds | 11 +-- 9 files changed, 46 insertions(+), 54 deletions(-) diff --git a/board/freescale/mpc8536ds/u-boot.lds b/board/freescale/mpc8536ds/u-boot.lds index 901f633..05c8d4d 100644 --- a/board/freescale/mpc8536ds/u-boot.lds +++ b/board/freescale/mpc8536ds/u-boot.lds @@ -118,21 +118,20 @@ SECTIONS . = ALIGN(256); __init_end = .; - .bootpg ADDR(.text) + 0x7f000 : + __flash_mask = 128M - 1; + .bootpg (ADDR(.text) ~(__flash_mask)) | (0xf000 __flash_mask) : { cpu/mpc85xx/start.o(.bootpg) } :text = 0x - .resetvec ADDR(.text) + 0x7fffc : + .resetvec ADDR(.bootpg) + 0xffc : { *(.resetvec) } :text = 0x - . = ADDR(.text) + 0x8; - - __bss_start = .; - .bss (NOLOAD) : + .bss ADDR(.bootpg) + 0x1000 (NOLOAD) : { + __bss_start = ABSOLUTE(.); *(.sbss) *(.scommon) *(.dynbss) *(.bss) diff --git a/board/freescale/mpc8540ads/u-boot.lds b/board/freescale/mpc8540ads/u-boot.lds index 515d320..2148e12 100644 --- a/board/freescale/mpc8540ads/u-boot.lds +++ b/board/freescale/mpc8540ads/u-boot.lds @@ -121,21 +121,20 @@ SECTIONS . = ALIGN(256); __init_end = .; - .bootpg ADDR(.text) + 0x7f000 : + __flash_mask = 16M - 1; + .bootpg (ADDR(.text) ~(__flash_mask)) | (0xf000 __flash_mask) : { cpu/mpc85xx/start.o(.bootpg) } :text = 0x - .resetvec ADDR(.text) + 0x7fffc : + .resetvec ADDR(.bootpg) + 0xffc : { *(.resetvec) } :text = 0x - . = ADDR(.text) + 0x8; - - __bss_start = .; - .bss (NOLOAD) : + .bss ADDR(.bootpg) + 0x1000 (NOLOAD) : { + __bss_start = ABSOLUTE(.); *(.sbss) *(.scommon) *(.dynbss) *(.bss) diff --git a/board/freescale/mpc8541cds/u-boot.lds b/board/freescale/mpc8541cds/u-boot.lds index d728d8b..13ec8bf 100644 --- a/board/freescale/mpc8541cds/u-boot.lds +++ b/board/freescale/mpc8541cds/u-boot.lds @@ -118,21 +118,20 @@ SECTIONS . = ALIGN(256); __init_end = .; - .bootpg ADDR(.text) + 0x7f000 : + __flash_mask = 8M - 1; /* Flash bank is 8 MB */ + .bootpg (ADDR(.text) ~(__flash_mask)) | (0xf000 __flash_mask) : { cpu/mpc85xx/start.o(.bootpg) } :text = 0x - .resetvec ADDR(.text) + 0x7fffc : + .resetvec ADDR(.bootpg) + 0xffc : { *(.resetvec) } :text = 0x - . = ADDR(.text) + 0x8; - - __bss_start = .; - .bss (NOLOAD) : + .bss ADDR(.bootpg) + 0x1000 (NOLOAD) : { + __bss_start = ABSOLUTE(.); *(.sbss) *(.scommon) *(.dynbss) *(.bss) diff --git a/board/freescale/mpc8544ds/u-boot.lds b/board/freescale/mpc8544ds/u-boot.lds index a05ece5..10a333b 100644 --- a/board/freescale/mpc8544ds/u-boot.lds +++ b/board/freescale/mpc8544ds/u-boot.lds @@ -118,21 +118,21 @@ SECTIONS . = ALIGN(256); __init_end = .; -