I have not switched high/low boot in quite a while so I'm not really qualified on the TEXT_BASE and CFG_MONITOR_BASE issue. Sorry for not being more helpful.

What I was pointing out is that your build will put the HRCW at 0xfff00000 (as you observed), but that is NOT where the HRCW lives UNLESS your flash chip is EXACTLY 1MB. That is the dark side of high-boot: the HRCW is not at a nice neat location relative to the reset vector (0xfff00100). The bright side of high boot is that you can program the HRCW once and it will live forever because you won't be erasing its block when loading a new u-boot. One of the most awkward programming errors is to erase the HRCW and not replace it properly because now you have to assert RST_CONFIG and power cycle to recover.

Incidentally, you didn't identify your processor. I'm assuming a 82xx processor because that is what I know best :-).

gvb

-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of mblack@mantaro.com Sent: Friday, July 09, 2004 9:43 AM To: u-boot-users@lists.sourceforge.net Subject: RE: [U-Boot-Users] moving u-boot to upper address

Thanks for the input but not according to my S19 file or my flash programmer... but thats not really what I am concerned with. I understand that the flash space isn't defined until OR0/BR0 are config'd. I will deal with HRCW later. What I want is my code to live and run in the absolute address 0xfff00000 region. Has what I have pointed out done that or is there more... was that the right way to do it?

Thanks,

Mitch

Original Message:

From: VanBaren, Gerald (AGRE) Gerald.VanBaren@smiths-aerospace.com Date: Fri, 9 Jul 2004 07:16:51 -0600 To: mblack@smtp3.smiths.com, at@smtp3.smiths.com, mantaro@smtp3.smiths.com, dot@smtp3.smiths.com, com@smtp3.smiths.com, u-boot-users@lists.sourceforge.net Subject: RE: [U-Boot-Users] moving u-boot to upper address

HRCW is ALWAYS at the START of your flash (assuming your flash is less than 16MB -- in that case, it is at 0xfe000000). The HRCW will be at 0xfff00000 ONLY if your flash is exactly 1MB.

Strictly speaking, the HRCW does not have any address: the processor asserts CS0 and reads the HRCW from offsets 0..31 in whatever memory is enabled when CS0 is asserted. It isn't until OR0/BR0 is configured (which is part of what is controlled by the HRCW) that you can talk about addresses.

gvb

...

-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of mblack@mantaro.com Sent: Friday, July 09, 2004 8:46 AM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] moving u-boot to upper address

...

...

I want u-boot to live in the upper boot area 0xfff00000.

...

So I have

...

...

undef'd _BOOT_LOW changed TEXT_BASE to be 0xfff00000 changed CFG_MONITOR_BASE to be TEXT_BASE

...

I realize that the HRCW will now be placed at 0xfff00000 and

...

the actual code will begin at 0xfff00100 - this is okay, I will handle the HRCW seperatly.

...

I just want to know if there is anything wrong with what I

...

have done or if there is anything else I need to do? There are, as you know, many dependancies and I am afraid I might have missed one.

...

I am dealing with custom hardware and I don't have a hardware

...

debugger - lots of flash and crash so I am not exactly sure where my

problem is.

...

...

Thanks!

...

Mitch

****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************