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
montjoie has quit [Ping timeout: 255 seconds]
montjoie has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
jacobk has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 255 seconds]
hexdump0815 has joined #linux-amlogic
buzzmarshall has quit [Quit: Konversation terminated!]
<narmstrong> Indeed, thx for finding that
ungeskriptet7 has joined #linux-amlogic
ungeskriptet has quit [Ping timeout: 255 seconds]
ungeskriptet7 is now known as ungeskriptet
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-amlogic
jacobk has quit [Ping timeout: 255 seconds]
mripard has joined #linux-amlogic
orkid has quit [Ping timeout: 246 seconds]
orkid has joined #linux-amlogic
f_ has joined #linux-amlogic
<f_> hi all.
<f_> Kwiboo: I've been thinking about this, for booting gxbb from eMMC and SD card with no offset change in `dd`
<f_> When compiling amlimage, also compile the code which will relocate SPL, and have amlimage use that compiled code
<f_> Make use of the cross compiler for compiling that tiny piece of code
<f_> and perhaps have amlimage use that binary
<f_> Perhaps pass it as an argument of use a hardcoded path?
<f_> *or
<f_> What do you think about this?
<f_> Really love what you've done by the way. amlimage really works perfectly, for its intended purpose.
<f_> (try passing a bl2.bin into amlimage and see your BL2 crash!)
<f_> (Amlogic bl2.bin)
<f_> You just compile it and flash
<f_> ^ in my case, compile, lsblk to make sure, dd
<f_> Have weird logs though.
<f_> Especially where it prints some TZRAM addresses out.
<f_> While at it we should find where the BSS is located when using Amlogic's bl2
* f_ opens Ghidra.
<narmstrong> f_: to be upstreamed the relocation code should also upstreamed and with a valid licence, rhen for example a script could be added that compiles the assembly and updates the amlimage.c file with the binary output
<f_> ldr x0=>DAT_d900a580,DAT_d9001058
<f_> bl zeromem16
<f_> ldr x1,DAT_d9001060
<f_> narmstrong: Of course!
<f_> The code is trivial anyway
<f_> so reimplementing under GPL-2.0+ shouldn't be hard at all.
<f_> but what I just pasted above is what I see in ghidra
<f_> This zeroes out the BSS region and is identical to this, in the old sources: https://git.vitali64.duckdns.org/archive/amlogic-bl2.git/tree/bl2/aarch64/bl2_entrypoint.S#n84
<f_> That's our BSS address!
<Kwiboo> hehe, yep, that is the code and bl2_main with memcpy, flush range then jump
<f_> (at least what's set in their BL2)
<Kwiboo> btw, updated my commit with some more relevant comments, more fore documentation purposes: https://github.com/Kwiboo/u-boot-rockchip/commit/57f7aa31e299068fef681e56f8c78aad85bf8390
<f_> nice
<Kwiboo> also think we need to do something similar to what narmstrong suggest, have some way to recompile and update the bundled code, so that a cross compiler is not required when using tools-only_defconfig to build mkimage/amlimage
<f_> Perhaps
f_[xmpp] has quit [Ping timeout: 248 seconds]
* f_ is the dumbest person humanity has ever seen.
<f_> Jokes aside, I messed something up in my rebase.
<f_> The stack and bss address was the same...
<f_> That, along with "fixing up" the serial driver, we got to the point where it tries to load from MMC2 but fails.
mripard has quit [Quit: mripard]
<f_> hmm MMC driver returns ENODEV
<f_> uclass_find_device_by_seq is the one complaining.
<f_> It doesn't seem to find the MMC device, which in this case is an SD card
jacobk has joined #linux-amlogic
mripard has joined #linux-amlogic
<f_> Perhaps some device tree thing
<f_> which I forgot
<f_> lvrp16: By the way, lepotato doesn't output anything to my 3440x1440 monitor, after loading linux
<f_> I think it's a known issue though, but since U-Boot outputed a 1920x1080 resolution I expected linux would do the same, but it didn't.
<f_> No device gets detected at all.
<narmstrong> f_: did you keep the mmc device for spl ? AFAIK there's a DT nodes filtering and you may need to select which nodes are kept
<f_> I think I did that?
<f_> https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/commit/?h=wip/spl&id=1d09d5ad5aa9a7406e1cd5fb407a3c318e0d0696 is this how?
<f_> narmstrong: This is what I currently have in meson-gxbb-u-boot.dtsi: https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/tree/arch/arm/dts/meson-gxbb-u-boot.dtsi?h=wip/spl
<narmstrong> f_: you may also need to add it to all dependencies, clock, pinctrl, etc
<f_> Yeah probably.
<Kwiboo> f_: there is a CONFIG_SPL_DM_SEQ_ALIAS that will help preserves aliases from device tree in spl
<f_> hm
<f_> Not that we're very space-constrained..I'll add it
<f_> Ah
<f_> 43K
<Kwiboo> Hehe, yeah, also recommend you check the u-boot-spl.dtb with dtc and see if all relevant info is present
<f_> Good idea
<Kwiboo> try enable CONFIG_LTO to help reduce space
<f_> Looks like everything is there?
<f_> except `sdcard` is empty, `sdcard_clk_gate` also empty, ...
<f_> But still, no change.
<f_> Seems like the sd_emmc_* nodes (except sd_emmc_a) are inside apb@d0000000
<f_> >bind node apb@d0000000
<f_> >Device 'apb@d0000000' has no compatible string
<lvrp16> f_ that us a long standing issue in the clock setup
<lvrp16> Need to tune it but I don't have that kind of monitor.
<f_> lvrp16: ah yes, I saw a very long thread on the discourse instance
<f_> Many people there also mentionned that it didn't work on their 3440x1440 monitor
<f_> still weird that I can see U-Boot logs from that monitor when it's booting
<f_> (but U-Boot's driver for that kind of stuff looks minimal)
<f_> lvrp16: By the way, I've seen that monitor sometimes reporting a 4k resolution when running LibreELEC on a raspberrypi. When setting that 4k resolution (obviously bigger than the native resolution) it still seems to work
<f_> I could perhaps force a 1080p resolution for now (I don't mind) somehow
<f_> perhaps hardcode resolutions in X11
<f_> Or...use my tiny SPI+HDMI display for the time being
<f_> (display is HDMI, touchscreen is SPI)
chewitt has joined #linux-amlogic
<f_> Still have to figure out why it can't detect any MMC device
<f_> probably something I forgot to do..
<f_> I should perhaps paste logs
vagrantc has joined #linux-amlogic
<chewitt> ^ some prior art on using binman
<chewitt> am just reading the last week or so's backlog .. nice work :)
<f_> I or Kwiboo should probably reply to this, linking to amlimage
<f_> amlimage supports gxbb, gxl, and sm1
<chewitt> Simon was looking for me to test the patches but I was buried in work at the time and this stuff is a little above my head
<f_> amlimage is intended for use with U-Boot SPL though, and as such only does what's necessary for BL1 to load it.
<narmstrong> f_: it looks it doesn't even search for mmc
<f_> narmstrong: Which file?
<f_> chewitt: So I'd guess using amlimage with the proprietary BL2 binary will end up not working at all, but it's still a nice starting point.
<narmstrong> f_: looking at the boot log, it does find the vpu node, but when looking for mmc is doesn't even look for the node
<f_> hm
<narmstrong> f_: can you dump the dtb attached to the spl ?
<f_> Sure.
jacobk has quit [Ping timeout: 258 seconds]
<f_> chewitt: Honestly in my opinion including aml_encrypt into U-Boot is a bad idea..especially when you have libre/open-source reimplementations
<f_> But even with these reimplementations you still have e.g. amlbootsig for gxbb, and gxlimg for gxl, etc
<f_> Too many different tools.
<f_> ...all that because Amlogic thought reimplementing a firmware packaging format was a good idea :/
<f_> (and making it very different across SoCs)
<f_> (fourtunately they kept the BL2 signing process the same..just one header at offset 0 or 512, largely one of the few things being mostly identical across SoCs)
jacobk has joined #linux-amlogic
<f_> narmstrong: Am looking at the code and device tree
<f_> >bind node apb@d0000000
<f_> >Device 'apb@d0000000' has no compatible string
<narmstrong> f_: you're missing all the clock, reset & pinctrl nodes
<f_> >apb: apb@d0000000 {
<f_> > compatible = "simple-bus";
<f_> narmstrong: Should've known!
<chewitt> f_: that RFC from Simon reflects his limited understanding of Amlogic specifics
<chewitt> it wrongly assumes the signing process is the same for all boards/generations .. which is not the case
<f_> At least the process to sign bl2 is the same for all generations
<f_> (not the same commands, but the overall logic is mostly the same)
jacobk has quit [Ping timeout: 258 seconds]
<chewitt> yup, should be something that can be borrowed from
<f_> chewitt: Also reflects that ODROID-C2 != ODROID-C4
<f_> He assumed that C2 == C4
<chewitt> yeah, he got confused a bit there
<f_> He could possibly borrow some of amlimage to sign BL2, yes.
<f_> But then again, amlimage only does ~10% of what aml_encrypt does.
<f_> (that works fine for running U-Boot SPL, but BL2 won't like it)
<f_> So he would also need to borrow some other bits and pieces from other reimplementations.
<chewitt> I'm highly confident Simon will be delighted for someone to send their own RFC patches that supersede his .. with something that works
<narmstrong> implementing a full open source tf-a using SPL would be the ultimate supersede :-p
<chewitt> now that pandora's box is open .. it's just a case of assembling all the bits :)
<f_> Would be even better if we could make U-Boot SPL work
<f_> branch: wip/spl
<f_> I integrated Kwiboo's amlimage patch he sent to me in that branch too.
<f_> So you can pretty much:
<f_> $ make videostrong-kii-pro_defconfig
<f_> $ make
<f_> $ sudo dd if=u-boot-gxbb-with-spl.bin of=/dev/sdb bs=512 seek=1
<f_> Kwiboo really did a nice work there :)
<f_> narmstrong: We got further!
<f_> spl: could not initialize mmc. error: -38
<f_> $ errno 38
<f_> ENOSYS 38 Function not implemented
<f_> But it finds it now.
<f_> I'll clean up and commit.
<f_> In the meantime should I tell Simon that an effort exists to bring U-Boot SPL to amlogic SoCs?
<f_> (in the thread)
<chewitt> sure, if you like
<f_> He could probably find it or amlimage interesting.
<chewitt> Simon's day-job is "everything to do with u-boot"
hexdump0815 has quit [Quit: WeeChat 1.9.1]
<f_> *and coreboot
<f_> I see him talking in #coreboot from time to time.
hexdump0815 has joined #linux-amlogic
<chewitt> so he'll be interested .. and also mildly relieved that someone else took any interest in one of the 2,894 things on his to-do list :)
<f_> :)
<hexdump0815> chewitt: now that you are around as well :) - do you maybe remember what was needed to get hdmi out working with the xdarklight tree on meson8 systems (s805/802/812)?
<hexdump0815> i'll be afk for a bit now, but i'll read the logs afterwards
<chewitt> off the top of my head .. no
<chewitt> but i'll see what crib notes or code I have lying around..
<hexdump0815> and maybe looking deeper, like in your libreelec repo? :) ... i think you once built a working hdmi mainline image iirc ...
<hexdump0815> a lot of thanks in advance already
<chewitt> have you tried appending video=HDMI-A-1:1920x1080M@60D to boot params?
<chewitt> https://chewitt.libreelec.tv/testing/LibreELEC-AMLMX.arm-10.85.0-odroid-c1.img.gz <= works, except for boot config which needed manual juju
<chewitt> there's a "box" image in the same webserver folder that has other device-trees
<chewitt> the C1 image packaging is wrong .. because the current LE packaging assumes some things that the prehistoric C1 u-boot hasn't implemented yet
<chewitt> but if you manually drop into u-boot console and run the appropriate boot commands .. things did boot
<chewitt> I think Martin's patches for HDMI evolved a bit since the 10.85.0 image (Feb '22)
<chewitt> (hence the newer 10.88.0 image) .. but I ran out of time to test
<chewitt> plus, the only other device I have is a WeTek Core (S812) and this hits an issue with secureboot that is only worked-around by crippling the kernel to a single CPU core
<chewitt> and that makes test rather un-fun
jacobk has joined #linux-amlogic
ndufresne9 has quit [Quit: The Lounge - https://thelounge.chat]
<Kwiboo> f_: narmstrong: I re-implemented the relocation code and compiled it with gcc 13.2, resulting code is optimized and bare minimum: https://github.com/Kwiboo/u-boot-rockchip/commit/37f9564fc3d6bfc93a39997b12e62954099e6504
<f_> Amazing!
<f_> narmstrong: my mail to linux-amlogic is awaiting approval it seems
<f_> >Message has a suspicious header
JohnnyonFlame has joined #linux-amlogic
<narmstrong> Kwiboo: nice optimization !
<f_> aaaand the In-Reply-To header got messed up
JohnnyonFlame has quit [Read error: Connection reset by peer]
<Kwiboo> gcc 13.2 wanted to optimize, at all levels, to use memmove without the use of -ffreestanding flag
<narmstrong> f_: no idea which header is suspicious
<f_> No idea either, perhaps the In-Reply-To header I tried to add in aerc
ndufresne has quit [Quit: The Lounge - https://thelounge.chat]
Daanct12 has quit [Remote host closed the connection]
ndufresne has joined #linux-amlogic
Danct12 has joined #linux-amlogic
ndufresne1 has joined #linux-amlogic
<f_> I'll go.
f_ has quit [Ping timeout: 246 seconds]
<hexdump0815> chewitt: thanks a lot for the pointers - i'll have a look at the images etc.
<hexdump0815> f_: Kwiboo: and while already writing here, i also just wanted to say that its quite amazing to follow how you are progressing - this is open source collaboration at its best ...
jacobk has quit [Ping timeout: 255 seconds]
ndufresne1 has quit [Ping timeout: 250 seconds]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 246 seconds]
jacobk has joined #linux-amlogic
iprusov has quit [Quit: WeeChat 3.5]
iprusov has joined #linux-amlogic
jacobk has quit [Ping timeout: 246 seconds]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 246 seconds]
jacobk has joined #linux-amlogic