<smaeul>
the problem with ST7701S-based panels is that they all have slightly different init sequences, without documentation
<smaeul>
however it's probably pretty easy to extract the init sequence from the kernel module if you open it up in Ghidra
<smaeul>
at that point you can basically copy/paste one of the existing SPI LCD drivers (like panel-sitronix-st7789v.c) and replace the mode and init sequence
<LordKalma>
I though about doing that, trying to decompile the module
<LordKalma>
thanks for the pointer, appreciate it :)
<LordKalma>
and for that github repo. Haven't come across it, I don'0t think the are in the main community where we're discussing x6100 hacking :)
<LordKalma>
thanks a lot
* LordKalma
install ghidra :D
<LordKalma>
I do wonder why the panel has 2 things here: `compatible = "jinglitai,jlt4013a";`
<LordKalma>
if they are implementing the driver, one isn't enough
<szemzoa>
smaeul: yes, that's the latest manual I was found too.
apritzel has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
pnill has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
Daanct12 has quit [Quit: Leaving]
<apritzel>
LordKalma: do you mean two names separated by a comma, in the compatible string? That is the "<vendor>,<device>" DT naming convention
<apritzel>
smaeul: many thanks for the pointer
<LordKalma>
ahhh my bad :)
<LordKalma>
apritzel, still learning, sorry
<LordKalma>
I thought those were names of the kernel modules
pnill has joined #linux-sunxi
<apritzel>
LordKalma: those are just unique strings, which are *matched* in drivers
<apritzel>
comparable to PCI vendor:device ID pairs
<LordKalma>
thanks :)
<apritzel>
LordKalma: if you look at the end of panel-sitronix-st7789v.c, for instance, you will find a list of compatible strings this driver cares about
<LordKalma>
will do. I'll probably take yoru advice, and put the module on Ghidra and see what's what
<LordKalma>
I never used ghidra I know it's capable of being given headers and other libraries, but meh, we'll see
<LordKalma>
right now I'm at my lab, so that's for the evening :)
<LordKalma>
(different kind of lab)
<LordKalma>
well, I meant smaeul's advice :)
* LordKalma
wishes they just complied with the GPL :(
hlauer has joined #linux-sunxi
<apritzel>
LordKalma: actually you should be able to ask for the source code, under the conditions of the GPL
<apritzel>
LordKalma: GPL doesn't require the vendor to publish the source, it just demands that it will be made available to customers, on request
<apritzel>
smaeul: szemzoa: so what I was thinking: the T113-S3 is also using the new H6 style clock/memory map
hlauer has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
<karlp>
(be prepared to send them floppies ;)
<karlp>
(and an obscure payment method for the cost of duplication)
<szemzoa>
apritzel: I don't know sunxi chips well, but as I read, the R528/F133(D1s)/T133-S3/D1 somehow related. The D1s(F133) is even pin compatible with T113. The difference is the D1s is RV with 64MB DDR2 and the T113 is armv7 with 128MB DDR3, but the peripherals are the same.
<LordKalma>
apritzel, I sent them two emals already
<apritzel>
LordKalma: then sue them! ;-)
<apritzel>
szemzoa: yeah, lately Allwinner is pumping out lots of different SoCs, with slight variations only
<apritzel>
smaeul: I wonder if your new clock sharing patch allows more SoCs to share their clock drivers
<apritzel>
I think H6 is a special snowflake, with USB3.0, PCI and the resulting x4 clocks, but maybe the H616 is closer to those new gen v7 SoCs
<LordKalma>
apritzel, yes, with my 5€ budget :D
<apritzel>
so they didn't react at all to your request? And that was the company that makes this radio?
<LordKalma>
I emailed Xiegu (the manufacturer), no response. I emailed Radioddity (the major resseler), and they said they'd "forward my concerns"
rajkosto has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
<LordKalma>
okay, I need some help
<LordKalma>
I mounted the image of the radio, and did grep -R "jlt" .`
<apritzel>
LordKalma: try: arm-linux-gnueabihf-objdump -D -m arm -b binary 7208
<apritzel>
(replace with your cross-compiler prefix)
<LordKalma>
thanks!
<apritzel>
I am typically not in the business of rev-eng-ing *Linux kernels* (since I have the source for that, or the vmlinux file), so not sure if there is a better way
<apritzel>
you might want to run "strings" on it, but I guess that alone won't help you much
<jakllsch>
(it defaults to 512 byte chunks, which are slower to access than larger chunks)
<LordKalma>
yes
<LordKalma>
changed to 16M... still the same
<apritzel>
the poor A7s are probably overwhelmed with the encryption ;-)
<apritzel>
and why do you dump the block device? /proc/kallsyms is a pseudo file, generated by the running kernel on the fly, it won't be contained in any dump
<LordKalma>
to explore the filesystem after
<LordKalma>
if you have better ideas, they are welcome
<apritzel>
for your driver research there are probably not many clues on the filesystem
<LordKalma>
so the kallsyms has those symbols
<LordKalma>
where are they?
<LordKalma>
:p
<apritzel>
where is what? kallsyms contains names for certain addresses, so ideally there is a fixed number that you subtract to get the offset in your extracted kernel file
<LordKalma>
okay, now what is the kernel file?
<LordKalma>
what file should I get out?
ftg has joined #linux-sunxi
hlauer has joined #linux-sunxi
<apritzel>
that file that you extracted already, from the zImage
<apritzel>
on those embedded systems that's typically not in the root fs, but separately
<LordKalma>
there is a /boot/zImage in the device
<apritzel>
so you got lucky
<LordKalma>
so `c04a7bc0 T drm_panel_init` means that drm_panel_init is at address c04a7bc0 from where?
<apritzel>
I would start at 0x4a7bc0 (so minus the two top bits), but I don't know the details about the arm32 kernel mappings
<apritzel>
it probably helps to find the lowest address first
<apritzel>
and I wouldn't look for a generic symbol, but for a driver specific one
<apritzel>
it probably helps to dump the dmesg output to look for a name
<apritzel>
or try /proc/devices or search somewhere in /sys
<apritzel>
smaeul, jernej: do you think it's worth to get "creative" with the clock numbering, to allow clock driver sharing?
<apritzel>
smaeul, jernej: so either make sure the names are unique across multiple SoCs, or include the SoC name, like CLK_V5_BUS_OTG
<LordKalma>
what's the right binutils for this chip, again=
<LordKalma>
?
<apritzel>
LordKalma: do you mean the (cross-)compiler triplet? That depends on your installed (cross) toolchain, a common name for ARMv7 is "arm-linux-gnueabihf-"
<apritzel>
LordKalma: indeed, does all the heavy lifting for you
<apritzel>
(but you still need to find that particular driver, not the generic kernel panel subsystem code)
<LordKalma>
yes
<LordKalma>
now I have to look on ghidra what did they call it :D
<apritzel>
you might be better off to check the running system
adjtm has joined #linux-sunxi
<jernej>
LordKalma, apritzel: rev eng raw vmlinux is very challenging. However, if you convert it to ELF (https://github.com/marin-m/vmlinux-to-elf) is suddenly very easy (provided that conversion works, which does most of the times)
vagrantc has quit [Ping timeout: 480 seconds]
<LordKalma>
jernej, if you read the last 5 lines of the log, I did just that :)
<jernej>
oh, I just scanned through and missed, sorry
<LordKalma>
apritzel, I saved the kallsyms into a text file and can go back to the system whenever I need
<jernej>
you can now scan for compatible string and you'll find functions you're looking by following reference of that string
<jernej>
where can be vmlinux downloaded? now I'm interested :P
<LordKalma>
what do you mean?
<jernej>
I would like to load that kernel in ghidra
<LordKalma>
perhaps Ghidra isn't as advanced on ARM
<LordKalma>
and there's the ARM deep decompiler, that takes ages
<jernej>
no, I'm using it for ARM almost exclusively and it works well
<DuClare>
IME Ghidra isn't very advanced on anything..
<LordKalma>
also in "st7701s_driver_init" says /* WARNING: Control flow encountered bad instruction data */ and /* WARNING: Bad instruction - Truncating control flow here */
<jernej>
yeah, if you take a look at resulting code, that's obvious
<jernej>
one explanation would be that symbols were not properly applied to bin file
<LordKalma>
it's just 4 lines of assembly
<LordKalma>
and generates all that crap haha
<jernej>
yeah, if you take a look at some other function, it has same issue
<LordKalma>
I'll now try to write the driver from a similar file
<LordKalma>
or hand this off to another member of the community that wrote linux kernel stuff before
<LordKalma>
thanks so much
<apritzel>
and you were lucky, on arm64 you typically have a randomised offset, plus I think there are kernel options which relocate *each* function randomly
<LordKalma>
I can't thank you enough
<jernej>
I loaded arm64 kernel I built and vmlinux-to-elf properly detected base address and decompiled code looks nice
<jernej>
so no randomization
<apritzel>
with a kallsyms from a running kernel?
<jernej>
no, app finds kallsyms inside vmlinux bin
<apritzel>
jernej: ah yeah, in this case the addresses are not randomised, because that happens at runtime
<jernej>
I try to use static analysis as much as possible for exactly such reasons :)
<LordKalma>
I (and I bet the rest of the community around hackign this radio) will try the most of give back by actually writing the driver
<LordKalma>
the OPEN SOURCE way
<LordKalma>
thank you so much again
<jernej>
no problem
<apritzel>
and yeah, the randomisation is exactly there to complicate "reverse engineering", although the more automated exploit version of it
<jernej>
note that if you write exactly the same way, you might violite copyrights
<LordKalma>
at least two of the functions reeturn 0
<LordKalma>
can't write that differently
<LordKalma>
and most of the others are also trivial
<jernej>
but then again, strings in kernel say that this driver is GPLv2
<LordKalma>
GPL 2.0 still protects owner's copyright
<LordKalma>
I can claim this is Jet from Xiegu's work
<jernej>
LordKalma: if you need help with writing the driver, don't hesitate to ask :)
<LordKalma>
I'll try myself, but will do, thanks
<LordKalma>
also, do you upstream to the mainline kernel, or do you have a fork?
<LordKalma>
I know they build the firmware for the radio with buildroot
<jernej>
I try to upstream everything, once code is ready
<jernej>
you can even create and submit DT for this device, so it will be officially supported in mainline kernel :)
<apritzel>
jernej: that's using the T113-S3, so first we need someone to do the pinctrl/ccu exercise ;-)
<apritzel>
jernej: which was the motivation for my question regarding clock driver sharing earlier
<jernej>
LordKalma: are you using U-Boot from manufacturer image?
<jernej>
somebody had to write DRAM driver too...
<apritzel>
jernej: there is *some* DRAM code in xfel
<jernej>
so xfel initializes DRAM instead of SPL?
<apritzel>
jernej: yes, that's my understanding
<apritzel>
for this SoC it looks like it upload a huge blob, then executes this
JohnDoe_71Rus has quit []
<apritzel>
for the other SoCs (H3, for instance), there is corresponding source code, but not for the R528/T113
<apritzel>
the H3 DRAM code looks eerily similar to the U-Boot code, btw. although with an MIT license header ...
<jernej>
of course is similar
<apritzel>
similar as in "having the same comments"
<jernej>
ha, ok
<apritzel>
jernej: do you know where the H3 U-Boot DRAM code originally came from?
<jernej>
no, H3 is actually before my time dealing with Allwinner SoCs
<apritzel>
(because it could be based on the same leaked source)
<jernej>
well, at the beginning, when I didn't follow everything
<apritzel>
I see
<jernej>
AW has same basic structure of DRAM driver from almost the beginning, like A10
<apritzel>
jernej: chances are it's similar to the other SoCs with integrated DRAM anyway
<LordKalma>
jernej, yes, the community is using the UBoot from the manufacturrer's image
<LordKalma>
I dunno if we have to do somehing to also build it from source
<LordKalma>
what do you suspect?
<jernej>
LordKalma: to make reveng process even easier, you can also import all kernel headers from that specific kernel version
<jernej>
this will give you all structures and help with analysis
<LordKalma>
thanks :) I notice most of it uses also exported functions, and it's very simple functions, shouldn't be too hard to get the structs from just grepping the linux source
<LordKalma>
jernej, but do you think that building uboot from source would cause trouble?
<LordKalma>
do you expect anything special to be in there?
<jernej>
do you have source?
<jernej>
that SoC is not supported by mainline U-Boot
<jernej>
and usually first big obstacle is DRAM driver, which has to be reveng
<LordKalma>
we don't obviously haha
<LordKalma>
jernej, the uboot.bin file loads into ghidra nicely
<LordKalma>
but none of the functions have signatures...
<apritzel>
LordKalma: the vendor U-Boot is typically very outdated
<LordKalma>
apritzel, I'd like to make it build for source as well
<LordKalma>
one battle at a time
<jernej>
not sure what you consider uboot.bin, usually there are two stages - SPL and U-Boot proper, combined into one binary
<apritzel>
and since we have the user manual, and it looks like it's one of those H6-gen v7 SoCs, I don't expect too much trouble, short of the DRAM init, of course
<jernej>
and note, proper offset for SPL is usually SRAM location, which can be found in SoC user manual
<apritzel>
jernej: but if it's the BSP U-Boot, then it's surely boot0 + U-Boot proper only, right?
<apritzel>
in v2014.07 or so ;-)
<LordKalma>
jernej, someone extracted the uboot section from the firmware update image
<LordKalma>
with this: `dd if=X6100-sdcard-20220219.img of=uboot_sdcard.bin bs=1024 skip=8 count=512 seek=0`
<jernej>
apritzel: look at boot log, it's modified mainline U-Boot
<jernej>
apritzel: IIUC, this is ARM analog of D1, so most code could be shared
<apritzel>
jernej: oh, I see
<LordKalma>
so I loaded that uboot_sdcard.bin into ghidra
<jernej>
this is most interesting combination of software used in the wild
<jernej>
mainline, but not really :)
<apritzel>
LordKalma: if you look at uboot_sdcard.bin with a hex editor, does it have "eGON.BT0" in the first line?
<LordKalma>
yes
<apritzel>
and does it have something which looks like a DT name a bit later?
<apritzel>
yeah, so clearly mainline based, with the uImage at 32K, and the DT appended at the end
<LordKalma>
what's that at 0x18820?
<apritzel>
LordKalma: if you just cut off the first 24K of uboot_sdcard.bin, and load that into Ghidra, telling it that the load offset is 0x20000
<LordKalma>
but isn't the DRAM driver something I want?
<apritzel>
LordKalma: that looks like a false alarm
<apritzel>
that's probably the image magic, used by the code ;-)
<apritzel>
LordKalma: yes, the DRAM driver is in the SPL, which is that first part, loaded into SRAM by the BootROM
<LordKalma>
and how would you reverse that?
<LordKalma>
but that's for another week
<apritzel>
LordKalma: with hard work and a lot of code staring, I guess ;-)
<apritzel>
anyway, between that, probably some similar bits in xfel, and the fact that the DRAM controller might be related to the V3 or F1C100s, there might be some chance to get it running
<DuClare>
It's only 24kB of code, so it can't be that hard :---)
<LordKalma>
but what does that code have?
<LordKalma>
how is it generated?
<DuClare>
"a bunch of magic"
<DuClare>
Someone somewhere knows how the dram controller works
<DuClare>
For the rest of us.. if you look at existing dram code in uboot.. you will find a lot of unexplained magic
<DuClare>
It would be nice to understand it better but I think we're pretty good if someone just manages to transcribe that magic to C which we can then distribute with U-boot and compile, instead of using those binary blobs
<LordKalma>
I'm sympathetic with that
<LordKalma>
dunno if I can do it
<karlp>
"blob freee!" .... sortof... not really....
<LordKalma>
I'll look at the uboot source tree when I can
<apritzel>
yeah, I was always curious to learn more about it, but it's actual rocket science, it seems
<apritzel>
there are bread crumbs here and there, for instance in some Xilinx DRAM controller documentation
<LordKalma>
karlp, getting the kernel to build from source will already be a nice achievement
<apritzel>
but it's also a moving target, AW keeps changing the IP :-(
<DuClare>
Moving target yeah, and the other question is, how the hell do you actually debug it if it doesn't work
<apritzel>
karlp: it is blob free, as we have proper open source C code, which is actually somewhat readable, beyond the usual "writel(MAGIC_VAL, BASE_ADDRESS + 0x42);"
<apritzel>
and us running that code in AArch64, when AW always used AArch32, proves that ;-)
<karlp>
apritzel: wasn't trying to disparage, sorry, just that sometimes it is just "MAGIC_ADDR_N_of_MMMM = magic_val_aaaa" ad nauseum,
<karlp>
and it doesn't really always feel all that much better than a blob.
<apritzel>
karlp: yeah, I hear you
<karlp>
and because it's now, "blob free" it ends there.
<LordKalma>
the existing dtb can be decompiled to a dts
<LordKalma>
and added to the kernel fork to get the driver going
<LordKalma>
let's see :D
<jernej>
LordKalma: I checked LCD driver a bit and it's trivial. It doesn't even communicate over SPI at all (at least I couldn't find any communication)
<jernej>
all it does is to power up/down and reset panel and provide mode data, like resolution
<LordKalma>
yes
<LordKalma>
two functions just return 0
<LordKalma>
and the others are simple :)
<LordKalma>
I'll see it gets done :) or hope to :p
<LordKalma>
want to chip it on what's required to build uboot? :D
<jernej>
let me know if it works
<jernej>
for U-Boot you just need DTS file and config
<apritzel>
the DTS file can be very simple, just CPUs, UART, maybe MMC
<jernej>
but DTS file needs to be done like other A33 boards, include A33 DTSI and just enable what it's used
<LordKalma>
the DTS file can be trivially decompiled from the existing OS
<LordKalma>
someone told me to `dtc -I dtb -O dts sun8i-r16-x6100.dtb -o ./decompiled.dts`
<apritzel>
LordKalma: that alone won't help too much, it must fit in the existing scheme, as jernej said
<jernej>
true, but if you want something that can be mainlined, you have to rewrite properly
<LordKalma>
yes sure
<jernej>
however, most nodes are already in SoC specific files, which you just include
<LordKalma>
but the only thing that isn't in mainline, as far the community knows, if just the lcd driver
<LordKalma>
*is just
<LordKalma>
and yeah, that would need some cleaning up :)
<LordKalma>
for now, buildroot also can handle all of this: both the kernel and uboot
<LordKalma>
I think I'll probably target doing this via buildroot as a quick development tool before trying to upstream
adjtm is now known as Guest1107
Guest1107 has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
adjtm is now known as Guest1118
Guest1118 has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
adjtm is now known as Guest1119
Guest1119 has quit [Read error: Connection reset by peer]