Issues with Flashing osimage.elf

Omikron · 2010-02-20 01:47:35

Alright, after spending an entire day debugging almost every step that I've had to complete so far, I've slowly made some progress in getting my PM3 working but I am once again at a brick wall of sorts.

I am currently working off of an r349 environment from the SVN, although I've also tried r317 and had identical results. I've successfully programmed the bootrom using J-Flash and a SAM-ICE adapter from Atmel. Once that was complete, I was able to connect the PM3 to the computer and use the prox client I compiled to successfully program the FPGA image. Unfortunately, try as I might I am unable to do anything with the OS image. When I try to use the prox client to write the data, here is the behavior that I observe:

C:\prox-dev\proxmark\client>prox os ..\armsrc\obj\osimage.elf
Flashing os from ..\armsrc\obj\osimage.elf
count=3 phoff=34
type=1 offset=0 paddr=100000 vaddr=108000 filesize=1df7e memsize=1df7e flags=7 align=8000
flashing offset=0 paddr=100000 size=1df7e
skipping forward 0x2000 because of strange linker thing
WriteBlock(102000, 256, 00 00 00 00 00 00 00 00 ... 00 00 00 00 00 00 00 00)
bad ACK

Attempting to manually program the image via J-Flash also results in the following error:

It seems to me that there is something wrong with the file being compiled. Does anyone have any thoughts or advice for resolution?

Last edited by Omikron (2010-02-20 03:10:49)

Omikron · 2010-02-20 02:50:21

Investigating the issue further, it seems that the issue at hand is related to how osimage.elf is compiled. There's a great deal of garbage data added to the end of the file. So much so, that it's too large to fit into the target's flash which is why J-Flash rejects it. I can only assume that this is why the prox client also rejects the image.

iZsh · 2010-02-20 04:12:37

Could you clarify?

Omikron · 2010-02-20 07:17:36

iZsh wrote:

Could you clarify?

Sure.

For reference, I'm currently compiling from SVN 351.

Here's the beginning of the file as loaded in J-Flash:

Here's the end of the actual OS image data:

Here's the end of the osimage.s19 file:

Note the ending address. This may not be why the prox client is rejecting the flash, but it's definitely why J-Flash rejects it. I figured they were related somehow.

Last edited by Omikron (2010-02-20 07:18:15)

d18c7db · 2010-02-20 10:32:39

Not sure what's going on there but a S19 file should be a pure text file, not containing binary data like in your screen shots.

Here's the beginning of my osimage.s19 viewed in a text editor (rev 317)

S01200006F626A2F6F73696D6167652E73313993
S31500010000F0B557464646C0B4354E364886422AD2E2
S315000100100323321C1A400421891A851B1940A9425F

and here's the end

S315000253187847C046ADFAFFEA7847C0465AFAFFEA26
S315000253287847C0463FEAFFEA7847C046EADDFFEA21
S309001253380100000058
S70500110001E8

unless your software parses the S19 files and shows the data contained within as a binary.

Here's me flashing r317

..\client\prox.exe os ..\armsrc\obj\osimage.elf
Flashing os from ..\armsrc\obj\osimage.elf
count=4 phoff=34
type=1 offset=0 paddr=0 vaddr=0 filesize=b4 memsize=b4 flags=6 align=8000
type=1 offset=8000 paddr=110000 vaddr=110000 filesize=15338 memsize=15338 flags=5 align=8000
flashing offset=8000 paddr=110000 size=15338
WriteBlock(110000, 256, f0 b5 57 46 46 46 c0 b4 ... f0 b5 5f 46 56 46 4d 46)
WriteBlock(110100, 256, 44 46 f0 b4 91 b0 0b 90 ... 02 9e 40 42 76 42 01 96)
WriteBlock(110200, 256, 02 90 00 9e d8 7b 83 46 ... 20 1c 3c bc 90 46 99 46)
...etc...
WriteBlock(125100, 256, 67 2c 20 67 6f 74 20 25 ... 20 74 6f 20 31 35 00 00)
WriteBlock(125200, 256, 53 79 73 74 65 6d 20 61 ... 78 47 c0 46 e9 fa ff ea)
WriteBlock(125300, 56, 78 47 c0 46 1d fa ff ea ... ff ff ff ff ff ff ff ff)
type=1 offset=20000 paddr=125338 vaddr=200000 filesize=4 memsize=8058 flags=6 align=8000
flashing offset=20000 paddr=125338 size=4
WriteBlock(125338, 4, 01 00 00 00 ff ff ff ff ... ff ff ff ff ff ff ff ff)
moving stuff forward by 56 bytes
type=1 offset=27fe0 paddr=20ffe0 vaddr=20ffe0 filesize=0 memsize=10 flags=6 align=8000

