[U-Boot-Users] [PATCH] 83xx: Put the version (and magic) after the HRCW.
Put the version (and magic) after the HRCW. This puts it in a fixed location in flash, not at the start of flash but as close as we can get.
Signed-off-by: Jerry Van Baren vanbaren@cideas.com
Put the version (and magic) after the HRCW. This puts it in a fixed location in flash, not at the start of flash but as close as we can get.
Signed-off-by: Jerry Van Baren vanbaren@cideas.com --- cpu/mpc83xx/start.S | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S index 0f27bb6..6ee9ec9 100644 --- a/cpu/mpc83xx/start.S +++ b/cpu/mpc83xx/start.S @@ -77,19 +77,11 @@ END_GOT
/* - * Version string - must be in data segment because MPC83xx uses the - * first 256 bytes for the Hard Reset Configuration Word table (see - * below). Similarly, can't have the U-Boot Magic Number as the first - * thing in the image - don't know how this will affect the image tools, - * but I guess I'll find out soon. + * The Hard Reset Configuration Word (HRCW) table is in the first 64 + * (0x40) bytes of flash. It has 8 bytes, but each byte is repeated 8 + * times so the processor can fetch it out of flash whether the flash + * is 8, 16, 32, or 64 bits wide (hardware trickery). */ - .data - .globl version_string -version_string: - .ascii U_BOOT_VERSION - .ascii " (", __DATE__, " - ", __TIME__, ")" - .ascii " ", CONFIG_IDENT_STRING, "\0" - .text #define _HRCW_TABLE_ENTRY(w) \ .fill 8,1,(((w)>>24)&0xff); \ @@ -100,6 +92,18 @@ version_string: _HRCW_TABLE_ENTRY(CFG_HRCW_LOW) _HRCW_TABLE_ENTRY(CFG_HRCW_HIGH)
+/* + * Magic number and version string - put it after the HRCW since it + * cannot be first in flash like it is in many other processors. + */ + .long 0x27051956 /* U-Boot Magic Number */ + + .globl version_string +version_string: + .ascii U_BOOT_VERSION + .ascii " (", __DATE__, " - ", __TIME__, ")" + .ascii " ", CONFIG_IDENT_STRING, "\0" +
#ifndef CONFIG_DEFAULT_IMMR #error CONFIG_DEFAULT_IMMR must be defined
Jerry Van Baren wrote:
Put the version (and magic) after the HRCW. This puts it in a fixed location in flash, not at the start of flash but as close as we can get.
Signed-off-by: Jerry Van Baren vanbaren@cideas.com
The git repository with my patches is at: http://www.cideas.us/cgi-bin/gitweb.cgi Actual repository: http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-mpc83xx;a=summary
Branches: * version-in-text - Put the version (and magic) after the HRCW. * lowboot - Add high/lowboot configuration to the Makefile, etc.
gvb
Jerry Van Baren gerald.vanbaren@comcast.net wrote:
Put the version (and magic) after the HRCW. This puts it in a fixed location in flash, not at the
start
of flash but as close as we can get.
Nice effort. Space saving and better version check.
I guess the same change could apply for MPC8260/47/8.
Thanks,
Sam
___________________________________________________________ 抢注雅虎免费邮箱-3.5G容量，20M附件！ http://cn.mail.yahoo.com
Sam Song wrote:
Jerry Van Baren gerald.vanbaren@comcast.net wrote:
Put the version (and magic) after the HRCW. This puts it in a fixed location in flash, not at the
start
of flash but as close as we can get.
Nice effort. Space saving and better version check.
I guess the same change could apply for MPC8260/47/8.
Thanks,
Sam
Yes. Most boards have the version in the first bytes of flash, but this was not possible on the 82xx because of the HRCW, so it was put in .data. This set up was copied for the 83xx (which also has a HRCW). My change moves it back to .text just after the HRCW. I put also the u-boot magic number back in in honor of Wolfgang. ;-)
If you change the file names in the patch, it probably would apply. :-) I intend to do this (perhaps literally), but ran out of ambition tonight.
Best regards, gvb
Jerry Van Baren wrote:
Sam Song wrote:
Jerry Van Baren gerald.vanbaren@comcast.net wrote:
Put the version (and magic) after the HRCW. This puts it in a fixed location in flash, not at the
start
of flash but as close as we can get.
Nice effort. Space saving and better version check.
I guess the same change could apply for MPC8260/47/8.
Thanks,
Sam
Yes. Most boards have the version in the first bytes of flash, but this was not possible on the 82xx because of the HRCW, so it was put in .data. This set up was copied for the 83xx (which also has a HRCW). My change moves it back to .text just after the HRCW. I put also the u-boot magic number back in in honor of Wolfgang. ;-)
If you change the file names in the patch, it probably would apply. :-) I intend to do this (perhaps literally), but ran out of ambition tonight.
Best regards, gvb
Arrgh, I forgot about the 8260 master + 7 slaves mode, which fills the first 256 bytes with HRCWs. As a result, we cannot put the magic number and version at offset 0x40 like I did with the 8360 (well, we could do it, but only if the system doesn't have slaves). We could, however, put the magic number and version in a different vector area that has room (e.g. offset 0x240).
What we have works and has worked for several years. I don't have enough ambition and interest at this point to change this for the mpc8260.
Best regards, gvb
Jerry Van Baren wrote:
Arrgh, I forgot about the 8260 master + 7 slaves mode, which fills the first 256 bytes with HRCWs. As a result, we cannot put the magic number and version at offset 0x40 like I did with the 8360 (well, we could do it, but only if the system doesn't have slaves). We could, however, put the magic number and version in a different vector area that has room (e.g. offset 0x240).
Or, you could tag the version string with a checksum and a signature, then have the application scan memory until it finds it. That way, you could put it wherever you want, even in different places on different systems, and it would still work.
Joakim asked me to ack or nack this patch, but at this point I can't tell who wants what. Can someone summarize the status of this patch for me?
Timur Tabi wrote:
Jerry Van Baren wrote:
Arrgh, I forgot about the 8260 master + 7 slaves mode, which fills the first 256 bytes with HRCWs. As a result, we cannot put the magic number and version at offset 0x40 like I did with the 8360 (well, we could do it, but only if the system doesn't have slaves). We could, however, put the magic number and version in a different vector area that has room (e.g. offset 0x240).
Or, you could tag the version string with a checksum and a signature, then have the application scan memory until it finds it. That way, you could put it wherever you want, even in different places on different systems, and it would still work.
Joakim asked me to ack or nack this patch, but at this point I can't tell who wants what. Can someone summarize the status of this patch for me?
Hi Timur,
The root post and patch is http://article.gmane.org/gmane.comp.boot-loaders.u-boot/25427 which is a patch for the 83xx and is what Joakim is interested in (tested on the MPC8360EMDS). The posting (above) was a followup. I intended to do an equivalent patch for the 8260, but decided not to due to the level of effort vs. reward.
The git repository with my patches is at: http://www.cideas.us/cgi-bin/gitweb.cgi Actual repository: http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-mpc83xx;a=summary
Branches: * version-in-text - Put the version (and magic) after the HRCW. * lowboot - Add high/lowboot configuration to the Makefile, etc.
Thanks, gvb
Jerry Van Baren wrote:
- version-in-text - Put the version (and magic) after the HRCW.
This patch works on the 8349E-mITX. Ack.
However, there's a caveat. The 8349E-mITX doesn't place the U-Boot image over the HRCW - it's located somewhere else in flash. So the HRCW in the U-Boot image is ignored. This may also be true of some other 83xx boards.
- lowboot - Add high/lowboot configuration to the Makefile, etc.
I haven't tried this patch.
Timur Tabi wrote:
Jerry Van Baren wrote:
- version-in-text - Put the version (and magic) after the HRCW.
This patch works on the 8349E-mITX. Ack.
However, there's a caveat. The 8349E-mITX doesn't place the U-Boot image over the HRCW - it's located somewhere else in flash. So the HRCW in the U-Boot image is ignored. This may also be true of some other 83xx boards.
Hi Timur,
I suspect your 8349E-mITX is configured to "boothigh" (BMS = 1, also known as HRCWH_FROM_0XFFF00100) so the u-boot image starts at 0xFFF00000 rather than at the start of flash (nominally 0xFE000000). In this case you should find the magic and version string starting at 0xFFF00040. Of course, in the .bin/.srec/whatever file, it should be at offset 0x40.
That is one of the advantages of "bootlow" - the HRCW from u-boot is placed at the start of flash and thus is used. With "boothigh" , the HRCW that is part of u-boot is in the "wrong place" and thus is not used. (Another advantage of "bootlow" is that you don't have to dedicate 1MB of flash for the u-boot image.)
Looking at include/configs/MPC8349ITX.h, if PCI_64BIT is defined it does a lowboot, otherwise it does a highboot (which seems odd to me, but people tell me I'm odd and the world is normal).
- lowboot - Add high/lowboot configuration to the Makefile, etc.
I haven't tried this patch.
The "lowboot" patch is specific to the MPC8360EMDS, although it could be copy and pasted into the MPC8349ITX configuration easily enough.
gvb
Jerry Van Baren wrote:
I suspect your 8349E-mITX is configured to "boothigh" (BMS = 1, also known as HRCWH_FROM_0XFFF00100) so the u-boot image starts at 0xFFF00000 rather than at the start of flash (nominally 0xFE000000). In this case you should find the magic and version string starting at 0xFFF00040. Of course, in the .bin/.srec/whatever file, it should be at offset 0x40.
Yes, that's correct.
That is one of the advantages of "bootlow" - the HRCW from u-boot is placed at the start of flash and thus is used. With "boothigh" , the HRCW that is part of u-boot is in the "wrong place" and thus is not used. (Another advantage of "bootlow" is that you don't have to dedicate 1MB of flash for the u-boot image.)
The original code from our BSP had only boothigh, so that's how I left it. I guess I should test lowboot as an option.
Looking at include/configs/MPC8349ITX.h, if PCI_64BIT is defined it does a lowboot, otherwise it does a highboot (which seems odd to me, but people tell me I'm odd and the world is normal).
I've noticed that too, and I'm trying to get answer as to why.
The "lowboot" patch is specific to the MPC8360EMDS, although it could be copy and pasted into the MPC8349ITX configuration easily enough.
Ok, if it gets accepted, I'll port it to the 8349ITX.
participants (4)
-
Jerry Van Baren -
Jerry Van Baren -
Sam Song -
Timur Tabi