lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<DC-IRC> <amazingfate> It's a devicetree issue.
<DC-IRC> <microlinux> Ok
DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian-rockchip
<DC-IRC> <catalin.adler.02> as a long time windows user and linux wanna be since the 90s i find all the linux story as complex and unusable as always. in the begining there was no traction now there's extreme fragmentation. net result is ... a lot of fun to put it mildly 😄
belveder79 has joined #armbian-rockchip
<belveder79> hey... anyone here that could help me with the device tree of a nanopc-t6? I'm trying to get the MCAM400 from nanopc-t4 to run on the nanopc-t6, but I'm failing miserably...
<DC-IRC> <rpardini> @amazingfate ref the Opi3B DT for mainline you added to rockchip64-edge: did you notice we've no UART? Just wondering if you already tried something
<DC-IRC> <amazingfate> I haven't tested uart in mainline kernel.
<DC-IRC> <rpardini> Oh ok, I'll try my hand at enabling `uart2` and adding the alias, seems to be all that is missing.
<DC-IRC> <amazingfate> I find that xunlong's uboot doesn't support fdt overlay, we need to patch it.
<DC-IRC> <rpardini> Yeah I was originally just mashing up your DT into Kwiboo's uboot actually when I noticed no UART
<DC-IRC> <rpardini> @mariob 's edk2 works (also no UART there, but might be my lack of edk2 knowledge) with PCIe too, but legacy kernel gags on NPU power domain.
<DC-IRC> <rpardini> OPi's uboot (with that _wonderful_ squashed first commit) has a hack to enable NPU power manually
<DC-IRC> <amazingfate> It there a working edk2 for opi3b?
<DC-IRC> <mariob> uart works on 3b
<DC-IRC> <mariob> in uefi
<DC-IRC> <mariob> it's set to 115200 baud
<DC-IRC> <rpardini> oh! see, I knew it was me fumbling
<DC-IRC> <rpardini> thanks
<DC-IRC> <rpardini> Yeah works perfectly in 115200 🏅
<DC-IRC> <amazingfate> Can we load dtb in grub using this edk2 firmware?
<DC-IRC> <amazingfate> I tried this edk2 on rock3a but I can't boot my iso.
<DC-IRC> <rpardini> Yep -- `grub-with-dtb` extension, and add `acpi=off` to kernel cmdline.
<DC-IRC> <rpardini> But again, on rk5.10 legacy, it panics very early due to NPU power domain. Heard we can disable NPU in DT to get around it.
<DC-IRC> <rpardini> will try with mainline soon
<DC-IRC> <amazingfate> I will try again with npu disabled.
<DC-IRC> <rpardini> NPU idea/stuff came from rock-3a indeed: https://forum.radxa.com/t/linux-kernel-giving-panic/8068
<DC-IRC> <rpardini> Same on Firefly 3568: https://bbs.t-firefly.com/forum.php?mod=viewthread&tid=3282
<DC-IRC> <amazingfate> I should have fixed it in uboot: https://github.com/radxa/u-boot/pull/19
<DC-IRC> <rpardini> Yeah I mean... vendor kernel expects uboot to presetup stuff... dunno how to workaround it using edk2
<DC-IRC> <amazingfate> Happy to see edk2 is working. A bright future is coming to us.
<DC-IRC> <mariob> it already installs a dtb, i got it from one of their official images
<DC-IRC> <mariob> not sure if that option is enabled by default though, it may just install ACPI
<DC-IRC> <mariob> you can change that in the settings
<DC-IRC> <amazingfate> Mainline and vendor dtbs differ a lot. So it's better to let grub choose the correct dtb file.
<belveder79> anyone able to tell me how to make MCAM400 visible on Nanopc-t6?
<DC-IRC> <mariob> could send a pull request to update it to the mainline dtb. didn't know rk356x had good mainline support, in this case it doesn't make any sense to supply the vendor dtb
<DC-IRC> <amazingfate> Is the dtb necessary in quartz64_uefi?
<DC-IRC> <mariob> it's hardcoded in the build script, so i'd imagine it will fail to build without it
<DC-IRC> <mariob> i'll be doing similar on the rk3588 uefi. will probably break your detection grub, but i plan to support overrides via a config file on the ESP partition
<DC-IRC> <mariob> including overlays
<DC-IRC> <mariob> i'll be doing similar on the rk3588 uefi. will probably break your smbios grub detection, but i plan to support overrides via a config file on the ESP partition
<DC-IRC> <amazingfate> Maybe we can make a configurable set in edk2 to let user decide if dtb is passed from edk2 firmware.
<DC-IRC> <mariob> yes, that's the plan
<DC-IRC> <mariob> it will pass a DTB by default (firmware is required to do that by the EBBR spec), which you can override by having it on the boot partition
<DC-IRC> <mariob> it will pass a DTB by default (firmware is required to do that by the EBBR spec), which you can override by having it on the boot partition instead
<DC-IRC> <mariob> without needing any special logic in grub
<DC-IRC> <mariob> in fact, for the overlay apply logic to work, you must not install the devicetree with grub
<DC-IRC> <mariob> cause it will overwrite the whole thing
<DC-IRC> <efectn> @mariob do you have any plan to make CPPC work? It seems a bit tough
<DC-IRC> <mariob> yeah, but that would only work if you boot in ACPI-only mode
<DC-IRC> <mariob> which provides limited linux support compared to DT
<DC-IRC> <efectn> Yeah using cpufreq patched mainline kernel sounds better than acpi-cpufreq
<DC-IRC> <mariob> it does. there's little point in using ACPI with linux as realistically speaking it will never be on par with the DT description
<DC-IRC> <mariob> it's more meant for the other OSes (esxi, windows) or even mainline linux now, given DT support there is not much better
<DC-IRC> <mariob> it's more meant for the other OSes (esxi, windows) or even mainline linux now, given DT support there is not much better at the moment
<DC-IRC> <amazingfate> Edk2 source code only has binary dtb files, which make it hard to know the decicetree's version, commit history.
<DC-IRC> <rpardini> Yeah I'd say edk2 should have a "basic" DTB, eg, mainline kernel's, just for spec compatibility... for SBCs using edk2 and Linux there's a very high probability that overlays will be needed (say enable i2c, etc) and less likely "custom" overlays too. I'd not want to burden edk2 with the overlaying? Instead just adopt something like LC's merger and use grub/whatever to load the merged DTB.
<DC-IRC> <mariob> They can be DTS files too, compiled as part of the edk2 build process, but for now I'm using plain DTBs as there's less files to work with.
<DC-IRC> <mariob> As for commit history and devicetree version, we can keep track of that in a separate file. It's really just something along the lines of "Update DTBs to armbian commit N" or similar.
<DC-IRC> <mariob> As i've said, you can still override the firmware-passed DTBs by storing them on the ESP partition, but I wouldn't rely on that because it will need to be disabled for proper SecureBoot.
<DC-IRC> <mariob> It's the firmware's job to pass the DT, even though they're kind of "tied" to the kernel used, sadly.
<DC-IRC> <mariob> It's really easy to apply overlays from edk2, there isn't any burden.
<DC-IRC> <mariob> Once mainline becomes more mature, I plan to add a setup option to switch between legacy and mainline DTB in firmware. But right now it's impossible as most boards are unsupported in mainline.
<DC-IRC> <mariob> Once mainline becomes more mature, I plan to add a setup option to switch between legacy and mainline DTB in firmware. But right now it's impossible as most boards are unsupported there.
<DC-IRC> <rpardini> Oh so we could have a DTB + overlays in the ESP, and edk2 would merge them? That could be useful, but also a 4th different way to handle overlays from Armbian perspective (1: bootscript, 2: extlinux, 3: grub with pre-merged dtb+o: 4: in ESP)
<DC-IRC> <mariob> Nothing prevents you from using pre-merged dtbs.
<DC-IRC> <rpardini> 4 could replace 3, but we support some HW that has static/dumb/old edk2 in an inaccessible flash 😐 (D2000)
<DC-IRC> <rpardini> also the x13s.
<DC-IRC> <mariob> Has 4 been done before?
<DC-IRC> <rpardini> no, actually not even 2/3 ever done
<DC-IRC> <mariob> I was looking for some standard/common-ish approach to this. Either ahve the firmware look-up files in say, a `\
<DC-IRC> <mariob> I was looking for some standard/common-ish approach to this. Either ahve the firmware look-up files in say, a `\dtb` directory.
<DC-IRC> <rpardini> (in Armbian)
<DC-IRC> <mariob> Or a config.txt file that specifies the overlays and dtb used depending on the board model.
<DC-IRC> <mariob> Similar to what rpi does
<DC-IRC> <mariob> Ideally we'd support extlinux but that's more effort than i'm willing to put into this to be fair 😅
<DC-IRC> <mariob> Mainly because it involves dealing with multiple boot options
<DC-IRC> <mariob> I was looking for some standard/common-ish approach to this. Either have the firmware look-up files in say, a `\dtb` directory.
<DC-IRC> <rpardini> Yeah in my view, having a userspace overlay selector UI and dtb merger would address all the cases, albeit being the least common denominator
<DC-IRC> <rpardini> that said, Armbian is still shipping not only dtbo's, but also "fixups" (uboot script fragments that further change the fdt)
<DC-IRC> <rpardini> origins of which are lost to history. mostly having a single dtbo for "SPI" and fixup for "exactly which SPI and at what speed"
<DC-IRC> <mariob> So what approach do you use for those efi systems?
<DC-IRC> <mariob> (assuming Arm here)
<DC-IRC> <mariob> I see amazingfate's live-iso images just loads the dtb via grub from the `live/dtb` directory on ESP.
<DC-IRC> <mariob> But grub doesn't support overlays so it's kind of a lost cause.
<DC-IRC> <rpardini> So for the Phytium D2000, there's no good DT, so we have kernel hacks to glue to ACPI.
<DC-IRC> <rpardini> For the x13s, it's grub `devicetree` -- not many overlays apply to a sealed laptop.
<DC-IRC> <rpardini> I've experimented with merged DTB and the same grub `devicetree` for a few SBCs.
<DC-IRC> <rpardini> but not shipping any of that yet.
<DC-IRC> <rpardini> so yeah in the end I'm just speculating and trying to form a one-size-fits-all semi solution proposal for near future.
<DC-IRC> <rpardini> (the rpi situation is still a headscratcher, it seems loading u-boot/edk2 from rpi's bootloader might be an option, instead of trying to wrangle that config.txt mess)
<DC-IRC> <rpardini> I wonder how Manjaro / Fedora handle this stuff, if at all....
<DC-IRC> <mariob> The main concern here is supporting multiple boards with the same ISO.
<DC-IRC> <mariob> Like, you could have an ISO for every board with patched dtb and grub devicetree, but kinda defeats the purpose of using edk2 in the first place
<DC-IRC> <rpardini> Well _yes_ if we could have generic images per-SoC, and autoselect the DTB like AF has done for his live ISO, it would be cool.
<DC-IRC> <mariob> Yeah, that's what i'm basically trying to do. But remove the need for grub `devicetree` and also handle overlays somehow
<DC-IRC> <mariob> Overlays are user-choice pretty much, they can specify those in a config file or by placing them on a board directory. Haven't decided yet.
<DC-IRC> <mariob> like
<DC-IRC> <mariob> `rock-5b\dtb\rk3588-rock-5b.dtb`
<DC-IRC> <mariob> `rock-5b\overlays\overlay1.dtbo`
<DC-IRC> <mariob> `rock-5b\overlays\overlay2.dtbo`
<DC-IRC> <mariob> and the firmware will apply all of the overlays in that board directory
<DC-IRC> <mariob> or have a config.txt file with sections for each board:
<DC-IRC> <mariob> ```
<DC-IRC> <mariob> [rock-5b]
<DC-IRC> <mariob> dtb=\dtbs\rk3588-rock-5b.dtb
<DC-IRC> <mariob> dtoverlay=\dtbs\overlay\overlay1.dtbo
<DC-IRC> <mariob> dtoverlay=\dtbs\overlay\overlay2.dtbo
<DC-IRC> <mariob> ```
<DC-IRC> <rpardini> Oh ok cool. That would enable a bunch of not-only-Armbian scenarios.
<DC-IRC> <mariob> Yeah, but sadly this isn't standardized so it would only apply to rk3588.
<DC-IRC> <rpardini> Fact you can have a single edk2 for multiple 3588 boards sounds like magic already.
<DC-IRC> <mariob> there's a firmware image for each board (meant to be flashed to spi nor), but that enables you to boot any ISO in a platform-agnostic way
<DC-IRC> <mariob> so from Armbian's perspective you wouldn't need to care about the board at all
<DC-IRC> <mariob> there's a firmware image for each board (ideally flashed to spi nor), but that enables you to boot any ISO in a platform-agnostic way
<DC-IRC> <rpardini> Oh, but somehow the board-specific image has to be flashed to spi-nor? ...
<DC-IRC> <mariob> yeah, well that can be flashed to either spi nor, emmc or sd card
<DC-IRC> <mariob> it is intended to be on a separate storage so that you don't have to worry about it
<DC-IRC> <mariob> but since that's not always possible, it can be flashed to emmc and sd too
<DC-IRC> <rpardini> clear. but how does AF's "Live ISO" works then?...
<DC-IRC> <rpardini> I thought it carried a generic-enough edk2
<DC-IRC> <mariob> no, the user is expected to have edk2 installed somewhere
<DC-IRC> <rpardini> oh! so no magic.
<DC-IRC> <rpardini> sorry I should have _tried_ the stuff beforehand 😉
<DC-IRC> <mariob> right now AF's live-iso reads the dtb filename hardcoded in SMBIOS and loads it from `\live\dtb` directory using grub `devicetree`
<DC-IRC> <mariob> but i wanna eliminate the need for that and also support overlays
<DC-IRC> <mariob> so you could just boot a standard ISO with rk3588 kernel
<DC-IRC> <mariob> without having to care about the DTB
<DC-IRC> <rpardini> Clear, so I'd need a board-specific edk2 either in eMMC or SPI, and then you can boot his iso from SD/USB/NVMe/whatever
<DC-IRC> <mariob> without having to care about the DTB, but, if needed, can also be overridden by ESP
<DC-IRC> <mariob> yep
<DC-IRC> <mariob> you can have everything on the same sd/emmc too
<DC-IRC> <mariob> like u-boot
<DC-IRC> <rpardini> clear. in that sense, Fedora-ARM has a "image builder" which takes a generic uefi image and mashes it with the board-specific u-boot.
<DC-IRC> <mariob> so you could just boot a standard UEFI ISO with rk3588 kernel
<DC-IRC> <rpardini> Armbian's instead producing terabytes of mostly-identical images with only u-boot differences in practice.
<DC-IRC> <mariob> So it's similar, to fedora, isn't it?
<DC-IRC> <mariob> Since they need a u-boot specific for the board anyway.
<DC-IRC> <rpardini> Yeah in the end is a storage/bandwidth vs user-convenience tradeoff.
<DC-IRC> <rpardini> Most/many beggining users are on Windows and BalenaEtcher, even the Fedora-ARM masher stuff is out of reach.
<DC-IRC> <rpardini> We could do a super-minimal Armbian image variant whose sole purpose is to deploy u-boot/edk2 to SPI/eMMC, but still, would be N images for N boards, if smaller.
<DC-IRC> <mariob> yeah, the assumption with an UEFI image is that the board already provides that
<DC-IRC> <mariob> or it's been previously installed by the user
<DC-IRC> <rpardini> Yeah in this light... being overlay-capable (loaded from ESP) seems very sane. It would enable a bunch of use cases.
<DC-IRC> <rpardini> btw I've not an SPI-enabled 3588, but this OPi3b has 128mbit NOR. Can I just omit the 16mb "env" partitition and write it there? 😄
<DC-IRC> <rpardini> (jaredmcneill's `.img` is 32mb)
<DC-IRC> <mariob> not quite sure what it uses that partition for
<DC-IRC> <mariob> you could try
<DC-IRC> <mariob> it's probably related to the var store, but the rk356x uefi does not support SPI r/w
<DC-IRC> <mariob> so you could load uefi off it, but you won't be able to save any setup options
<DC-IRC> <mariob> like boot order
<DC-IRC> <rpardini> yeah I thought the same. I will try and report back.
<DC-IRC> <rpardini> All in all: thanks for the great work on edk2, on both 88 and 6x.
<DC-IRC> <mariob> sure, let me know how it goes
<DC-IRC> <amazingfate> 32mb is too big, that's for SD card only.
<DC-IRC> <amazingfate> I built a 16MB image before for my rock3a.
<DC-IRC> <rpardini> It looks to me like idbloader + uboot proper, if I use your partition layout (BOOT_SPI_RKSPI_LOADER) it should work shouldn't it.
<DC-IRC> <amazingfate> It should work.
belveder79 has quit [Ping timeout: 260 seconds]
<DC-IRC> <schuppeste_98085> i attempt to use edk2 on fedora images.. but cant get it work
<DC-IRC> <schuppeste_98085> edk2 works, but not the readyToGo Fedora Images