done.

Last edited by d18c7db (2010-02-20 10:55:15)

d18c7db · 2010-02-20 11:14:26

Actually I just noticed that the elf flasher behaviour is stil broken resulting in incorrect firmware updates, the last WriteBlock at address 125338 shouldn't happen as it erases the block starting at address 125300 resulting in a constantly rebooting board. Flashing the S19 file through other means correctly updates the firmware so I suggest you use the S19 files.

Omikron · 2010-02-20 13:19:10

d18c7db wrote:

Actually I just noticed that the elf flasher behaviour is stil broken resulting in incorrect firmware updates, the last WriteBlock at address 125338 shouldn't happen as it erases the block starting at address 125300 resulting in a constantly rebooting board. Flashing the S19 file through other means correctly updates the firmware so I suggest you use the S19 files.

Yes, as you've figured out the J-Flash software imports the Motorola S19 files as binary data and flashes them accordingly. Unfortunately, it still doesn't help out my situation. Last night I used J-Flash to manually delete the address that appeared to be garbage, and flashed it directly via JTAG.

The behavior observed was a constantly rebooting board:

1. ALL LED On
2. Red/Orange On (Bootloader)
3. Reboot

During this time the board doesn't detect as any type of USB device in Windows at all, unless I hold down the button during boot and keep it in the bootloader. When I just have the bootloader and FPGA image flashed I don't have the rebooting problem and Windows and the prox client detect the PM3 just fine.

d18c7db · 2010-02-20 21:27:23

A few observations: your application seems to display the S19 file in little endian format, I hope it not wrongly byeswapping the file before flashing, secondly, what you have circled as the end of the OS image data is in fact not the end. After what looks like a byte swapped date string there should be one more sector of data. In my experience, if that sector isn't flashed you end up with a dead or rebooting PM3.

I also note that the software you use seems to go on and on after the end of the data until it reaches an address that matches the end of data address plus an offset of 10000. Perhaps your software expects the S19 to contain actual addresses ? The current S19 contains addresses relative to 100000, so the first address in the S19 file of 10000 is actually address 110000 and last address of roughly 25300 is address 125300. These are all hex numbers.

Would you be able to use some other software to flash the card? Perhaps look into OpenOCD or the ArmPgm software in the files section?

Last edited by d18c7db (2010-02-20 21:28:25)

Omikron · 2010-02-20 22:51:16

d18c7db wrote:

A few observations: your application seems to display the S19 file in little endian format, I hope it not wrongly byeswapping the file before flashing, secondly, what you have circled as the end of the OS image data is in fact not the end. After what looks like a byte swapped date string there should be one more sector of data. In my experience, if that sector isn't flashed you end up with a dead or rebooting PM3.
I also note that the software you use seems to go on and on after the end of the data until it reaches an address that matches the end of data address plus an offset of 10000. Perhaps your software expects the S19 to contain actual addresses ? The current S19 contains addresses relative to 100000, so the first address in the S19 file of 10000 is actually address 110000 and last address of roughly 25300 is address 125300. These are all hex numbers.
Would you be able to use some other software to flash the card? Perhaps look into OpenOCD or the ArmPgm software in the files section?

As far as I can tell the AT91SAM7S256 is a chip that uses Little Endian format, which is why it's automatically selected. The user manual for J-Flash states that I can manually select the chip family and choose between Little/Big, but that such a setting is for external flash. This seems to be confirmed by the error message that I get when attempting to switch to Big Endian.

It seems that I should be able to flash the PM3 with the this device and J-Flash, since that's the software Atmel officially endorses, but it could be an issue with the settings as well. How sure are we that the code that compiles the .s19 files is 100% standards compliant?

As far as OpenOCD goes, I was considering trying that until I read it may not work on x64 versions of Windows. Have you had much luck with that?

d18c7db · 2010-02-20 23:28:32

No I don't use x64. Endianness was just something to watch out for, of more concern was that your screen dump of the osimage seemed to miss the last block of data as I said above and also that the size of the image in your program seems to extend from 10000 to 11DF80 which is definitely too big. I'd have expected the range to be either 10000-1DF80 *or* 110000-11DF80, you might want to look into that, perhaps some program settings? I don't use J-Flash so not sure.

The S19 files are standards compliant and I have flashed them successfully with other tools.

Omikron · 2010-02-20 23:44:11

d18c7db wrote:

No I don't use x64. Endianness was just something to watch out for, of more concern was that your screen dump of the osimage seemed to miss the last block of data as I said above and also that the size of the image in your program seems to extend from 10000 to 11DF80 which is definitely too big. I'd have expected the range to be either 10000-1DF80 *or* 110000-11DF80, you might want to look into that, perhaps some program settings? I don't use J-Flash so not sure.
The S19 files are standards compliant and I have flashed them successfully with other tools.

