Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Is anyone else using the yagarto cross compiler (gcc 4.4.1 based)? I had that set up under Eclipse and have been using it forever now, except the latest SVN now has issues with it.
The code compiles fine, no errros but after flashing the board all sorts of weirdness ensues. More often than not, the board appears to boot but isn't recognized as a valid device, or watching the led boot sequence it appears the board boots twice in quick succession (yellow-red, then the other red which indicates FPGA init, then that same sequence again...) after which the board fails to respond. If the board ever comes up it will most often reset after a while. This all goes away when compiled with -O0 so I can't really debug what the issue is.
Now the same exact source compiled with devkitARM r18 (gcc 4.1.0 based) works fine. If I back out to SVN r290 then all is well again with yagarto and I have a rock solid board, no issues. Seems the new dbprintf most likely caused it but I don't know why. I've also use the latest devkitARM r27 (gcc 4.4.2 based) and all is well too, it's just yagarto and latest SVN with full optimization on...
Offline
Bushing, what sort of compile environment do you use? Does the latest SVN run OK for you when flashed to the PM3.
I've tested the following compilers
devkitARM r18 (gcc 4.1.0) <- this is the defacto default in 2009.09.05.ProxSpace.zip
devkitARM r27 (gcc 4.4.2)
yagarto-bu-2.19.1_gcc-4.4.1
yagarto-bu-2.20_gcc-4.4.2
The code compiles without errors in all of the above, however with devkitARM r18 the elf won't flash due to error:
Flashing os from ..\armsrc\obj\osimage.elf
count=3 phoff=34
flashing offset=0 paddr=100000 size=23fa2
skipping forward 0x2000 because of strange linker thing
WriteBlock(102000, 256, 004991B8)
bad ACK block 00102000
This doesn't occur with code compiled with the others, so it's probably related to the early gcc version.
Additionally compiling the latest SVN with the other compilers and flashing the code results in a dead board, it doesn't appear on the USB bus, often it seems to boot and just sits there then reboots presumably due to watchdog reset.
However if I check out SVN 290 then manually incorporate all the changes up to 307 _except_ the dbprintf, ie the new printf code isn't compiled in and no dbpstring or dbpinteger are replaced with dbprintf, then I again have a stable running PM3, so I'm fairly positive something printf related is creating the issue or I'm doing something wrong.
Has anyone else flashed the latest SVN, if so what was the result? We need some feedback here, thanks.
Offline
This basically sounds like a stack overflow issue: If something dies after adding a large and complex function, it's basically always the stack's fault. Look at armsrc/obj/fullimage.map to see how much ram is being used/is free and try to decrease the size of BigBuf, which should decrease ram usage and allow for more stack usage.
Offline
Yep, I seem to have come across three distinct problems.
1) Stack overflow, as you described. I decreased the size of the BigBuff and most Dbprintf related issues went away.
2) Some more weirdness with Dbprintf, specifically in the ReadMem() function, Dbprintf really _really_ hated being called with 9 DWORD arguments, so I turned them into BYTE arguments (except for the address which remains DWORD)
3) Finally, and by far the bigest cause of hangs was the new elf flash loader. It seems it sometimes causes the very last buffer not to be written to flash properly.
For example, when writing osimage.s19 with the old flasher then reading the last sector written I get:
> mdw 0x124900 64
0x00124900: 46c04778 eafff04c 46c04778 eafff074 46c04778 eafff569 46c04778 eafff5ec
0x00124920: 46c04778 eaffd85d 46c04778 eaffdfae 46c04778 eafff51c 46c04778 eaffd9a5
0x00124940: 46c04778 eafff5ae 46c04778 eaffd82e 46c04778 eaffd545 46c04778 eaffe885
0x00124960: 46c04778 eaffd841 46c04778 eaffd7c7 46c04778 eafff20e 46c04778 eaffe31c
0x00124980: 46c04778 eaffe7ba 46c04778 eaffec30 46c04778 eaffd78c 46c04778 eafff05a
0x001249a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x001249c0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x001249e0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff But when using the new elf flasher I get:
> mdw 0x124900 64
0x00124900: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x00124920: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x00124940: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x00124960: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x00124980: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x001249a0: 00200154 00000001 7ffdf000 0022fd2c 77c4311b 77c3a52e 77c61b78 0022fd38
0x001249c0: 77c3b991 00000011 0022fd78 77c418cd 00000001 77c5fca0 77c418bf 0022fee0
0x001249e0: 0022fea0 7ffdf000 0000002f 00000001 0022fd4c 00000000 0022ffe0 77c35c94 This is basically caused by the fact that the osimage.elf image has 2 sections in it, the fist section is the image proper which is initially written correctly to flash, then it has another section 8 bytes long starting apparently at address 0x1249a0.
type=1 offset=20000 paddr=1249a0 vaddr=200000 filesize=8 memsize=7f5c flags=6 align=8000
flashing offset=20000 paddr=1249a0 size=8
The flasher should probably ignore this last section but it oblingingly writes it by creating a blank sector (0xff) and adding the 8 bytes offset by the correct amount (followed by a bunch of junk probably containing old buffer data) and writing that sector to 0x124900 overwriting the last (correct) sector data from 0x124900 to 0x1249a0 which in fact should have been preserved.
Last edited by d18c7db (2010-01-10 04:36:54)
Offline