Compiling flash image suitable for banks A and B?

[lpcware]

Content originally posted in LPCWare by dwjperry on Tue Jan 13 18:05:52 MST 2015
I'm adding IAP support to my application, where a host will upload an image via MODBUS to my LPC43xx-based device. There would be one image which provides both application code and self-programming, rather than a separate bootloader, alternating between flash banks as new firmware images are loaded.

However, one issue I've overlooked is the need for the firmware to be compiled to suit the particular flash bank it resides in. As such I'd need to release an A and B firmware version for each release and choose the right one depending on which bank is currently in use —  not ideal.

Is there a way to generate a common firmware image? Or are there simple and robust changes that can be made to the image in situ to target it towards a particular flash bank?

[lpcware]

Content originally posted in LPCWare by ashgupta28 on Tue Jun 30 06:34:49 MST 2015
Thanks,

Actually i want to ask from "dwjperry" if he got any success in this thread that is why i posted here.

Ashish

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jun 30 05:28:42 MST 2015
Please read the answer I recently posted to your other thread. Please do not duplicate questions in different threads.

[lpcware]

Content originally posted in LPCWare by ashgupta28 on Tue Jun 30 01:52:02 MST 2015
Hello dwjperry,

I am looking to generate the Binary from LPCXpresso that can be loaded into the Bank A @0x1A000000. But also be loaded into Bank B @0x1B000000. Currently we can change the setting in LPCXpresso to generate the binary either for Bank A or Bank B. SO Bank B binary cannot be loaded into Bank A.

How to generate the image that could be placed in either bank A or B ? Please suggest

Thanks in advance,
Ashish Gupta

[lpcware]

Content originally posted in LPCWare by dwjperry on Fri Jan 16 15:59:49 MST 2015
Thanks, I will investigate further, but use separate images (or a diff between them) to unblock me for now.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Jan 16 02:25:16 MST 2015
In my first reply, I said you need position independent code and data... But when you do this, you need to fix-up your image (so it knows where it is running) and (I think) to do this, your loader will need to read the ELF (axf) file which tells you what needs fixing up in the GOT (global offset table) - i.e. you can't use a binary image.

Search for "ARM position independent code with GCC"

[lpcware]

Content originally posted in LPCWare by dwjperry on Thu Jan 15 19:14:27 MST 2015
That's just the phrase I was looking for. The -fPIC option seems to be what I was looking for, however the resulting images (targeted at banks A or B) still seem to differ, so I take that to mean that it's not completely supported in the M4? The differences appear to be fewer, however (~700 vs. 1000).

[lpcware]

Content originally posted in LPCWare by starblue on Thu Jan 15 02:38:16 MST 2015
Have you tried generating position independent code (should be doable with some command line options to the compiler)?

[lpcware]

Content originally posted in LPCWare by dwjperry on Thu Jan 15 01:43:14 MST 2015
I'm not proposing a straight search and replace. The results of that would be...interesting. :-)

I'm proposing calculating a binary patch between the A and B images, and sending that patch along with one of the images so that the other can be derived. A simple implementation would a list of image offsets where the value can be flipped, along with checks to make sure that only 0x1A <-> 0x1B changes are required, and a checksum for good measure.

It would be interesting to know the original design rationale for the LPC4300 flash map and boot process. Was it intended that two not-quite-identical images would be used in each bank, flipping between them to do firmware updates (as I'm proposing)? Or was one just intended for holding the bootloader (even though you'd have the same space available as the application code, bit overkill). Or just a clear separation between code intended for the M4 and M0 cores? 

[lpcware]

Content originally posted in LPCWare by LessThanZero on Wed Jan 14 21:39:05 MST 2015

Replacing all the 0x1A bytes for 0x1B is naive, and fraught with risk. It's almost certain you'd replace a 0x1A byte in some instruction (or data). This results in a crash if you're lucky, and unpredictable behavior if you're not. If you don't want to do the fixups, compile 2 separate images.

[lpcware]

Content originally posted in LPCWare by dwjperry on Wed Jan 14 21:12:55 MST 2015
Thanks, that makes sense.

Given the complexity of the file format, how about a naive approach? Doing a binary diff on images compiled for banks A vs B revealed about 1000 changes for a ~190kB image size, all appear to be simply swapping 0x1A for 0x1B (i.e. the upper address byte of the flash banks).

I could send an image targeted at bank A, and then a binary patch (rather than the full image) to target it at B, all wrapped in an appropriate structure with checksums etc. My main concern is reducing the amount of data to be sent over the wire, so this might be workable.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Wed Jan 14 15:47:43 MST 2015
You need position independent code and data. Your boat loader would need to provide the address fix ups when it is downloading and programming the flash. For example, the vectors would need to be fixed. It is doable but is quite a big job and you are going to need to understand a lot about image formats and address fixups

[lpcware]

Content originally posted in LPCWare by dwjperry on Wed Jan 14 15:26:59 MST 2015
Thanks for the reply, but that doesn't answer my question.

Under what you describe, you'd still need two versions of the flash image (at least that's my understanding). Is there a way around this?

[lpcware]

Content originally posted in LPCWare by bavarian on Wed Jan 14 02:46:35 MST 2015
You can only work with your own boot manager which you put into the first 8kbyte sector of bank #A.
This loader is then managing the rest.

The EEPROM sector could be used to indicate which image is the valid one.

Regards,
NXP Support Team.