VxWorks ROMLOG binary data format needed.

reyalp

13387

Re: VxWorks ROMLOG binary data format needed.

« Reply #10 on: 04 / July / 2010, 16:17:06 »

Advertisements

Quote from: cppasm on 04 / July / 2010, 05:23:12

Just look into GetLogToFile() function to find out address of log in ROM, size is in the first 4 bytes of log.
Then just write those data to file and that's all.

This is FFFFE000 on every camera I've looked at.

If we can come up with suitable generic code, it would be nice to have this in CHDK, rather than requiring the native call build. (next step... "send crash report"

)

Quote

Many (or all) VxWorks cameras does not have parameter whether to shutdown or not after saving romlog.

a540 does.

Logged

Don't forget what the H stands for.

cppasm

Re: VxWorks ROMLOG binary data format needed.

« Reply #11 on: 05 / July / 2010, 03:33:46 »

Quote from: reyalp on 04 / July / 2010, 16:17:06

This is FFFFE000 on every camera I've looked at.
If we can come up with suitable generic code, it would be nice to have this in CHDK, rather than requiring the native call build. (next step... "send crash report" )
es.

It's not always true.
On S2 IS it's 0xFF800000.
And I guess on all 'S' series too.
But generic code could be created by adding this variable to camera specific stubs.

Logged

reyalp

13387

Re: VxWorks ROMLOG binary data format needed.

« Reply #12 on: 03 / March / 2013, 23:17:18 »

Thread necromancy

I'm not sure if cppasm ever posted his code, the attachments seem to have gotten lost

I've added a module to the chdkptp extras directory that parses some useful information out of vxworks romlogs. Currently it's only tested with a540, and works for asserts and exceptions.

For both, it displays task name, task id, some stack, and camera log (with print_all())

Asserts also show file and line number.

Exceptions show exception vector and registers.

There's a lot of stuff I haven't figured out yet. The stack shown for asserts may not be the complete stack dump, but it always gets back to an address in debugassert, so more isn't really useful

It can be invoked like
!require'extras/vxromlog'.load('ROMLOG.LOG'):print()
or
!require'extras/vxromlog'.load('ROMLOG.LOG'):print_all()

Note ROMLOG.LOG is a local path, it doesn't download it form the camera.

I'd be interested to have samples of other romlogs from vxworks cameras that use the binary format.

Logged

Don't forget what the H stands for.

srsa_4c

4426

Re: VxWorks ROMLOG binary data format needed.

« Reply #13 on: 05 / March / 2013, 12:38:48 »

Quote from: reyalp on 03 / March / 2013, 23:17:18

I've added a module to the chdkptp extras directory that parses some useful information out of vxworks romlogs. Currently it's only tested with a540, and works for asserts and exceptions.

For both, it displays task name, task id, some stack, and camera log (with print_all())

Asserts also show file and line number.

Exceptions show exception vector and registers.

Thanks, seems useful (especially the information about exceptions). In the past, I just used some hex viewer and searched for things that looked like addresses - was usually enough for assert logs.

Quote

There's a lot of stuff I haven't figured out yet. The stack shown for asserts may not be the complete stack dump, but it always gets back to an address in debugassert, so more isn't really useful

The stack dump seems to have an extra line at the end, the start of the text log (characters).

Quote

I'd be interested to have samples of other romlogs from vxworks cameras that use the binary format.

I have attached some (a410, a420, ixus65_sd630, s80).
The first 3 VxWorks model (s1, ixus30, ixus40) is different (as usual), there's no GetLogToFile and the logged information is different (no stack trace appears to be recorded, it has some kind of "state of all running tasks" instead). I have successfully used some home-made DebugAssert replacement on these to record the needed information to the card. In fact, the assert handler is replaced in my s1is port - the original routine restarts the camera instead of shutting it down, which is annoying as there's no autoboot.

some_vx_romlogs_.7z (5.57 kB - downloaded 37 times.)

« Last Edit: 05 / March / 2013, 12:45:37 by srsa_4c »

Logged

Menu jumping/flickering on M10?

reyalp

13387

Re: VxWorks ROMLOG binary data format needed.

« Reply #14 on: 06 / March / 2013, 00:49:54 »

Thanks.

Quote

The stack dump seems to have an extra line at the end, the start of the text log (characters)

This should be fixed.

I looked through the ones you sent and they seemed to load ok. ixus65_sd630/ROMLOG.LOG is slightly odd, the exception vector is 0 which shouldn't normally happen... but pc is 0 so maybe it was a null function pointer, which would jump to the reset handler? The other register values look plausible.

Code: [Select]

Exception vector 0x0 (Reset)
Occured at 2012:06:23 17:52:15
Task ID: 2578136
Task Name: tPhySw
Registers:
r0   0x001d12dc      1905372
r1   0x00000002            2
r2   0x000d3010       864272
r3   0x00000000            0
r4   0x00000002            2
r5   0x000d0e6c       855660
r6   0x000c6cc5       814277
r7   0x000d0ea2       855714
r8   0x00000000            0
r9   0x00000000            0
r10  0x00000000            0
r11  0x00000000            0
r12  0x00000000            0
sp   0x000d2fec       864236
lr   0x001d1059      1904729
pc   0x00000000            0
cpsr 0x00000013           19

a420/ROMLOG_3.LOG doesn't seem to have a valid task name, but others from the same camera do so I'd guess that's just corruption related to the crash.

Code: [Select]

Exception vector 0x4 (Undefined instruction)
Occured at 2011:12:24 10:06:40
Task ID: 1888724
Task Name: ª
Registers:
r0   0x0000000b           11
r1   0x00000000            0
r2   0x00000000            0
r3   0xffe14850     -2013104
r4   0xffe14804     -2013180
r5   0x0000a3c8        41928
r6   0x00000000            0
r7   0x001c1d6c      1842540
r8   0x001cd14c      1888588
r9   0x00000000            0
r10  0xffffffff           -1
r11  0x001cd140      1888576
r12  0x00080029       524329
sp   0x001cd0c8      1888456
lr   0x000b61ef       745967
pc   0x000b621c       746012
cpsr 0x60000013   1610612755

Logged

Don't forget what the H stands for.

reyalp

13387

Re: VxWorks ROMLOG binary data format needed.

« Reply #15 on: 10 / March / 2013, 00:32:52 »

I've confirmed that a call to a null function pointer will result in the "Reset" exception in vxworks. Strangely, it doesn't seem to in DryOS.

edit:
Not so strange, on D10 the reset vector is initialized to a NOP, so falls through to the next one (undefined instruction)

« Last Edit: 10 / March / 2013, 22:43:35 by reyalp »

Logged

Don't forget what the H stands for.