<qschulz>
apalos: without your patches, it reaches CLI
<qschulz>
a517796cfa5 works reach CLI on RK3588
<apalos>
but without my patches meminfo cant print all that stuff
<qschulz>
apalos: all three logs are with your patches
<apalos>
ah ok so there's a regression somewhere upstream ?
<qschulz>
the last log is the same with or without MEMINFO symbol enabled (but with your patch applied)
<apalos>
ok so the basic idea is working fine
<apalos>
The whole point is that we now configure the mmu properly
<qschulz>
if I use v2025.04-rc1 (your base; without your patches), the last log reaches CLI (but obviously no meminfo)
<apalos>
So before that wrting a const char * was 'ok'. Now it sint because it's actually RO memory
<qschulz>
oof, so that's going to likely break "a few" boards
<qschulz>
and essentially, we'll discover plenty of new bugs :)
<apalos>
yes I know, but I think its time we went past 1980 and actually configure the memory correctly
<qschulz>
or bugs that exist and weren't caught
<apalos>
qschulz: the CI also blows up on 1 qemu test, for the same reason
<apalos>
*someone* on the tests is writing RO memory
<apalos>
i just havent found time to track it and send an RRC
<apalos>
RFC*
<qschulz>
apalos: can i easily figure out where the code that triggers the abort is?
<apalos>
yes do an objdump -dS u-boot and search for a4b3b4
<qschulz>
because the next line that's supposed to be printed is PMIC: RK806, and it's not like I wrote that driver :D
<apalos>
or an address that's close to that, ELR is the address you should return to after the exception is handled
<sng>
qchulz apalos is this about the issue seen with pxe, or is it to do with the mmu configuration?
<apalos>
completely different,
<qschulz>
sng: what we're discussing today is wrt mmu conf, not pxe
<apalos>
I already ping someone tolook at the pxe thing
<apalos>
yea I pinged sng for the pxe stuff :>
<sng>
apalos so this is some mmu related issue?
<apalos>
sng: this is what my patches applied that reconfigure the mmu for proper page permissions
<apalos>
I just asked for favor so we can test them on many hardware platforms
mckoan is now known as mckoan|away
Stat_headcrabbed has joined #u-boot
persmule has joined #u-boot
sszy has joined #u-boot
frytaped has quit [Quit: WeeChat 4.4.2]
frytaped has joined #u-boot
frytaped has quit [Max SendQ exceeded]
frytaped has joined #u-boot
<qschulz>
apalos: ok, found the bug, will send patches soon. With my soon-to-be-sent patches on top of your branch, I get the following for RK3588 Tiger: https://paste.ack.tf/1bf004
<apalos>
qschulz: ok, I think I need to send the RFC soon, since I suspsect there's a bunch of cases like that
<qschulz>
apalos: yeah I'm afraid this may take a long while to merge :/ but we need to start some day :)
<apalos>
qschulz: even the current patches are bit of a meeeeeh
<apalos>
It only runs on arm calling an arch specific function
<apalos>
But since we dont have an MMMU API in place, I think that's ok, and we can extend it in the future if more archs care
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<apalos>
qschulz: are you maintaining rockpis btw?
<apalos>
UEFI capsule updates are kind of broken but the fix is minimal
Stat_headcrabbed has joined #u-boot
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
yann-kaelig has joined #u-boot
mmu_man has joined #u-boot
<qschulz>
apalos: no, don't even have any
<qschulz>
if it's the Radxa ones you're talking about, just ping naoki :)
<naoki>
well?
leah has quit [Ping timeout: 246 seconds]
<qschulz>
naoki: apparently UEFI capsules broken on RockPi, don't have more info on that than what apalos said :)
Stat_headcrabbed has joined #u-boot
<naoki>
qschulz: Just a few hours ago I wanted to remove the CONFIG_EFI_CAPSULE_FIRMWARE_RAW line from ROCK Pi 4 configs ;)
<naoki>
I don't know what UEFI capsules is...
<naoki>
then,
<naoki>
good night :)
<qschulz>
night night
naoki has quit [Quit: naoki]
<sng>
qschulz can you share the values of pxefile_addr_r and kernel_addr_r on your platform. when i try this on the qemu arm64 virt platform, i get a crash when the two addresses overlap when downloading the kernel
<sng>
qschulz okay, thanks. and from what address does the DRAM start
<qschulz>
0x0 IIRC
<qschulz>
though the first 2MiB are reserved for BL31 use
<sng>
qschulz yes i see CFG_SYS_SDRAM_BASE as 0x0
leah has joined #u-boot
<sng>
qschulz i tried with the pxefile_addr_r at 0x46000000; kernel_addr_r at 0x44000000. with a 41MB kernel, I am not seeing these messages on qemu arm64.
<sng>
qschulz maybe when are you working on the board, can you check the output of bdinfo before you have issued the pxe commands. maybe put the bdinfo command output in pastebin.
<Tartarus>
OK, whacked my local scripts to generate and save the junit files from pytest, posted a patch now so that gitlab will make it available to download (azure already does this)
saimazoon has quit [Ping timeout: 252 seconds]
haritz has joined #u-boot
haritz has joined #u-boot
totkeks has quit [Ping timeout: 248 seconds]
flyback has quit [Ping timeout: 260 seconds]
flyback has joined #u-boot
ikarso has joined #u-boot
<dsimic>
marex: the v2 of the "usbkbd" patch is pretty much done, I just need to write the patch descriptions and, of course, to test it all
<dsimic>
as a "bonus level", :) I didn't stop at what we discussed, so there will also be a small surprise in form of some additional features, so to speak
joeskb7 has quit [Quit: Lost terminal]
mmu_man has joined #u-boot
<dsimic>
though, IDK is that worth calling a suprise, but we'll see :)