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
jacobk has quit [Ping timeout: 255 seconds]
montjoie_ has quit [Ping timeout: 245 seconds]
montjoie has joined #linux-amlogic
ungeskriptet has quit [Ping timeout: 246 seconds]
ungeskriptet has joined #linux-amlogic
ungeskriptet has quit [Ping timeout: 255 seconds]
ungeskriptet has joined #linux-amlogic
Daanct12 has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
hexdump0815 has quit [Ping timeout: 248 seconds]
hexdump0815 has joined #linux-amlogic
Terry13732293409 has quit [Quit: Ping timeout (120 seconds)]
Terry13732293409 has joined #linux-amlogic
Daanct12 has quit [Ping timeout: 248 seconds]
Daanct12 has joined #linux-amlogic
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-amlogic
<Kwiboo> f_: I played some with gxbb emmc support in amlimage: https://github.com/Kwiboo/u-boot-rockchip/commit/a99eadd16b9d552b7952e51e6c28d0794d4cab0b
<Kwiboo> it works, but not sure injecting code into the image like that is something that would be fine for upstream, so needs more work
<Kwiboo> did not fully test the commands mentioned in the commit message, but tested manually running something similar to that
<Kwiboo> Disassembly of the injected code: https://gist.github.com/Kwiboo/cb20f854e5da6602c4db3af5b6c3c661
ldevulder has joined #linux-amlogic
JohnnyonFlame has joined #linux-amlogic
Daanct12 has quit [Ping timeout: 245 seconds]
Daanct12 has joined #linux-amlogic
f11f12 has joined #linux-amlogic
Daanct12 has quit [Quit: WeeChat 4.0.4]
buzzmarshall has joined #linux-amlogic
f_ has joined #linux-amlogic
<f_> Kwiboo: shouldn't be too hard to write code that could relocate U-Boot SPL
<f_> After all it just moves code from 0xd9001200 to 0xd9001000, in theory
<f_> and jumps to 0xd9001000
<f_> aka. bl2_entrypoint for Amlogic/TF-A BL2
<f_> (actually jumps to 0xd9001008)
<f_> (there's a `b 0x8` at 0xd9001000)
<f_> Honestly that's trivial.
<f_> Kwiboo: I assume you used bl1.bin.hardkernel
<f_> is that right?
<f_> Today I'm cleaning up my tree and will commit some stuff, and push
<f_> then I'll apply the amlimage patch you sent :)
<f_> Now applying your patch
<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_> ¯\_(ツ)_/¯ trivial
<f_> Patch doesn't apply. I'll try rebasing.
<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_> Kwiboo: hah
<f_> Off by JUST 0x10
<f_> Kwiboo: thanks but I just applied it
<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.
<f_> =)
<f_> I'll push.
<f_> and with one command, your patch is now stored on my git server! https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/commit/?h=wip/spl&id=151cd5855af22236dca0d9758175c548d51348e8
<f_> and as promised, I'll test on a gxl board.
* f_ unpacks lepotato from its original box
<f_> I like the lepotato/lafrite packaging tbh
* f_ unscrews Pi3 casing to remove the eMMC module
f11f12 has quit [Quit: Leaving]
<f_> Hey look it works!!
<f_> <debug_uart>
<f_> GXL:BL1:9ac50e:bb16dc;FEAT:ADFC318C:0;POC:0;RCY:0;USB:0;SPI:0;CHK:A7;EMMC:400;NAND:81;SD:0;READ:0;0.0;CHK:0;
<f_> And that's it.
<f_> (obviously)
<f_> But it boots into something so I call that a win!
<Kwiboo> Nice, and great work!
<f_> Kwiboo: You did an amazing work at this
<narmstrong> great work both, this looks really promising
<f_> Thanks a whole lot for this!
<f_> narmstrong: does it? :)
<narmstrong> it definitely does!
<f_> and by the way, did gxl boot order change?
<f_> I see my lepotato tries to boot from USB first, then SPI
<narmstrong> I think it's the same across GXBB GXL, GXM and AXG (https://u-boot.readthedocs.io/en/latest/board/amlogic/boot-flow.html), it depends the value of the
<f_> Perhaps because POC=0 on my lepotato?
<f_> while it's set to 3 on my kii-pro?
<narmstrong> probably
<f_> Also I like how you can just press a button and enter USB mode, on lepotato
<narmstrong> it's a new one, it wasn't the case on the first version
<f_> I have an AML-S905X-CC-V1.0-A
<narmstrong> hmm
<narmstrong> perhaps I always had a broken potato then...
<f_> Also the GPIO pin header thing is colourful instead of plain black which looks nice in my opinion.
<f_> The button is just near the ethernet port
<f_> I'm talking about the Uboot/K11 button
<narmstrong> yep i know it, never forced usb mode for me...
<f_> Ah
<narmstrong> but I still have one of the first units
<f_> You still have some early units =)
<f_> Also I know this is going to be weird but I think lafrite is....
<f_> .....uhhh
<f_> It's small
<f_> cute french fries
<f_> I know that's weird but meh.
<f_> I like working with these 2 boards
<narmstrong> it was the first amlogic board to be shipped with mainline u-boot, which is still awesome
<f_> Awesome indeed.
<f_> mainline linux, too.
<f_> And then people in reviews get surprised by how many images they have available to them
<f_> librecomputer is one of the few vendors who get why mainline is important and benefical.
<f_> Kwiboo: I'll integrate amlimage into the device tree
<f_> Excellent
<Kwiboo> f_: Great, to define the "imagename" you could probably use a ifdef or replace/define the args prop in related soc family u-boot.dtsi
<f_> Perhaps.
<f_> For now I'm making all changes inside meson-gxbb-u-boot.dtsi
<Kwiboo> Make sense :)
<Kwiboo> Btw, the first 4k of tzram could probably be used for bss or stack, I just tested some ranges/sizes for malloc/bss/stack, and looking at https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/amlogic/gxbb/gxbb_def.h#L40-L47 there may be overlap with mailbox use
<f_> The first 4K is supposed to contain the header but since it's completly unused by U-Boot SPL I think it makes sense
<Kwiboo> Or possible use c000 starting from 0xD9014000 like the comment mention: Top 0xC000 bytes (up to 0xD9020000) used by BL2
<f_> Yeah probably
<f_> Everything up to 0xD9020000 is available to us.
* f_ checks S905X datasheet
<Kwiboo> Yep, and I guess once execution is handed off to TF-A, it will continue on to U-Boot proper, so entire tzram could also be used by tf-a
<f_> Kwiboo: in page 44, in the S905X datasheets that got published by Khadas, you can see:
<f_> Start: 0xD9000000 | End: 0xD9013FFF | AHB SRAM
<f_> Start: 0xD9014000 | End: 0xD903FFFF | <nothing>
<f_> And then you got the bootROM.
* f_ checks S905 datasheet
<f_> ¯\_(ツ)_/¯ nothing but crickets
<f_> Very incomplete S905 datasheet :X
<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
<f_> Ah there it works.
<f_> TZRAM ends at 0xD9020000
<f_> that's what the old sources say
vagrantc has joined #linux-amlogic
jacobk has joined #linux-amlogic
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-amlogic
<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
<minute> weird
jacobk has quit [Ping timeout: 258 seconds]