ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
<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
cnxsoft has joined #linux-sunxi
perr has joined #linux-sunxi
perr has quit [Remote host closed the connection]
rajkosto has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
apritzel has joined #linux-sunxi
hlauer has joined #linux-sunxi
JohnDoe_71Rus has quit []
JohnDoe_71Rus has joined #linux-sunxi
<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" .`
<LordKalma> result was
<LordKalma> grep: ./5.8.9/modules.builtin.modinfo: binary file matches: ./5.8.9/modules.builtin:kernel/drivers/gpu/drm/panel/panel-jlt4013a-pss.ko
<LordKalma> does modules.builtin means that I don't have the driver as a separate file?
<LordKalma> because I can't find panel-jlt4013a-pss.ko anywhere
hlauer has quit [Ping timeout: 480 seconds]
indy has quit [Max SendQ exceeded]
<apritzel> LordKalma: yes, that's part of the kernel image file then
hlauer has joined #linux-sunxi
indy has joined #linux-sunxi
indy has quit [Remote host closed the connection]
indy has joined #linux-sunxi
indy has quit [Max SendQ exceeded]
indy has joined #linux-sunxi
indy has quit [Remote host closed the connection]
indy has joined #linux-sunxi
<LordKalma> what file do I need to take apart then?
<apritzel> LordKalma: "the kernel", not sure if that's part of the root fs, or packaged somewhere else
hlauer has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
<LordKalma> so far I have this
<LordKalma> I tried running extract-vmlinux on that vmlinuz file, no success
<apritzel> LordKalma: do you have "binwalk" installed? That helps you find the beginning of the gzip compressed kernel image in the vmlinuz file
<apritzel> or use the zImage, not sure what's the difference between the two in your case
<LordKalma> I went to look at a firmware update image instead of the full armbian, which is itself already a hack
<LordKalma> and there's only a zImage file
<LordKalma> I tried something I saw online which was looking at some gz header signature, not much luck
<LordKalma> binwalk, great tip!
<LordKalma> some problems tho
<DuClare> That's not how you extract
<DuClare> binwalk will do it for you if you pass the right flag
<DuClare> and dd seeks in blocks, not bytes
<DuClare> Also dd's seek option is for seeking in output file
<DuClare> skip is for seeking in input file
<LordKalma> `dd if=zImage of=zImageExtracted.gz bs=1 skip=29192` ?
<DuClare> That might work
<DuClare> But like I said, binwalk would just do it for you
<LordKalma> tried with `binwalk --dd=".*" zImage
<DuClare> -e
<LordKalma> https://i.imgur.com/U6HRMT8.png this is what came out with that
<LordKalma> let me try with -e
<LordKalma> not great https://i.imgur.com/IDqmxUv.png
<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
<LordKalma> btw I tried the same again: https://i.imgur.com/r9InTNq.png
<DuClare> So you can -e it again
<DuClare> btw binwalk -eM would have extracted recursively
<LordKalma> yap
<LordKalma> but doesn't seem to have anything interesting
<apritzel> but there is little point in extracting all those blobs
<DuClare> Yea I don't know what y'all are looking for
<LordKalma> I'm going to get my radio and SSH into it, because I think that was already discovered
<LordKalma> DuClare there's a driver that th manufacturer didn't release sources
<LordKalma> it's statically linked
<LordKalma> trying to get to it
<apritzel> LordKalma: yeah, much better if you have access to a live system
<LordKalma> let me get it
<apritzel> LordKalma: try /proc/kallsyms
<LordKalma> try what, sorry?
<apritzel> LordKalma: this pseudo file should contain the symbols for the running kernel, which help you find the driver
cnxsoft has quit []
<LordKalma> like this?
<apritzel> yeah, roughly, although I would dump it and analyse that on another box
<apritzel> and keep looking for driver specific names
<apritzel> then see if you can correlate back the runtime addresses to offsets in your extracted kernel file
<LordKalma> I'm dumpig the whole disk inmto my machine
<LordKalma> `ssh root@192.168.1.21 "dd if=/dev/mmcblk2 | gzip -1 -" | dd of=image.gz`
<LordKalma> their root password is "123"
<LordKalma> oh god this copies at 300kbps
<jakllsch> use dd bs= ?
<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-"
<LordKalma> what a cool tool
vagrantc has joined #linux-sunxi
<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> extract the image from there :)
<jernej> ok, thanks
<jernej> apritzel: I'm not sure it's worth it, one mistake and everything will be even bigger mess
vagrantc has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<jernej> thanks, but I already extracted everything and initial analysis just finished :)
<LordKalma> relevant strings
<jernej> LordKalma: did ghidra find any references to those strings? mine didn't, so it's probably missing few other references
<LordKalma> how do you look for that?
<LordKalma> doesnt' seem so
<jernej> yeah, same as mine
<jernej> so biggest challenge is to find reference by hand and then start analysis from that place
<LordKalma> I just don't understand what did they call the driver symbols
<LordKalma> found it
<LordKalma> they are using the name of the controller IC
digetx has quit [Ping timeout: 480 seconds]
<jernej> hm, I would expect higher quality of decompiling...
<LordKalma> what does it mean some are in blue: https://i.gyazo.com/294024724924a0bc8165d9463eb91d5a.png
<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
<jernej> so either vmlinux to elf step didn't work well or ghidra misinterpret something
<apritzel> LordKalma: that looks like a string ...
<jernej> exactly
<LordKalma> what does the undefined r0:1 <RETURN> mean?
<LordKalma> under the function name in the asm view
<LordKalma> what looks like a string, sorry?
<jernej> if you clear code from driver_init function and look at raw bytes, you'll see that it points in the middle of "unknown error>" string
<apritzel> those weird insn at c0a20d60 translate into: "nown error>" and "<no"
<LordKalma> so the addresses are totally wrong?
<jernej> yes
<LordKalma> fuck
digetx has joined #linux-sunxi
<LordKalma> this website says the same addresses
<LordKalma> 7620 0xC04B8A50 0x00000000 LOCAL | FUNC DEFAULT 0x0001 st7701s_enable
<LordKalma> so it's the zImage to elf...
<LordKalma> jernej, any ideas?
<LordKalma> I tried https://github.com/torvalds/linux/blob/master/scripts/extract-vmlinux on the xImage, didn0t work
<apritzel> LordKalma: no surprise here, all the symbols and their addresses come from the same kallsyms source
<jernej> nothing for now, but I'll play with it a bit
<jernej> I haven't encountered such issue yet
<apritzel> I wonder if it's worth to correlate some known function in the kernel to its kallsyms address
<LordKalma> I tried the "find "1f 8b 08" and then dd from there and gzip" without success
<LordKalma> apritzel, thinking fixed offset?
<apritzel> yeah
<LordKalma> you can give an offset to zImage to elf
<apritzel> for instance something accessing a coprocessor register, that should have a rather unique opcode
<apritzel> maybe the load address plays a role here as well?
<LordKalma> the notepad file is from cat /proc/kallsysm
<jernej> apritzel: yes, that's my guess
<LordKalma> how so the load address?
<jernej> vmlinux-to-elf allows you to override it
<LordKalma> but yeah, `cat /proc/kallsysm` does show the same addresses
<jernej> apparently, autodetected base address is 0xc0100000
<jernej> apritzel: do yo know by chance what is usual base address for kernel?
<jakllsch> 0xc0100000 sounds plausible
<jernej> U-Boot load script loads kernel to 0x46000000
<jakllsch> that sounds like a physical address
<jernej> but maybe decompressor relocates it?
<jakllsch> the kernel runs in virtual address space
<jakllsch> (after startup)
<jernej> ah, true
<LordKalma> so even the addresses from `cat /proc/kallsysm` are virtual addresses?
<LordKalma> because they are the same as the elf
<jernej> LordKalma: do you have boot log from serial console with original FW?
<LordKalma> I can get ~it for you
<LordKalma> it's jus logging the boot?
<jernej> yes, but from beginning, with U-Boot messages
<LordKalma> let's see what I can do
<LordKalma> OF: reserved mem: initialized node cma@4a000000
<LordKalma> relevant?
<jernej> thanks!
<LordKalma> no, thank you!
<LordKalma> you're helping me :D
<jernej> cma is memory pool from which kernel can allocate consecutive physical memory region, used for some peripherals
<LordKalma> a friend of mine says 0xC0000000 would be more expected
<jernej> we can try :)
<jernej> looks better, but full analysis must go through
<LordKalma> you're faster than I am :p
<jernej> I'm using old laptop though, so your analysis will probably finish faster
<LordKalma> `vmlinux-to-elf --base-address C0000000 zImage image.elf`
<LordKalma> correct?
<jernej> not sure if "0x" prefix is needed or not, but yes
<DuClare> Not needed
<LordKalma> it's analyzing now
<jernej> meh, I think it's not correct
<jernej> while code is more sensible, it still contains references to middle of the string
<LordKalma> Is there a way for me to know, with the device, the base kernel address
aggi has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<LordKalma> jernej, the code looks massively better...
<jernej> LordKalma: Found it! Correct base address is 0xC0008000
<LordKalma> wow, how?! :D
<jernej> googling revealed that zreladdr in kernel scripts is responsible for that address
<jernej> and looking into arm subfolder I saw that basically all references have 0x8000 offset
<LordKalma> so cool man, thanks
<LordKalma> I'm analysing with that offset now as well :)
<jernej> and now ghidra crashed :P
<apritzel> yeah, the load offset is important, because you need at least one page where PA == VA, to enable the MMU
<LordKalma> sounds totally right!
<LordKalma> I can't believe this
<LordKalma> thank you so much!
<jernej> apritzel: I always wondered about that
<jernej> np
<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
<LordKalma> but I won't, fuck Xiegu
<jernej> :)
<LordKalma> I'll write non-trivial blocks differently
<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?
<LordKalma> X6100 is the model of the radio...
<LordKalma> what does this tell you?
<apritzel> interesting, so it's indeed a mainline based SPL
<apritzel> so the DRAM driver is within the first 24KB of this code (that's the value at offset 0x10)
<apritzel> at offset 0x60000 there is probably a U-Boot legacy image with U-Boot proper, which is not really interesting to us
<apritzel> I guess this runs already with my WIP Allwinner V5 port
<LordKalma> 0x10?|
<apritzel> 00000010 in your screenshot
<LordKalma> so it's like 24 bytes, not kbs?
<LordKalma> because there is clearly a string right after
<apritzel> the first few bytes are the so called eGON header
<apritzel> with magic, checksum, length, version info and so on
<apritzel> which is parsed by the BootROM
<apritzel> the very first word is a jump over that header
<apritzel> so this is data, but Ghidra doesn't know
<LordKalma> yeah
<LordKalma> clearly
<apritzel> (and it looks like it assumes the ARMv7 boot vectors)
<LordKalma> I selected V8, but yeah
<apritzel> v8? that's Cortex-A7 cores, right? so clearly ARMv7
<apritzel> anyway, you could use your 5 €
<apritzel> to sue them again for the U-Boot source code
pmp-p has quit []
<apritzel> LordKalma: maybe you get a discount, for two GPL projects?
pmp-p has joined #linux-sunxi
<LordKalma> hahahah
<LordKalma> this is the binwalk of the uboot
<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
rajkosto has joined #linux-sunxi
<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.
<apritzel> but that is actually much better for many SoCs
<LordKalma> holyyyy
<DuClare> "Bunch of magic writes performed by boot0" :)
<LordKalma> "/* Bunch of magic writes performed by boot0 */"
<LordKalma> hahaha yeah
<apritzel> LordKalma: yeah, that's one of the older models, we got better in the later SoCs
<jernej> well, that Xilinx documentation actually help me to understand some issues we had with H6 DRAM driver and update driver
<jernej> but that's luck
<apritzel> indeed
<LordKalma> I think uboot is above what I'll be able to do
<LordKalma> again I can't thank you enough for all the help today
<apritzel> if it's mainline based, there are actually not too many reasons to replace it
<LordKalma> apritzel, I would actually kind of like to see if be able to build from source
<LordKalma> for the simple reason that I can't distribute this
<apritzel> LordKalma: sure, and I want a pony!
<LordKalma> in fact, the guys that did the armbian for this radio are distributing the full OS releases
<LordKalma> which includes the current kernel and the uboot
<LordKalma> which is an obvious copyright violation, but eh
<apritzel> but as you said: it's a lot of work, and without having the hardware it's very tedious to do, so we should stay realistic
<LordKalma> yes
<apritzel> you could just link to those dodgy bits
<DuClare> I can't remember if S3 is supported? I wonder how much the new dualcore version differs
<DuClare> It's got the same amount of DDR3
<DuClare> .. which doesn't mean anything of course
<apritzel> DuClare: the V3s is supported, including the (integrated) DRAM driver
<apritzel> DuClare: that's what I mentioned before: chances are the DRAM IP is very similar ...
<DuClare> I have an S3 and I'm almost certain I'm running mainline uboot.. but I might be using boot0 for the dram init
<apritzel> and for the rest: I am in the middle of a V5 port, which is one example of those "Cortex-A7 new gen SoCs"
<apritzel> DuClare: yeah, S3 is just another slight variant of the V3s, I think
<apritzel> Kconfig has: config MACH_SUN8I_V3S\nbool "sun8i (Allwinner V3/V3s/S3/S3L)"
<LordKalma> this is the soc btw
<LordKalma> R16-J
<apritzel> ah, R16, messed that up ...
<jernej> ok, so that one is actually supported already :)
<LordKalma> it is? :D
<LordKalma> so that's why it's "based on mainline"
<apritzel> yeah, totally mixed that up wth some other new Soc ...
<jernej> R16 is actually relabeled A33
<LordKalma> but the hexeditor showed a string saying "X6100"
<LordKalma> during the build you can name the device?
<apritzel> any idea what that "-J" means?
<apritzel> LordKalma: that's the name of the devicetree file
<LordKalma> how so?
<DuClare> Oh gosh I mixed things up even worse. I thought LordKalma was the one asking about T113-S3
<DuClare> :D
<LordKalma> I mean that name in what I just linked
<apritzel> DuClare: me too :-D
<LordKalma> let's get things straight: R16=A33 -> Supported by mainline U-Boot? yes/no?
<apritzel> LordKalma: check configs/Bananapi_m2m_defconfig
<apritzel> LordKalma: yes
<LordKalma> okay, followup question again: how does x6100 end up here: https://i.gyazo.com/8020d18e9472ab0c1c6343be24d10ca2.png
<LordKalma> is that part of the build? giving the device a name?
<apritzel> LordKalma: read that file ...
<apritzel> CONFIG_DEFAULT_DEVICE_TREE="sun8i-r16-bananapi-m2m"
<LordKalma> will do
<apritzel> this is both used by the U-Boot build system to append the right .dts file to the U-Boot image, but also ends up in the SPL header
<apritzel> (.dtb file, compiled from the respective .dts source)
<LordKalma> so they just wrote a single file for their specific device
<LordKalma> that coudl easily be upstreamed
<apritzel> LordKalma: for support a new board, when the SoC is already supported, you basically need a devicetree and a defconfig
<apritzel> tricky part is that the devicetree file needs to go through the Linux kernel review first, and be merged there
<LordKalma> ?
<apritzel> no, something like the BananaPi file I named above
<apritzel> those files you linked are a kernel .config and buildroot config, totally unrelated to U-Boot
<LordKalma> ah ok ok
<LordKalma> can't uboot be built against a custom kernel fork that would have the devicetree file?
<LordKalma> before any of that
<LordKalma> something like this?
<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]
adjtm has joined #linux-sunxi