<Kwiboo>
hehe, yep I just used the code from bl1.bin.hardkernel, took a closer look and it basically does: memmove(0xd9001000, 0xd9001200, 0xb000); flush_dcache_range(0xd9001000, 0xd900c000); goto 0xd9001000;
<f_>
the master branch is now up-to-date with upstream
<Kwiboo>
also look like relocation code from bl1.bin.hardkernel also check exception level and enable i-cache, but agree it is trivial
<f_>
I rebased. Trying to apply your patch again
* f_
is fighting against his email client
<Kwiboo>
one thing that I thought was funny is that the headers in bl1.bin.hardkernel possible use wrong offsets, BL1 may jump to 0xd900410 instead of 0xd900400 for emmc and 0xd9001010 for sd-card
<f_>
Finally it works.....still have to learn how to use aerc =)
<f_>
had to pass -m to :pipe so that it pipes the entire message head & body.
<f_>
Else git becomes confused
<f_>
I'm compiling and then I'll check to see if it works!
<Kwiboo>
bl1.bin.hardkernel use a header with "Payload 0: 45056 @ 0x1000" and the header generated by aml_enctypt_gxb and mkimage amlimage etc use "Payload 0: 45056 @ 0xff0"
<f_>
0xff0 vs 0x1000
<Kwiboo>
same for the emmc header: 45056 @ 0x400, instead of the one with aml_chksum: 48128 @ 0x3f0
<Kwiboo>
more correctly, aml_chksum would use 45056 @ 0x3f0, with the code I tested with emmc in mkimage amlimage it used a payload length related to offset and end of full payload
<f_>
just noticed the payload size was wrong in aml_chksum
<f_>
Looks like it doesn't care about most of the header :S
<Kwiboo>
BL1 only failed CKH when total size was too large to fit in the 0xc000 data read
<f_>
Yeah but with aml_chksum it works fine doesn't it?
<f_>
Oh
<f_>
It will work fine, yes
<f_>
Either way yes the size looks wrong
<Kwiboo>
not sure it use any of the other offset/size, possible the BL2 code use the other offset/size for the BL3 FIP parts
<f_>
Yeah, perhaps.
<f_>
Kwiboo: nice work, it seems to work as expected.
<Kwiboo>
in tf-a the bootrom are is defined as TZROM, so is probably read-only, and I think in old bl2 source, they defined TZRAM SIZE as 0x20000 and not 0x14000
<f_>
Indeed.
<f_>
0xD9040000 is where the bootROM resides
<f_>
Wait, is git.vitali64.duckdns.org down?
<f_>
Still responds to ssh....
<f_>
So it's DuckDNS
<f_>
Damn
<Kwiboo>
Anyhow, do not trust the bss/stack/malloc addr and size I picked, I only picked some 4k aligned values and hoped that it would make it work :-)
<f_>
lol
<Kwiboo>
so they could need a review/tuning if they are adequate for SPLs usage
<f_>
that sucks...duckdns isn't working as expected
<f_>
One of the few reasons why my server can't achieve 24/24 uptime :c
jacobk has joined #linux-amlogic
* narmstrong
is happy to have a non-volatile ipv4 address
jacobk has quit [Ping timeout: 258 seconds]
<f_>
not even `curl`ing from my own server works ¯\_(ツ)_/¯
<f_>
so duckdns is b0rked
<f_>
So I'll have to use something else for referring to old Amlogic BL2 sources
<f_>
I usually prefer linking to my archived version but duckdns is down ¯\_(ツ)_/¯
<f_>
and I'll have to say that I'm definitely not one of those people who like using GitHub for anything
<f_>
Oh, and git doesn't work either
<f_>
narmstrong: I have a non-volatile address
<f_>
195.15.242.30, has stayed the same for many years
<f_>
and it still works.
<f_>
(although it will return a 404 error)
<f_>
ah, and doubles as a pastebin viewer for some weird reason..I really should properly configure nginx
<hexdump0815>
xdarklight: is anything special required trying to get hdmi working using your tree for meson8?
<hexdump0815>
xdarklight: i remember some u-boot env variable having to be set maybe and that the console is not working, but xorg
<hexdump0815>
xdarklight: do i remember that correctly or wrong?
<hexdump0815>
xdarklight: if anything special is required, is there any documentation about it somewhere?
f_[xmpp] has joined #linux-amlogic
<f_>
I'll go.
f_ has quit [Ping timeout: 245 seconds]
jacobk has quit [Ping timeout: 246 seconds]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 255 seconds]
Daanct12 has joined #linux-amlogic
Danct12 has quit [Ping timeout: 250 seconds]
jacobk has joined #linux-amlogic
JohnnyonFlame has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #linux-amlogic
JohnnyonFlame has quit [Client Quit]
jacobk has quit [Ping timeout: 246 seconds]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 246 seconds]
jacobk has joined #linux-amlogic
<minute>
hmm, i've upgraded my laptop with a311d to kernel 6.5 (rebased my small patchstack) and now i think the cpu is/are much slower and i can't see cpu freqs anymore in htop
<minute>
which driver populates the cpufreq nodes on meson / g12b?
<minute>
ok, the problem was that cpufreq_dt_platdev is now a module (maybe debian's decision?) and has to be loaded manually