Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - adamnock

#1
Just confirming, the build you're testing is for Firmware 1.1.0 yes?

Wanted to check before I try running it on my 1.2.0 camera and possibly ruin it :)
#2
@ROME @vwnut8392

Pending someone with the requisite skill-set becoming involved, its unlikely this will progress any further.
#3
Menu nav no issues. Changing menu option (image qual) saving, turn off/on, confirm still set, reload HW, still set (config writes working)
LiveView working normally. Took a photo, scared myself because I was set to 8s expose and thought it had crashed, file saved onto SD no issue.

Yep, all looks fine. And HW shows back up straight up on any change.

No issue on debug, just checking incase I should expect it and there was a FIO write problem.

Gotcha on firmware sig
#4
OK, HELO1303.FIR plus a base compile of ML so we have fonts and other artifacts





GUI stuck around this time. Did reset and try again just in case.
FW Sig changes again but still different from QEMU result (which both DeinGott and I matched on, hopefully ruling out a bad ROM on any side)
Should I be seeing debug/output logs into a file on the SD card?
#5




Nice. Is the different firmware signature on hardware vs emulation expected?
#6




Results from HELO1300.FIR

Looks like it might say out of bound, but im guessing it would make sense to you :)
#7
Or not. I see you're on top of it. #standsback
#8
Then if im following the startup properly (im pretty raw at this sorry) then given that

ml_gui_initialised
flag is set via function
handle_common_events_startup
in
gui-common.c,
which is called from
handle_buttons
in
gui.c

which is part of the ML gui_main_task, it would follow that said task is either not being started, or is faulting.

Which could be a incorrect stub for the dryos gui_main_task

I might check that out.
#9
Could it be timing? I note in QEMU we reach the GUI a good 10-12 seconds before anything else runs. And even vanilla we see a pause then further startup occur just after the GUI presents
#10
Well Three Cheers for DeinGott!

As I understand it, the next step is to get one of the primary Dev's to generate a boot-flag enabler (the installer?) the then effectively try this on real hardware.

Im a willing test dummy here. Im comfortable with the risk inherent :)
#11
Maybe either create a new branch for 1300D-experimental code (regarding your serial patch) or wrap it in a new define check?
CONFIG_QEMU_SERIAL_DEBUG or something?
#12
If you identified FIO_FindFirstEx from the BL call just before the debug message *"[DM] ERROR : FIO_FindFirstEx fail"
at ROM dump position

0xf842435c -> 0xf8424368

Then I would concur that it seems the likely candidate.
#13
Mein Gott DeinGott (sorry I had to), thats a leap forward.

Ive copied your work into the repo and also made some adjustments to get CONFIG_HELLO_WORLD to compile (fps-engio and raw had some platform-specific requirements)
Hello World now builds, and autoexec.bin is loaded as you had, but Hello World does not execute.

I grabbed the QEMU output for a run and popped it up here
<REMOVED DUE TO MERGE WITH MAIN REPO>
if anyone wants to have a sticky. File is qemu-bootlog-hw.txt

#14
*sigh* reading through the EOSM2 walkthrough a1ex linked hinted I was having the same issue with GDB not properly loading with QEMU as dfort did.

Fixed, added a breakpoint for firmware start, going to add more for the non-FIO stubs so I can try and pinpoint where is going off target.
No idea what im doing, but im having fun doing it  8)
#15
Thought id found them but running the minimal hello world in QEMU's just looping

PrefetchAbort
0007F158

So either ive stuffed what I found or one of the other stubs is wrong (sic)

// Note / Question
Just to be sure, im supposed to be copying the compiled autoexec.bin file to sd.img and running with boot=1 correct?
I am doing a checkpoint each test by setting boot=0 to ensure booting to GUI works as intended, just in case I stuff something else.

More:
OK im confident know there's something wrong other than incorrect msleep or bmp_vram_info stubs.
Removing them from the mix and running a copy of minimal which I would expect to simply die faults at the same point.
Meaning one of the main stubs is probably wrong. Or being called from RAM and we dont have an offset (tempted to go into work and get my laptop with my last efforts where I think I had something on that).

Taking a break and creating a public fork so nothing goes missing again.

Public Fork:
https://bitbucket.org/maugriman/magic-lantern-1300d/

Currently just the initial folder setup and currently identified stubs, with the framework copied from the 1100D
#16
OK so it seems to compile minimal for the 1300D we need to find the stubs

bmp_vram_info
msleep

*dig dig dig*
#17
Digging up my notes (which I still cant find) whet my appetite. 1300D Firmware booted in QEMU.
Time to remember stuff.
#18
Yeah I checked out that branch earlier.
Realised id not backed up my ROM copies so ill redo that shortly.

Hoping some of kennetrunners stubs progress might have been recorded in one of the build branches, but no matter, still needs doing.

