I added G7 X 100b and 100d to the autobuild, labeled as ALPHA, with FI2 building disabled.
What's the reason for omitting 100c?
BTW I noticed an anomaly in camera_list.csv: sx400is-100b is ALPHA but is still skipped.
ALPHA doesn't particularly imply "ready for the autobuild". The status labels are set by whoever works on the ports. Generally ports starts as ALPHA and we don't add cameras to the autobuild until a few people have reported it working.
So ixus125_elph110hs works, but remains in ALPHA since it has too many features disabled?
The ID -> name association list is attached to my previous post due to size limitation. I have extracted the function pointers starting from 0x80a001d0, and used a script to extract the debug strings (which appear to be function names) from the disassembly of the 0x80a00000 area.
loc_bff25a00: ; 3 refs bff25a00: bd01 mov.n a11, a1bff25a02: a806 l32i.n a10, a6, 0bff25a04: 25d1ff excwbff25a07: 2d0a mov.n a2, a10bff25a09: 96baf6 bltz a10, loc_bff25978bff25a0c: a805 l32i.n a10, a5, 0bff25a0e: 0c1b movi.n a11, 1bff25a10: e52e01 excwbff25a13: f801 l32i.n a15, a1, 0bff25a15: 9cff beqz.n a15, loc_bff25a38bff25a17: c02000 memwbff25a1a: 480f l32i.n a4, a15, 0bff25a1c: ed04 mov.n a14, a4bff25a1e: c02000 memwbff25a21: 381f l32i.n a3, a15, 4bff25a23: cbaf addi.n a10, a15, 12bff25a25: 473714 bltu a7, a4, loc_bff25a3dbff25a28: 412a76 l32r a4, 0xbff032d0 ; (0x80a00830)bff25a2b: 408ea0 addx4 a8, a14, a4bff25a2e: 8808 l32i.n a8, a8, 0bff25a30: e00800 excwbff25a33: dd0a mov.n a13, a10bff25a35: 860b00 j loc_bff25a67loc_bff25a38:bff25a38: 0c03 movi.n a3, 0bff25a3a: 42a0f0 movi a4, 240loc_bff25a3d:bff25a3d: a2a009 movi a10, 9bff25a40: c12576 l32r a12, 0xbff032d4 ; *"ID Error[%d] -- msg:0x%08x"bff25a43: 20d220 or a13, a2, a2bff25a46: b14175 l32r a11, 0xbff02f4c ; (0xbff04328)bff25a49: 40e420 or a14, a4, a4bff25a4c: b80b l32i.n a11, a11, 0bff25a4e: 25a8fd excwbff25a51: f14075 l32r a15, 0xbff02f54 ; (0x00c1341c)bff25a54: f80f l32i.n a15, a15, 0bff25a56: 8caf beqz.n a15, loc_bff25a64bff25a58: cd04 mov.n a12, a4bff25a5a: a11e76 l32r a10, 0xbff032d4 ; *"ID Error[%d] -- msg:0x%08x"bff25a5d: bd02 mov.n a11, a2bff25a5f: d801 l32i.n a13, a1, 0bff25a61: e00f00 excwloc_bff25a64:bff25a64: d2a000 movi a13, 0loc_bff25a67:bff25a67: a22600 l32i a10, a6, 0bff25a6a: 30b320 or a11, a3, a3bff25a6d: 20c220 or a12, a2, a2bff25a70: 65ceff excwbff25a73: a22500 l32i a10, a5, 0bff25a76: b2a002 movi a11, 2bff25a79: 652801 excwbff25a7c: 06e0ff j loc_bff25a00.loc_bff25a80:bff25a7f: 00a2a0 addx4 a10, a2, a0bff25a82: 09b2 s32i.n a0, a2, 44bff25a84: 2b00 addi.n a0, a0, 2bff25a86: c11476 l32r a12, 0xbff032d8 ; *"MzrmRcvTskMain Start"bff25a89: a59afd excw
Need some help to find message handlers for EOS M3:My code does not look the same as yours
I can't help more ATM because I have not found/extracted/disassembled the M3 blobs, yet.
dump offset - load address - size0x09FEFB0 0xBFF20000 0x77B80x0A06770 0xBFF00000 0x4AD00x0A0B248 0x80A00000 0x106220
It's very much possible that 'our' Xtensa is not lx106. Hmm, isn't that the core used in ESP 8266? Because that's a rather basic core that supports way less instructions, so its disassembler won't do the job.
You can take it from ROM dump:Code: [Select]dump offset - load address - size0x09FEFB0 0xBFF20000 0x77B80x0A06770 0xBFF00000 0x4AD00x0A0B248 0x80A00000 0x106220
Which exactly binutils you've used to get your disassembly?
Finally my message handlers are exactly the same as G7x.
Are function pointers situated at 0x80a00830?
bff2596e: 72a0ef movi a7, 239...bff25a25: 473714 bltu a7, a4, loc_bff25a3d
Started by NewbieToobie
Started by enveetee
General Discussion and Assistance
Started by kim.diedrichsen.7
Started by alvm
Started by reyalp
« 1 2 ... 7 8 »
General Discussion and Assistance