Author Topic: Beginning steps in kernel disassembly and analysis (Read 3984 times)

dconrad · « **Reply #15 on:** June 20, 2021, 12:19:26 PM »

Quote from: amachronic on June 20, 2021, 05:44:40 AM

0x2c2c2c2c is most definitely the value pointed to by smart_config.write_gram_cmd. 0x2c is the standard write_memory_start command of MIPI DCS, used to initiate writing data to the LCD controller's framebuffer RAM. It's not fb_videomode.flag.

Aha, so it's cmd_buf[], I see it there now in my example driver setup.

Quote

In the M3K kernel sources the init_pixclock member is dropped vs. the YuanhuanLiang repo. That's probably why your fb_videomode struct is too big. Maybe you should check the M3K sources for other structs that seem "wrong", it's possible that the Eros Q is using sources similar to the M3K's. (A reminder that your source won't necessarily line up with the binary!)

I see! That did make it fit, and all the values look sane now. Bookmarking the m3k sources...

Quote

So with this in mind, jzfb stuff looks lined up right to me:

Code: [Select]
805147ac = bitfield clkply_active_rising=1 newcfg_fmt_conv=1 others=0 (this is standard fare, nothing exotic) 805147b8 = smart_config.bus_width 805147c0 = smart_config.length_data_table 805147c4 = smart_config.data_table
Also a look at this
Code: [Select]
805147a4 00 uint:1 0h pinmd:1 805147a4 00 uint:1 0h pixclk_falli 805147a4 00 uint:1 0h data_enable_ 805147a5 00 00 00 00 00 smart_co field_0x1d
That start address 805147a5 is almost certainly wrong. The alignment of the struct is at least 4 bytes and struct alignment = maximum alignment of any member. Plus, the first member must be aligned wrong because enums seem to be ints under the ABI used (an implementation detail which I haven't bothered to verify but seems to be true).

Weirdly, Ghidra doesn't align structs by default -- in the lower right corner of the struct editor is an unobtrusive "Align" checkbox. Checking that will make Ghidra insert the correct padding to follow C alignment rules (afaict). It seems Ghidra defaults to "packed" alignment by default... it confused me for a couple hours too.

In this particular case I think I can say with certainty the alignment is wrong -- but in general, you would need to check the generated code to see if the compiler emitted code to access aligned addresses or unaligned addresses. The lw/sw instructions to load/store a word require 4 byte aligned addresses, whereas to access an improperly aligned word, the compiler would need to generate different instructions -- in the case of MIPS the instructions used would depend on the ISA version targeted, IIRC the older versions don't have any unaligned load/store instructions.

The align checkbox... That magically fixed it! Yep, now that'll be the first thing I check.

Quote

That's my assumption. Sure, it's defined in other parts of the xburst tree for other SoCs, but this is an X1000 kernel... where else would it be defined?

Oh, I thought it was the jzfb_platform_data from drivers/video/jz_vfb/vfb.h at first, which is really short in comparison, but it's missing *dsi_pdata and lcd_type between *modes and bpp, so I was confused.

This is definitely a crash course in data structures, something I probably should have taken a class on in college...

amachronic · « **Reply #16 on:** June 20, 2021, 12:48:22 PM »

ah, didn't realize that other driver used the same name... it looks like an in-memory framebuffer with no hardware interface. The real LCD driver would be under drivers/video/jz_fb_v12/. Or maybe the v11 or v13 versions. I'm not sure why they put 3 versions in one source tree.

dconrad · « **Reply #17 on:** June 20, 2021, 03:47:04 PM »

Do you think it's worth trying to construct the platform_device structure? It requires building the device struct which is a bit daunting. Plus, there are some #ifdefs that I'm not sure if this device would have or not. Just not sure if that's something worth going through or not.

Edit: the big one defined in kernel/include/linux/device.h

amachronic · « **Reply #18 on:** June 20, 2021, 04:33:42 PM »

FWIW, I didn't ever figure out struct device and didn't try -- once I realized how complicated it was. But I did do some random clicking inside of them and it might've been useful once or twice... there's probably not much there which can't be found another way, because that struct is generic.

One tactic you could use to handle this kind of thing -- create the struct, but pad out the unknown parts with byte arrays. Choose the size of the byte arrays to make the known members line up properly, and if you find more information, you can always split up the byte arrays and add new members in the middle, etc.

So, maybe find a driver which you have source code for and which statically initializes a platform_device/device struct; locate the beginning of that struct in the binary, then go over the struct's members in order, stepping inside all nested structs along the way. Then, identify the initialized members and learn their offsets. Of course any initialized data that you aren't expecting will throw off the count, but with luck you can identify a few members. Then you can tentatively identify adjacent members via the source code as long as you don't have to pass over anything of unknown size.

dconrad · « **Reply #19 on:** June 20, 2021, 05:03:15 PM »

Quote from: amachronic on June 20, 2021, 04:33:42 PM

FWIW, I didn't ever figure out struct device and didn't try -- once I realized how complicated it was. But I did do some random clicking inside of them and it might've been useful once or twice... there's probably not much there which can't be found another way, because that struct is generic.

One tactic you could use to handle this kind of thing -- create the struct, but pad out the unknown parts with byte arrays. Choose the size of the byte arrays to make the known members line up properly, and if you find more information, you can always split up the byte arrays and add new members in the middle, etc.

So, maybe find a driver which you have source code for and which statically initializes a platform_device/device struct; locate the beginning of that struct in the binary, then go over the struct's members in order, stepping inside all nested structs along the way. Then, identify the initialized members and learn their offsets. Of course any initialized data that you aren't expecting will throw off the count, but with luck you can identify a few members. Then you can tentatively identify adjacent members via the source code as long as you don't have to pass over anything of unknown size.

That seems like a sane way to do it. I'll have to give it a shot.

Meanwhile, I think I have some real, actual information about the LCD and backlight! well, maybe. I haven't quite figured out what the controller is, and I don't know what pins it uses to connect, but I think I've found quite a few details about it. I think all the values make sense, as far as I can tell - though I don't have much experience with these beyond what I've seen in example structs in the X1000 kernel source.

The platform_data struct: