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