memset has quit [Remote host closed the connection]
memset has joined #u-boot
vagrantc has quit [Quit: leaving]
memset has quit [Remote host closed the connection]
memset has joined #u-boot
jclsn has quit [Ping timeout: 273 seconds]
jclsn has joined #u-boot
qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #u-boot
mmu_man has quit [Ping timeout: 262 seconds]
agris has joined #u-boot
<agris>
Hello? Is anybody here?
<agris>
does "SPL/TPL" refer to the same thing? If I'm able to build a BL31.elf from trusted-firmware-a.git does that mean I don't need a SPL or a TPL?
<agris>
otherwise I have this
<agris>
rk3588_spl_loader_v1.19.113.bin
<agris>
bl31_0x00040000.bin
<agris>
bl31_0x00040000.bin.digest
<agris>
bl31_0x00040000.bin.gz
<agris>
bl31_0x000f0000.bin
<agris>
bl31_0xff100000.bin
<agris>
bl31.elf
<agris>
these blobs from the manufacturer
<agris>
I'm trying to build my own u-boot because when I try to load freebsd's aarch64.efi bootloader it crashes u-boot so hard I need to press the reset button
<agris>
the manufacturer is using a strange fork of u-boot from 2017
<agris>
they sdk they gave me just has this tarball with a fork of linux and u-boot, and the tarball doesn't even have all the changes committed just one staged relating to a display
tlwoerner_ has quit [Quit: Leaving]
tlwoerner has joined #u-boot
<agris>
I need help
<shadow>
hi agris
<shadow>
TPL is "yet another SPL, after SPL"
<shadow>
it needed a name so arbitrarily it is "TPL"
<shadow>
SPL itself is usually operating before DRAM is initialized
<shadow>
if all source code was known then it is usually just MaskROM to U-Boot main app, if MaskROM does the DRAM initialization; or there is a minimal filtered build of U-Boot with few options for constrained on-die memory operation (SRAM?) and this is known as SPL, and then maybe there's some kind of supervisor sandwiched in there before U-Boot main app too
<shadow>
when DRAM is initialized then U-Boot main app is loaded and code execution jumps there
<agris>
How would I be able to tell?
<agris>
# LBA start (sectors) LBA end (sectors) Size (bytes) Name
<agris>
00 8192 16383 4194304 security
<agris>
01 16384 24575 4194304 uboot
<agris>
03 32768 40959 4194304 misc
<agris>
02 24576 32767 4194304 trust
<agris>
04 40960 49151 4194304 dtbo
<agris>
and what does BL31.elf do, is it needed?
<agris>
the devkit BL31.elf blob is twice as big as the one I built from cloning trusted-firmware-a.git
<agris>
i also managed to find the dts/dtsi files from their custom version of linux
<agris>
but
<agris>
their custom version of u-boot just uses rk3588-evb, i'm not sure if it's modified or not
<shadow>
typically vendors will copy paste some other contractor's work getting the eval board going, then splash their changes over it without any regard for the future
<agris>
the linux distro (debian 12) appears to be from linaro
<agris>
at least the default user (uid1000) is
<agris>
it's weird though. It doesn't boot like a normal linux. It uses some kind of android booting fit image with a built in dtb
<shadow>
the first move would be to upstream this (if it is not yet) to Linux Kernel, as that is the authoritative center for devicetree
<agris>
thankfully i do have the source
<shadow>
then u-boot, then *bsd
<agris>
what does that entail? submitting the dts/dtsi files to kernel.org?
<shadow>
if you just want to tweak the existing vendor u-boot I would like to be helpful but it is going to be diminishing return on time invested in it
<shadow>
upstream is the way to go
<agris>
I want to eventually get generic linux kernel booting a normal way, instead of this weird custom androidboot fit image
<agris>
as far as I can tell support for the rk3588 is good in linux7
<agris>
I just need to figure out how to get a normal non-hackjob u-boot running that can load efi without crashing
<agris>
I'm new to arm stuff, trying to get away from the x86 monopoly and be able to run a computer in my car for more then a couple minutes before running the battery down ;)
<shadow>
presumably you could identify which existing upstream dts is most similar to your device's hardware
<agris>
I already have the device tree source
<shadow>
dts changes over time
<agris>
ah
<shadow>
as drivers are updated or re-written, their option names change, also bugs are fixed in how things inter-relate
<agris>
so I wouldn't be able to use these dts files?
<shadow>
you could on u-boot circa 2017
<shadow>
they're more of a reading reference, especially when the schematic is not available
<agris>
just the compatibility definition telling the kernel which driver to load?
<agris>
I have the schematics for this board
<shadow>
look up circa 2017 the linux kernel driver that consumes the configuration written in that dts, then read through the code to figure out what registers it readl and writel, read the chip documentation for that peripheral to understand the registers, then read the latest Linux kernel driver applicable to write your new dts
<shadow>
schematics are good, that's helpful. You should be able to read through the dts in that above git tree subdirectory identifying what is most closely resembling your board
<shadow>
perhaps start with rk3588-evb1-v10.dts and rk3588-evb2-v10.dts to see if it has any similarity at all
<agris>
so I would not be able to build a current version of u-boot for this board yet?
<shadow>
likely the compatible names have changed since then in mainline Linux, and U-Boot has sync'd with some of that in the last decade
<agris>
so to be clear, the path forward is use the vendor's 2017 fork of u-boot but add efiloading support so I can attempt to boot a mainline kernel, play with modernizing the dts files to work with modern linux and upstream that, then work on the same for bsd?
<agris>
Shouldn't I at least be able to load the FreeBSD bootloader without u-boot crashing?
<shadow>
yeah. U-Boot has a subtree that references devicetree-rebasing which is built from every tagged release of mainline Linux (including release candidates)
<agris>
I haven't tested it yet, but when I built u-boot with bootefi support and uploaded it to this board, as soon as i used the bootefi command u-boot would crash
<agris>
I'm not sure if building a linux efistub would crash too
<agris>
but I feel like linux is a lot more complex and requires more then the freebsd loader
<shadow>
so... upstream to Linux, then U-Boot conveniently has all those changes when they're published, and poke a few levers and config options with some driver glue and it should be working
<agris>
is there a wiki server I could use to document my findings and hopefully collaborate with others?
<shadow>
openwrt community might have something applicable
<agris>
what should I do if u-boot 2017 crashes loading linux too?
<agris>
thing is, I want to use a modern linux because there's been a ton of work on open source drivers since then for linux 6.18-linux7.x whereas this vendor's version is using a ton of blobs and weird extremely alpha quality drivers
<shadow>
my advice will be rather generic, based on experiences loosely around RISC-V developer boards; there are some rk3588 experts that frequent this IRC channel (it may take a week or two, everyone is busy)
<agris>
running a mainline circa 2017 linux kernel would not work
<agris>
because support wasn't there at that time
<agris>
I figured updating u-boot would stop it from crashing when using bootefi
gsz has joined #u-boot
<mps>
SPL - secondary program loader, TPL - tertiary program loader