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)
<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_>
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
<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.
<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.