Proxmark3 community

TomCyber

Member

Registered: 2010-02-15

Posts: 10

Boot loop after flashing

Hi folks,

today I have flashed my Proxmark3 with the latest elf file (Rev 380) and the freshly compiled flasher unter Linux. I did this procedure quite frequently during the last few days and there were never any problems.

This time, after flashing the osimage.elf my Proxmark3 enters an infinite boot loop and there is no chance to access the board through proxmark3, flasher, etc.

1. Why did this happen?
2. What can I do to get my board working again.

Ad 1: I have changed my ARM devkit to the newest release 4.4.2 (which I thought was recommended)?!
Ad 2: I have no JTAG equipment - do I need to get it in order to reflash the Proxmark3? Or are there any tricks to make the board reappear on the usb?

The flashing log:
--------------------------------------------------
~/workspace/Proxmark3/client$ sudo ./flasher os ../armsrc/obj/osimage.elf
Waiting for Proxmark to appear on USB... Found.
Entering flash-mode...
(You don't have to do anything. Press and release the button only if you want to abort)
Waiting for Proxmark to reappear on USB... Found.
Flashing os from ../armsrc/obj/osimage.elf
count=5 phoff=34
type=1 offset=0 paddr=0 vaddr=0 filesize=d4 memsize=d4 flags=6 align=8000
type=1 offset=8000 paddr=110000 vaddr=110000 filesize=140b8 memsize=140b8 flags=5 align=8000
flashing offset=8000 paddr=110000 size=140b8
WriteBlock(110000, 256, f8 b5 57 46 46 46 c0 b4 ... f0 b5 5f 46 56 46 4d 46)
WriteBlock(110100, 256, 44 46 f0 b4 95 b0 0d 90 ... 04 9e 40 42 76 42 03 96)
WriteBlock(110200, 256, 04 90 01 9e d8 7b 83 46 ... 20 1c 3c bc 90 46 99 46)
WriteBlock(110300, 256, a2 46 ab 46 f0 bc 02 bc ... 01 32 9c 42 f8 dc 7a e7)
WriteBlock(110400, 256, 00 23 ea 5c 0d 99 ca 54 ... d7 dc 01 20 08 f0 1c fe)
WriteBlock(110500, 256, 01 20 08 f0 19 fe 00 20 ... 66 63 25 63 61 63 13 f0)
WriteBlock(110600, 256, e9 fc 97 4a 00 27 97 4b ... 4a 45 01 da 11 91 4a 46)
WriteBlock(110700, 256, 8e 1c 12 96 0b 9e 40 42 ... 01 dd 11 91 1a 1c 0f 2a)
WriteBlock(110800, 256, 56 d8 00 24 15 4d a9 78 ... 99 79 88 44 d9 79 88 44)
......
WriteBlock(123900, 256, 20 69 6d 61 67 65 3a 20 ... 63 61 72 64 20 66 6f 72)
WriteBlock(123a00, 256, 6d 61 74 3a 20 25 78 00 ... 75 65 73 74 20 66 72 6f)
WriteBlock(123b00, 256, 6d 20 72 65 61 64 65 72 ... 64 65 72 3a 20 25 69 20)
WriteBlock(123c00, 256, 62 79 74 65 73 00 00 00 ... 63 6d 64 20 66 72 6f 6d)
WriteBlock(123d00, 256, 20 72 65 61 64 65 72 3a ... 65 2e 00 00 42 61 64 20)
WriteBlock(123e00, 256, 72 65 73 70 6f 6e 73 65 ... 20 66 72 6f 6d 20 74 61)
WriteBlock(123f00, 256, 67 2c 20 67 6f 74 20 6c ... 29 e1 ff ea 78 47 c0 46)
WriteBlock(124000, 184, 99 fa ff ea 78 47 c0 46 ... ff ff ff ff ff ff ff ff)
type=1 offset=20000 paddr=1240b8 vaddr=200000 filesize=4 memsize=4 flags=6 align=8000
flashing offset=20000 paddr=1240b8 size=4
WriteBlock(1240b8, 4, 01 00 00 00 ff ff ff ff ... ff ff ff ff ff ff ff ff)
moving stuff forward by 184 bytes
type=1 offset=20008 paddr=1240bc vaddr=200008 filesize=0 memsize=8066 flags=6 align=8000
type=1 offset=27fe0 paddr=20ffe0 vaddr=20ffe0 filesize=0 memsize=10 flags=6 align=8000

done.
Have a nice day!
--------------------------------------------------

Any help is greatly appreciated!

Regards,
Tom

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

can you try to revert to whatever arm crosscompiler you were using and see how it goes?

TomCyber

Member

Registered: 2010-02-15

Posts: 10

Re: Boot loop after flashing

I would love to. However, i am not at all able to flash the board, because it doesn't appear on the usb anymore. Is there only the way through JTAG or can I force the board to connect to usb for the flashing?

I thought, it would help if I keep the button pressed when (and after) the board is powered on (i.e. connected to the usb port). It will then stay with red and orange LED on, but still not appear on the usb. So no chance for flashing?!

Last edited by TomCyber (2010-02-24 13:47:37)

TomCyber

Member

Registered: 2010-02-15

Posts: 10

Re: Boot loop after flashing

Ok - problem solved. At least for now. I wasn't patient enough with waiting for the Proxmark3 to appear on the usb when pressing the button. It took quite a while until lsusb showed the device. Once it turned up I started the flasher and it was doing its work.

And the reason was.... ;-)