Ultimately what I'm saying is the problem really seems to be more with the file and less with J-Flash. When I load the bootrom.s19 or fpgaimage.s19 files I have no such problems, and the ranges seem appropriately automatically detected and correct.

Here's a screenshot of it loading bootrom.s19:

As you can see it seems to select the ranges automatically based on the file itself.

TomCyber · 2010-02-21 00:04:23

Hi to both of you,

seems like I am just at the same point as Omikron is. For quite a while am trying to flash the os version 317 to my proxmark3. I get the same errors as Omikron discribes:

C:\prox-dev\proxmark_r317\client>prox.exe os ..\armsrc\obj\osimage.elf
Flashing os from ..\armsrc\obj\osimage.elf
count=3 phoff=34
type=1 offset=0 paddr=100000 vaddr=108000 filesize=1ee42 memsize=1ee42 flags=7 align=8000
flashing offset=0 paddr=100000 size=1ee42
skipping forward 0x2000 because of strange linker thing
WriteBlock(102000, 256, 00 00 00 00 00 00 00 00 ... 00 00 00 00 00 00 00 00)
bad ACK

So there seems to be something wrong with the elf-file, indeed?!

I was able to flash the FPGA-elf-file without any problems.

After reading this thread, I have two questions: First - and obvious - one: How can I flash my 317 os in such a decent way as d18c7db showed - or better: How do I compose the elf-file so that it can be decently flashed?! Second question: Do I need to be worried that _if_ flashing works, my proxmark3 will end up in an boot-loop? Since I dont have a flasher board for JTAG flashing this would be quite a pain...

Thanks for your help!

Regards,
Tom

Omikron · 2010-02-21 00:17:09

Thank goodness this isn't isolated to me. Since no one else is having these problems, I'm guessing it's a compiling issue.

d18c7db, what is the current OS/toolchain environment you're compiling under?

TomCyber · 2010-02-21 00:22:27

Exactly that question I have forgotten to ask. Having my information from code.google.com, I installed http://proxmark3.googlecode.com/files/2 … xSpace.zip which seems to be not really up-to-date with the svn repository, since the "devkitWIN" isn't in the path variable anymore.

So maybe there are other - more sublte - differences that result in unflashable elf-files?!

A pointer to the current windows toolchain would indeed be a great help. Thanx!

Omikron · 2010-02-21 01:37:16

TomCyber wrote:

Exactly that question I have forgotten to ask. Having my information from code.google.com, I installed http://proxmark3.googlecode.com/files/2 … xSpace.zip which seems to be not really up-to-date with the svn repository, since the "devkitWIN" isn't in the path variable anymore.
So maybe there are other - more sublte - differences that result in unflashable elf-files?!
A pointer to the current windows toolchain would indeed be a great help. Thanx!

Actually Tom as of the latest SVN pretty much everything in that folder is useless. The devkitARM toolkit included is out of date, devkitWIN is also deprecated, and the source included is quite old.

The Wiki is now officially useless until it gets updated, which I don't have a problem doing myself provided that I figure out how to build a solid environment from scratch and provided that the code base stabilizes some over the next few days.

iZsh · 2010-02-21 01:53:49

It should stabilize now that the code base is the same for the three platform

Proxmark3 community

Announcement

#1 2010-02-20 01:47:35

Issues with Flashing osimage.elf

#2 2010-02-20 02:50:21

Re: Issues with Flashing osimage.elf

#3 2010-02-20 04:12:37

Re: Issues with Flashing osimage.elf

#4 2010-02-20 07:17:36

Re: Issues with Flashing osimage.elf

#5 2010-02-20 10:32:39

Re: Issues with Flashing osimage.elf

#6 2010-02-20 11:14:26

Re: Issues with Flashing osimage.elf

#7 2010-02-20 13:19:10

Re: Issues with Flashing osimage.elf

#8 2010-02-20 21:27:23

Re: Issues with Flashing osimage.elf

#9 2010-02-20 22:51:16

Re: Issues with Flashing osimage.elf

#10 2010-02-20 23:28:32

Re: Issues with Flashing osimage.elf

#11 2010-02-20 23:44:11

Re: Issues with Flashing osimage.elf

#12 2010-02-21 00:04:23

Re: Issues with Flashing osimage.elf

#13 2010-02-21 00:17:09

Re: Issues with Flashing osimage.elf

#14 2010-02-21 00:22:27

Re: Issues with Flashing osimage.elf

#15 2010-02-21 01:37:16

Re: Issues with Flashing osimage.elf

#16 2010-02-21 01:53:49

Re: Issues with Flashing osimage.elf

Board footer