narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - official channel moved from Freenode - publicly logged on https://libera.irclog.whitequark.org/linux-amlogic
naoki has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 252 seconds]
hexdump0815 has joined #linux-amlogic
JohnnyonFlame has quit [Ping timeout: 252 seconds]
buzzmarshall has quit [Quit: Konversation terminated!]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 252 seconds]
jacobk has joined #linux-amlogic
mripard has joined #linux-amlogic
gis has quit [Quit: leaving]
zsoltiv_ has quit [Ping timeout: 246 seconds]
jacobk has quit [Quit: No Ping reply in 180 seconds.]
jacobk has joined #linux-amlogic
paddymahoney has quit [Ping timeout: 246 seconds]
paddymahoney has joined #linux-amlogic
f_ has joined #linux-amlogic
<f_> hi Kwiboo ! Nice to see here!
<f_> I should dig more into gxlimg to figure out what to do.
<f_> Especially because since I'm trying to replace Amlogic BL2 with U-Boot SPL, accoding to my reverse-engineering notes & old sources BL2 takes care of most of the FIP packaging (obviously), so ~90% of gxlimg would be useless if using U-Boot SPL.
<f_> For gxbb I'll, as said before, assimilate what aml_chksum does, and create 2 headers. For gxl I'll create one. Honestly unifying gxbb and gxl signing, doing just enough for BL1 to run whatever's in the first 48K (BL1 reverse-engineering notes show that BL1 indeed loads exactly 48K), should be easy.
<f_> Perhaps an option to switch between gxbb and gxl signing should be enough.
<f_> Integrate that into U-Boot's build system, and here we go from a bazillion commands to a simple `make` and `dd if=u-boot-gxbb-with-spl.bin of=/dev/mmcblk0`.
<f_> That's my plan.
<narmstrong> good plan, best plan even so far :-)
<f_> Thanks!
<f_> That's for signing...but that assumes my U-Boot SPL binary works
<f_> which...I have no idea if it does
<f_> and unless I'm a magician I doubt it'll work on the first try.
<f_> Kwiboo: A quick peek at amlbootsig v.s. amlbootsig-gxl shows that only the header version seems to have changed.
<f_> from 0x1 (gxbb) to 0x0101 (gxl)
<f_> You were right.
<f_> Ah, and BL2 doesn't seem to be encrypted
mripard has quit [Quit: mripard]
<f_> narmstrong: and if I manage to get SPL to work, I should be able to maintain this upstream if you want.
<f_> Will probably be disabled by default though ^^
<narmstrong> f_: sure, if you want you can send an RFC first that adds SPL disabled-by-default so we can see how much is needed, then probably merge it if it can have an immediate utility (like falcon mode)
mripard has joined #linux-amlogic
gis has joined #linux-amlogic
gabes2 has quit [Quit: The Lounge - https://thelounge.chat]
gabes2 has joined #linux-amlogic
<f_> Sure.
<f_> I will send RFCs, for sure.
<f_> narmstrong: Should I include gxl support as well?
<narmstrong> Sure, it should be enabled on all arch
<f_> all SoCs....don't think that will be possible for now
<f_> gxbb and gxl first, then ¯\_(ツ)_/¯
<f_> cottonwood looks like it should be the perfect fit for a g12 board but I still don't know what to choose....or if I'll acquire a g12 board at all.. ¯\_(ツ)_/¯
<f_> But some libre software community once said "change the world, one byte at a time"
<f_> g12 isn't my main concern for now.
JohnnyonFlame has joined #linux-amlogic
<narmstrong> vim3 is so far the best g12 board, followed by n2 and c4, but yeah cottonwood will be a game changer since 100% upstream-only supported
<f_> Yeah I kinda like librecomputer boards now
<f_> and lvrp16 is a nice person ¯\_(ツ)_/¯
<f_> But honestly I don't care much about if it's the best, I care about the fact that it works well.
<narmstrong> I still haven't met him in person yet, perhaps I will in sept this year!
<lvrp16> narmstrong: we met several times already 🤣
<f_> 🤣
<narmstrong> lvrp16: nah we never met!
<lvrp16> Oh right that was the other armstrong.
<narmstrong> lvrp16: last time we could at ER/KR I wasn't here
<lvrp16> The moon one.
<f_> >the moon one.
<narmstrong> lvrp16: probably at the early amlogic story at an US ELC, but it was too long ago...
<lvrp16> narmstrong: yes it has been too long 😊
<f_> first time narmstrong shows up in real life after so many years
<f_> narmstrong: What are you going to talk about in september?
<narmstrong> honestly I didn't show in public events (except linaro connect) since nov 2019
<lvrp16> The cottonwood followup will be better for custom designs.
<lvrp16> Spec is already done, getting designed as we speak.
<narmstrong> noice!
<lvrp16> f_: If you get u-boot SPL, I will have to send you a box of choclates or wine or something.
<f_> lol
<f_> At some point I wanted OpenBSD on my set-top box
<f_> the end
<f_> I just wanted OpenBSD on my set-top box
<f_> Didn't actually work on it, but thought it would be cool.
<f_> lvrp16: You don't have to send me anything if it works BTW :) just the fact that it works (if it'll work) makes me happy
<f_> It'll make me happy.
<lvrp16> I think NetBSD runs on Le Potato with EFI framebuffer. Not OpenBSD but I am not familiar with the BSDs.
buzzmarshall has joined #linux-amlogic
<f_> Sure
<f_> OpenBSD was originally a fork of NetBSD so..
<f_> But I think seeing OpenBSD running on a set-top box or lepotato/lafrite will also make someone else happy :)
naoki has quit [Quit: naoki]
<f_> Also, I'd like to update the lepotato/lafrite binaries in that libreelec repo
<f_> It's a really useful repo with a simple script you run, which is why we mostly use this on Amlogic device ports.
<Kwiboo> f_: if I remember correctly from my old aml/gxbb hacking days a valid header and sha256 checksum was enough, a valid rsa signature was only needed in a secure boot scenario
<f_> Yeah I think that should be enough to get it to boot.
* f_ opens a gxbb bootROM dump in ghidra
<Kwiboo> does U-Boot already contain code for DRAM init? or how will that work? BL2 does DRAM init if I recall correctly
<f_> No, but I'm reverse-engineering and reimplementing that stuff.
<f_> And yes, BL2 does DRAM init.
<f_> Haven't pushed anything yet though.
<f_> Actually, let me push now.
<Kwiboo> ahh, cool :-)
<f_> I didn't have any gxl board before though, until lvrp16 sent me some gxl boards
<f_> So I'll also port to gxl :D
<f_> https://git.vitali64.duckdns.org/misc/reversing-gxbb-bl2.git/ contains actual disassembly and decompilation of BL2
<f_> and BL1, too, as well as BL1 dumps from my KII Pro set-top box and lepotato
<f_> fun fact, BL1 does load exactly 48K https://git.vitali64.duckdns.org/misc/reversing-gxbb-bl2.git/tree/bl1/kii-pro/bl1.c#n239 including the header
<Kwiboo> I got a little bit confused about the initial 16 byte random data yesterday when I checked gxlimg, but looking back at https://github.com/Kwiboo/u-boot/commit/6d0a17632922077a2e64b13ae1a6bdf0024b718f it explains the 16 byte offsets, I just ignored the random data completely back then
<f_> The random data is...well...random
<f_> in a local work of meson-tools I made it output the string "_amlbootsig_gxbb" instead of the random data.
<f_> *fork
<f_> Works fine.
<f_> Kwiboo: Nice work you did there though, for making one single binary that can be booted from both SD and eMMC at the same time.
<f_> very hacky for now. I'll clean it up before sending patches.
<f_> ...and after testing :P
<f_> I just copy-pasted this from TF-A
<f_> But at least it compiles :P
<Kwiboo> Nice and very cool stuff! :-)
<f_> Thanks!
<f_> Since I have bootROM dumps let's take a look at where the header offset is set.
<f_> I collected some bootROM dumps lately :)
mripard has quit [Quit: mripard]
GNUtoo has joined #linux-amlogic
* f_ gets distracted and boots up his lepotato with an SPI display attached.
vagrantc has joined #linux-amlogic
jacobk has quit [Ping timeout: 246 seconds]
jacobk has joined #linux-amlogic
<f_> SPI+HDMI display works BTW but touchscreen doesn't work =(
jacobk has quit [Ping timeout: 252 seconds]
<f_> (I need a device tree overlay)
<f_> Back to Amlogic signing stuff! lol
<lvrp16> f_: ILI9486?
<f_> The screen itself is HDMI but touchscreen is XPT2046.
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 246 seconds]
<f_> Now that I think about this...did anyone try to set nDataOffset to the offset where BL2 is found?
<f_> Kwiboo: ^ have you tried this?
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 252 seconds]
jacobk has joined #linux-amlogic
<Kwiboo> f_: yes that should be the start code or similar, offset from header start, it is the main thing that is changed/fixed header is used for in aml_chksum
<Kwiboo> 1024-1315: code that copies bl2 from 4608 to 4096
<Kwiboo> and as mentioned in my commit message: 16-111: eMMC header+checksum (start addr set to 1024)
<f_> Yeah but what if you set it to 4096?
<f_> Ah but then the base address could be incorrect...
<Kwiboo> yes, it is based from the @AML start
<f_> Yeah indeed....all that because of this tiny code snippet:
<f_> I think this is why BL1 has the zero-offset requirement.
<f_> U-Boot SPL is tiny
<f_> Perhaps have some code at offset 1024 that simply jumps to 4608?
<f_> (seems to be less than 48K, so should perhaps work)
<Kwiboo> something like that, if I remember correctly the bl2.bin had start code set to 4096-16 from header start, somewhere in bl2 there was a += 512 similar to your code snippet that had to be patched out, cannot remember why that += 512 had to be removed
ldevulder has quit [Quit: Leaving]
<Kwiboo> then u-boot.bin.hardkernel had some minimal code that basically just memmove(data_addr - 512, data_addr), this code was put at 1024-16 from header and used as start code for emmc header, nDataOffset=1024-16
<Kwiboo> after memmove then there was a jump to regular 4096-16 offset, or a bunch of nop until it reached regular code for bl2
<Kwiboo> to in theory you can put your at whatever aligned offset you like and have nDataOffset point to it, and bl1 will jump to it
<f_> Sure.
<f_> I'll have to go. I still check public logs daily though.
<f_> (daily as in, literally every day)
f_ has quit [Ping timeout: 246 seconds]
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-amlogic
<hexdump0815> lvrp16: when you asked about the a55 vs a53 regression - was that on some amlogic board?
<hexdump0815> i'm asking as i saw terrible performance in some scenarios with s905x3 - much worse than for instance s905x2 even
<hexdump0815> i did not really find out what exactly is the reason - the only thing which looked a bit different was the l1 cache size maybe according to tinymembench
<hexdump0815> it looked a bit like it only had 16k instead of the otherwise usual 32k l1 ... all not very scientifically tested, but i think it was reproducable across a few s905x3 tv boxes
<hexdump0815> maybe for your case also run tinymembench and check the l1 and l2 cache size according to the memory latency test at the end
JohnnyonFlame has quit [Ping timeout: 244 seconds]
<lvrp16> hexdump0815: it was a relatively large regression for all A55, even RK3566/RK3568. the stress-ng matrix benchmark does not scale beyond 2 cores. it could be cache size. 1 core gets 500 points, 2 core, 700, 3 cores 750, 4 cores 760. a53 scaled linearly up to 1100+ bogus operations/s.
<lvrp16> cortex a53 had a loss of 25 bogus operations per second per extra core. cortex a55 had an exponential loss per extra core that rapidly reached 0.
jacobk has quit [Ping timeout: 252 seconds]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 252 seconds]
JohnnyonFlame has joined #linux-amlogic