...obviously the new devkitARM (4.4.2) which I downloaded yesterday. Going back to version 4.3.3 and compiling the armsrc directory produced a working osimage.elf.

Anybody here with the same experiences? Did I do something wrong with installing/configuring the devkitARM?

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

funny, yesterday marcan was telling me that using devkitARM was a bad idea because "devkitfail" had a history of fail. I guess he was right

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: Boot loop after flashing

Guys don't blame devkit or gcc. I know where the problem is and I have already posted about it a couple of time in different threads. We need to fix the elf parser logic and I'm happy to do that when I get some time meanwhile use a different version gcc or be patient

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

can you point me to those threads? I'll take a look. (and we also happen to have a gcc dev. around ^^ ).

marcan

Member

Registered: 2010-02-20

Posts: 5

Re: Boot loop after flashing

It's worth noting that I'm using vanilla GCC+binutils (GCC version 4.4.3, no devkitARM) and it works just fine for me. I've rarely used devkitARM, but I have experienced severe fail when using devkitPPC. Your mileage may vary, but I'd still recommend a vanilla compiler, not devkitARM.

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

I guesss the main issue is for windows developers, which tend to be less patient for installing stuff, hence the devkitARM use

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: Boot loop after flashing

Rather than have you read through other threads, it'd be easier to explain again.