@anyone else. Dont expect rapid progress here. Im going to have to properly learn this stuff as I go, im no reverse engineering genius :)
#19
Ive put off coming back for too long (honestly I got quite lost but im still going to try and muddle my way through this).

a1ex / kennetrunner

Was there a branch of the project which included the QEMU hacks and currently identified stubs I can check out and work from?
I think I understand the project topology well enough now to compile a hello world test and run it on metal.

#20
Hi Electrohead

Current priority is finding the relevant code stubs.
http://www.magiclantern.fm/forum/index.php?topic=12177.0

You can dump your camera's ROM without having to take it apart or anything horrible like that. Go back to the start of this post and look at A1ex's first couple of replies, they contain the details.
Then you want to check out and build the latest 'qemu' branch of the source, which contains the work A1ex has done on getting the 1300D emulatable etc.

Get yourself to the point where the ROM runs up past the Ready K404 debug output and you can get started with the above stub finding.

I had a priority project dumped on me at work, so ill be out of this for the next 8-10 days, but then ill get back in and keep working on it too :)
#21
OK im a little confused....again

Ive got what i believe is most of the startup stubs identified, and compiled ML as such.
However, when booting with ML, which qemu is finding autoexec.bin off the SD card and booting it, i drop to the FROMUTILITY every time, without hitting any of the stub locations. Even if they were wrong, I believe I should see a jump to the location as ML tried to call those functions.

So, have I missed a step?
All I can see from searching around the forum is that the FROMUTILITY should be a option from a boot flag, but the output suggests 1 is the correct flag to boot autoexec.bin. Hence I can only assume its not loading?


SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x3AFC0
Now jump to AUTOEXEC.BIN!!

************ FROMUTILITY MENU Ver 0.11 ************
[Type:404 Body:DC Rev:0.00 MID:0x88(Error)]
0.Factory Menu
1.Erase Sector Select
2.Erase Block Select
3.Erase Chip
4.Write from card
5.Write from DRAM
6.Firm   flag 0xF8000000 0x00000000 ON
7.Boot   flag 0xF8000004 0xFFFFFFFF ON
8.UpDate flag 0xF800000C 0xFFFFFFFF OFF
9.Create Boot Disk
A.Exec Program from SD
C.Connect card
D.SROM 4Byte Mode ON
G.Memory Dump
I.Write Data
J.Direct Jump
U.Firm update
Z.RCBIND.BIN update
>>
#22
Alrighty then.
yes the memory trace seems like a very very handy feature.

Ill get started on it again this weekend!

Thanks for the heads up on the qemu updates :)
#23
Right so assuming my previous was in any way right


f80c0090: e59f0044 ldr r0, [pc, #68] ; f80c00dc: (fea87718)
f80c0094: e59f1044 ldr r1, [pc, #68] ; f80c00e0: (00001900)
f80c0098: e59f3044 ldr r3, [pc, #68] ; f80c00e4: (0004f4ac)
loc_f80c009c:
f80c009c:    e1510003 cmp r1, r3
f80c00a0: 34902004 ldrcc r2, [r0], #4
f80c00a4: 34812004 strcc r2, [r1], #4
f80c00a8: 3afffffb bcc loc_f80c009c
f80c00ac:         e59f1034 ldr r1, [pc, #52] ; f80c00e8: (00084d7c)



f80c00a0: 34902004 ldrcc r2, [r0], #4


Is loading the relevant ROM data to be copied from the address at r0, with an offset of 4 into r2


f80c00a4: 34812004 strcc r2, [r1], #4


is then storing that ROM data into the address in r1, again with an offset of 4, which it gets from r2


f80c0094: e59f1044 ldr r1, [pc, #68] ; f80c00e0: (00001900)


Is the RAM start address, which leaves


f80c0090: e59f0044 ldr r0, [pc, #68] ; f80c00dc: (fea87718)


Which is the copy FROM location, which is pc + 68, which thanks to the helpful disassembly output, we know is 0xF80C00DC

Hence, the RAM_OFFSET is 0xF80C00DC

Note:

This could be additional verified by the fact that the code at F80C00DC is

f80c00dc: fea87718 mcr2 7, 5, r7, cr8, cr8, {0}


Which definitely looks like the type of function you would want in RAM as its intended for a coproc (sic?) and hence would want to be accessible from said RAM as it may reference other local functions the coproc needs to execute/


#24
Right, so I understand now. Its not a case of identifying where in RAM the ROM portion is copied TO, is where it came FROM.
Also 0x1900 is the start point of the RAM copy of the ROM portion

Leading to the RAM OFFSET value being the location in ROM where the copy is done from, so that the STUB addres would be
the location in ROM, not RAM, which would be

RAM OFFSET address + (RAM function address - RAM start address)

So for the function at 0x29898, the STUB address would be
RAM_OFFSET + (0x29898 - 0x1900).

So now to figure out where its being copied from. That should be trivial I think.....
#25
Wait thats not right....hmm, i think I know what I did wrong there