Have a look at the output of the first post in this thread, the WriteBlock(124000 completes flashing the block 124000-1240100 and the flasher should probably just quit there, however some compilers create an elf file with extra segments. The parser code sees that extra segment and does WriteBlock(1240b8 which effectively overwrites the just flashed range 124000-1240b7.

I admit I don't understand the interaction between compilers and the segments they generate in .elf files so I don't know the significance of that last small segment containing just 4 bytes "01 00 00 00" but in practice if I binary patch the elf file to cancel out that last segment, the image flashes OK and I have a functional board, so I don't know if the proper thing to do is to ignore those last 4 bytes or try and flash them intelligently by merging them into the last written segment when there is an overlap.

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

Ok I see, I'll generate the elf with both compilers and check their structures I guess. It should give me some clue for a clean fix. We'll see ...

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

Ok, so, here is a objdump of the the working fullimage.elf:

working_obj/fullimage.elf:     file format elf32-littlearm
working_obj/fullimage.elf
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00110001

Program Header:
    LOAD off    0x00000000 vaddr 0x00100000 paddr 0x00100000 align 2**15
         filesz 0x0000c4bc memsz 0x0000c4bc flags rw-
    LOAD off    0x00010000 vaddr 0x00110000 paddr 0x00110000 align 2**15
         filesz 0x0000dd42 memsz 0x0000dd42 flags r-x
    LOAD off    0x00020000 vaddr 0x00200000 paddr 0x0011dd42 align 2**15
         filesz 0x00000004 memsz 0x00000004 flags rw-
    LOAD off    0x00020008 vaddr 0x00200008 paddr 0x00200008 align 2**15
         filesz 0x00000000 memsz 0x00008066 flags rw-
    LOAD off    0x00027fe0 vaddr 0x0020ffe0 paddr 0x0020ffe0 align 2**15
         filesz 0x00000000 memsz 0x0000000f flags rw-
private flags = 4000002: [Version4 EABI] [has entry point]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .fpgaimage    0000a4bc  00102000  00102000  00002000  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .start        00000048  00110000  00110000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .text         0000dcfa  00110048  00110048  00010048  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .data         00000004  00200000  0011dd42  00020000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00008066  00200008  00200008  00020008  2**3
                  ALLOC
  5 .commonarea   0000000f  0020ffe0  0020ffe0  00027fe0  2**0
                  ALLOC
  6 .comment      000002e2  00000000  00000000  00020004  2**0
                  CONTENTS, READONLY
  7 .ARM.attributes 00000020  00000000  00000000  000202e6  2**0
                  CONTENTS, READONLY

Which produce the following working flashing log (for the os):

(...)
WriteBlock(11dc00, 256, 20 61 62 6f 72 74 69 6e ... 65 73 73 3d 25 78 2c 20)
WriteBlock(11dd00, 66, 43 6f 6e 74 65 6e 74 73 ... ff ff ff ff ff ff ff ff)
type=1 offset=18000 paddr=11dd42 vaddr=200000 filesize=4 memsize=4 flags=6 align=8000
flashing offset=18000 paddr=11dd42 size=4
WriteBlock(11dd42, 4, 01 00 00 00 ff ff ff ff ... ff ff ff ff ff ff ff ff)
moving stuff forward by 66 bytes
type=1 offset=18008 paddr=200008 vaddr=200008 filesize=0 memsize=8066 flags=6 align=8000
type=1 offset=1ffe0 paddr=20ffe0 vaddr=20ffe0 filesize=0 memsize=f flags=6 align=8000

And here is objdump for the bad fullimage.elf (using the latest devkit):

bad_obj/fullimage.elf:     file format elf32-littlearm
bad_obj/fullimage.elf
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00110001

Program Header:
    LOAD off    0x00000000 vaddr 0x00100000 paddr 0x00100000 align 2**15
         filesz 0x0000c4bc memsz 0x0000c4bc flags rw-
    LOAD off    0x00010000 vaddr 0x00110000 paddr 0x00110000 align 2**15
         filesz 0x000140b8 memsz 0x000140b8 flags r-x
    LOAD off    0x00028000 vaddr 0x00200000 paddr 0x001240b8 align 2**15
         filesz 0x00000004 memsz 0x00000004 flags rw-
    LOAD off    0x00028008 vaddr 0x00200008 paddr 0x001240bc align 2**15
         filesz 0x00000000 memsz 0x00008066 flags rw-
    LOAD off    0x0002ffe0 vaddr 0x0020ffe0 paddr 0x0020ffe0 align 2**15
         filesz 0x00000000 memsz 0x00000010 flags rw-
private flags = 5000002: [Version5 EABI] [has entry point]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .fpgaimage    0000a4bc  00102000  00102000  00002000  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .start        000000f4  00110000  00110000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .text         00013fc0  001100f8  001100f8  000100f8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .data         00000004  00200000  001240b8  00028000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00008066  00200008  001240bc  00028008  2**3
                  ALLOC
  5 .commonarea   00000010  0020ffe0  0020ffe0  0002ffe0  2**2
                  ALLOC
  6 .comment      00000022  00000000  00000000  00028004  2**0
                  CONTENTS, READONLY
  7 .ARM.attributes 0000002e  00000000  00000000  00028026  2**0
                  CONTENTS, READONLY

which yields to the known bad flashing log:

(...)
WriteBlock(123e00, 256, 72 65 73 70 6f 6e 73 65 ... 20 66 72 6f 6d 20 74 61)
WriteBlock(123f00, 256, 67 2c 20 67 6f 74 20 6c ... 29 e1 ff ea 78 47 c0 46)
WriteBlock(124000, 184, 99 fa ff ea 78 47 c0 46 ... ff ff ff ff ff ff ff ff)
type=1 offset=20000 paddr=1240b8 vaddr=200000 filesize=4 memsize=4 flags=6 align=8000
flashing offset=20000 paddr=1240b8 size=4
WriteBlock(1240b8, 4, 01 00 00 00 ff ff ff ff ... ff ff ff ff ff ff ff ff)
moving stuff forward by 184 bytes
type=1 offset=20008 paddr=1240bc vaddr=200008 filesize=0 memsize=8066 flags=6 align=8000
type=1 offset=27fe0 paddr=20ffe0 vaddr=20ffe0 filesize=0 memsize=10 flags=6 align=8000

As you can see, the part you are blindly dropping is the .data section, so it might not be such a good idea

So, it seems the latest version produces quite a bigger .start and .text section...
Let's investigate why now ^^

By the way, it might also mean that, up to now, it was working accidentally... we have the same behavior for the working flash run. Except we lose only 66 bytes.

Last edited by iZsh (2010-02-25 02:07:48)

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

Ok I've been told by segher (gcc dev) that the latest gcc version is more aggressive about the inlining hence the size going wild. But that's not really the issue. the real issue is that the flasher is flashing the code using each hdr but they are not all 0x100 aligned and the flasher is not able to flash the code on a byte basis. (so we erase some bytes)

marcan is going to fix the linker script/makefile to produce an elf with only one hdr which should therefore wave the problem. At least that's the plan

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: Boot loop after flashing

Considering this is an embedded device and each flash byte counts, is there anything we can do re the inlining you mention to reduce the resultant code with later gcc to the earlier gcc levels?

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

Yes of course, first stopping using an insane -O6 and switching to -Os would be a good idea. But for the moment we still have plenty of space, so that'd be a premature optimization IMHO. We should switch to -O2 or even -O3 though, until we really need -Os.

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

The flashing issue should be fixed now.

./flasher .../armsrc/obj/fullimage.elf

shoud work (on linux, mac os, and windows)

adam@algroup.co.uk

Contributor

From: UK

Registered: 2009-05-01

Posts: 203

Website

Re: Boot loop after flashing

Confirmed working for linux...

Nice one iZsh!

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: Boot loop after flashing

Yeah ditto for Windows,

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: Boot loop after flashing

This one was fixed by marcan, so kudos to him, not me