jfsimon has quit [Remote host closed the connection]
alexxy has quit [Ping timeout: 268 seconds]
dormito has quit [Ping timeout: 248 seconds]
sally_ has joined #u-boot
sally has quit [Ping timeout: 268 seconds]
alexxy has joined #u-boot
jfsimon has joined #u-boot
dormito has joined #u-boot
<sjg1>
Kwiboo: Tom has often suggested having a way to get a constant from the devicetree and build it into the image. We actually use OF_PLATDATA on the rockchip Chromebooks, but I notice that no other rockchip boards do. Is it just too much hassle?
<sjg1>
Kwiboo: We could probably do something less intrusive, like stuff a value into the Elf file. Binman already does this, so we would just need a mechanism to declare the symbols, binman_sym_declare() but for arbitrary things in the devicetree
<marex>
shadows: I was always pondering whether we could convert DT into a C structure and somehow link-time something convert it into constants
<marex>
sjg1: ^
<sjg1>
Kwiboo: Also, did that rockchip series go in in the end?
<marex>
sjg1: maybe not a structure, but a load of macros which would represent the resolved tree keys, set to resolved tree values
<marex>
that might be compile-time optimize-able
<sjg1>
marex: Yes, OF_PLATDATA does the first thing you said. Zephyr does the second; however the macro magic is distasteful
<shadows>
marex: you are talking about optimization, valid, also I am stuck on how to troubleshoot where the existing way doesn't work for this board target
<shadows>
to reduce the chance of it being some devicetree Fdt node that was stripped out for the SPL, can I easily ensure the whole devicetree gets lumped in to the SPL and not bother having to add bootph-pre-ram statements everywhere
<shadows>
at least for troubleshooting
<marex>
sjg1: but the compiler can likely optimize that better
<marex>
shadows: you can, but the SPL probably wont fit into the SRAM anymore, keep in mind the SRAM size is limited, so is the total SPL size because of it
<shadows>
256KB?
<marex>
shadows: look at DEBUG_UART (to get any output before DM_SERIAL UART driver kicks in) and possibly sprinkle printf() around the UART driver and clock driver to find out why clk_get/clk_get_rate() return -ve
<sjg1>
marex: Possibly, but now you are talking about space rather than time
<marex>
sjg1: care to elaborate ?
<shadows>
and "how" to avoid stripping and processing bootph-pre-ram stuff ? is there some CONFIG to set that will avoid the filtering
<sjg1>
marex: I mean, it likely won't boot any faster if a constant is read from a literal pool instead of read from a global. I assumed you were thinking that the compiler might optimise certain values to avoid needing a literal, which might space space
<marex>
shadows: mark all the relevant nodes and subnodes with bootph-all , that's the way to go
<marex>
sjg1: it takes a while to resolve a number, e.g. 42, from somewhere in the DT ... imagine the number would be a constant integer which is compiled into the code ... a) it could be optimized by the compiler and b) the DT parser might not even be necessary for some platforms
<marex>
the b) saves you a LOT of space in SPL
<marex>
the a) saves you boot time
<sjg1>
Yes indeed. My point was that we have that feature today (getting a value into the executable sort-of from the DT), so we could do some plumbing and use it
<shadows>
that's tedious entering bootph-all, doing it... but there's not some heavier handed way to just avoid filtering out this stuff?
Jones42 has joined #u-boot
<sjg1>
shadows: You can do something like change the quiet_cmd_fdtgrep rule to remove $(fdtgrep_props)
Jones42 has quit [Ping timeout: 252 seconds]
jybz has quit [Ping timeout: 252 seconds]
<shadows>
sjg1: aside, for OF_UPSTREAM board targets with multi fit dtb, um... the SPL here says the model is VisionFive2 1.3b ; so the selection has not happened which chooses the correct dtb, for the SPL ? a bit confused on that, should it be? or is there necessarily going to be a hard-coded selection of which of the dtb in the multi-dtb fit to use at SPL time
jybz has joined #u-boot
<shadows>
I'm testing on Pine64 Star64 which does its logic selection as part of that callback in boards/starfive/visionfive2/spl.c to select for the dtb matching of the Star64 at runtime... so that kind of answers my question in a way, there's chicken-and-egg problem there
<shadows>
unless I'm only inspecting one record and there's more in SPL dtb hang on lemme look at that
quinq has joined #u-boot
<sjg1>
shadows: I think I saw some patches on the mailing list about that, but xypron is the expert there
<shadows>
are we expecting that runtime dtb selection happens for the SPL before the DM serial code?
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #u-boot
vardhan has joined #u-boot
mmu_man has quit [Ping timeout: 272 seconds]
LeSpocky has quit [Ping timeout: 244 seconds]
LeSpocky has joined #u-boot
alpernebbi has quit [Ping timeout: 252 seconds]
alpernebbi has joined #u-boot
clamor has joined #u-boot
<shadows>
sjg1: thanks for the advice, was able to remove the filtering and get the whole fdt through to SPL. Still same issue but that removes one source of error while troubleshooting
enok has quit [Ping timeout: 276 seconds]
mtoy_ has joined #u-boot
mtoy has quit [Ping timeout: 276 seconds]
mwalle has quit [Quit: WeeChat 3.8]
clamor has quit [Ping timeout: 272 seconds]
clamor has joined #u-boot
Guest313 has joined #u-boot
monstr has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
goliath has joined #u-boot
mckoan|away is now known as mckoan
haritz has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
mwalle has joined #u-boot
warpme has joined #u-boot
Jones42 has joined #u-boot
ldevulder has joined #u-boot
sszy has joined #u-boot
Jones42 has quit [Ping timeout: 260 seconds]
Jones42 has joined #u-boot
monstr has joined #u-boot
<Guest313>
sjg1: i've tried to add the "9121737455c Add EFI handover support to bootm" function - Unfortunately i'm getting an exception when i try to load the image ("!!!! X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID - 00000000 !!!!"
frieder has joined #u-boot
Poltawer has joined #u-boot
mmu_man has joined #u-boot
<marex>
xypron: ^
<shadows>
down the code path `ret = uclass_get_device_by_ofnode(UCLASS_CLK, args->node, &dev_clk);` fails when called from SPL phase of ns16550.c but is success when from U-Boot Main phase; args_count=1 and args[0]=146 in both situations.
<marex>
that will dump current driver tree, what is bound and what is probed
<marex>
check the clock driver there
<shadows>
good hint, thanks, that's very helpful to have something to try... will do
<shadows>
marex: https://paste.debian.net/1372202/ scan through and look at position of "clk_get_by_index() = -19" the first time from SPL, the output of dm_dump_tree() where I have called it from ns16550.c, and then again when it is U-Boot Main where we see "clk_get_rate() = 24000000"
monstr has quit [Ping timeout: 252 seconds]
<shadows>
I see there's no uart0_core reference from the SPL phase... not sure all what that relates to code in U-Boot, very obviously it's different in the broad view of it
<shadows>
oscillator which has the 24MHz value from devicetree has no children in the dump at time of SPL
Jones42 has quit [Ping timeout: 252 seconds]
Jones42 has joined #u-boot
mmu_man has quit [Ping timeout: 248 seconds]
<Kwiboo>
shadows: looks like the jh7110_clk has not been probed or fails to probe and register all clocks prior to ns16550.c try to read the clock rate in the SPL dm tree dump, unsure what needs to be done to solve that
<Kwiboo>
marex: I was concerned that my recent change in ns16550.c to check clock-frequency prior to the rate from clk_get_rate() had caused a regression, but I think not, shadows issue is not related to that change ;-)
<shadows>
Kwiboo: checking clock-frequency prior to the rate from clk_get_rate() sounds like a correct strategy
<Kwiboo>
sjg1: ahh, I have avoided use of OF_PLATDATA because it requires modification to drivers to work properly and if I am not mistaken also does not handle e.g. reg translation properly (#address-cells <> 1 or #size-cells <> 1 or ranges)
<Kwiboo>
sjg1: the rockchip dt series did not make the first rockchip PR, I expect it will make it in a follow up PR from kever
<shadows>
is jh7110_clk not allowed to run before the debug uart at SPL ?
<shadows>
thinking what would disabling debug uart do
<shadows>
anything I can drop into there to make it more obvious when that is probed (or fails to probe), and perhaps something to force it to probe?
<shadows>
I think we're talking about "jh7110_pll_clk" right? from drivers/clk/starfive/clk-jh7110-pll.c
enok has joined #u-boot
<Kwiboo>
shadows: I think the none-pll driver is the one that needs to work/be probed correctly prior to get_clk_rate, and should typically happen dynamically when the code requested a UCLASS_CLK for the clk reference, the none-pll driver is the one that register the gate clk for uart0_core clock
mmu_man has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enok has quit [Ping timeout: 252 seconds]
<shadows>
I follow what you're saying, but then I go to try and find a none-pll in source... huh. I search a few different ways. Or is that a conversational reference?
<sjg1>
Kwiboo: It does handle simple translation, or at least it seems to work OK on rk3288. But really OF_PLATDATA is designed to make SPL smaller, not faster. I think the Binman idea is better for the problem of getting a peripheral address from the DT
<sjg1>
Kwiboo: Re the rockchip DT series, I'm looking forward to it being applied. For now, I've got the VBE stuff on hold
Hypfer67 has joined #u-boot
Hypfer6 has quit [Ping timeout: 276 seconds]
Hypfer67 is now known as Hypfer6
<sjg1>
Guest313: We don't have this flow in CI at present though
<Guest313>
sjg1: Thanks! I will try your u-boot tree
<Guest313>
sjg1: i'm also getting an Exception (!!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - 00000000 !!!!)
<Guest313>
sjg1: What i'm doing wrong?
ikarso has joined #u-boot
enok has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
cambrian_invader has quit [Ping timeout: 272 seconds]
KREYREN has quit [Ping timeout: 264 seconds]
<sjg1>
Guest313: I doubt it; more likely there is something wrong in there. Are you able to isolate where the crash happens?
cambrian_invader has joined #u-boot
<Guest313>
sjg1: It happens only if i apply the "Add EFI handover support to bootm" patch and occurs when executing "hf(priv->parent_image, priv->sys_table, params);"
<Guest313>
(efi_boot function / arch/x86/lib/bootm.c)
<Guest313>
sjg1: i've tried booting via fit image and directly via zboot
<Guest313>
sjg1: without the handover patch it is working but i can only use one core
<sjg1>
Tartarus: Yes I need to get rid of that printf(). I just need to find which series it was
<sjg1>
Guest313: OK, so I suppose your kernel has an EFI stub? You could dump the image that U-Boot is jumping to, to make sure it looks correct - see print_buffer()
<sjg1>
Tartarus: Will the meeting be starting 5 after the hour?
<Guest313>
sjg1: no it's a bzImage
<Guest313>
without an efi stub*
Poltawer has quit [Quit: WeeChat 4.6.1]
Guest313 has quit [Quit: Client closed]
<Tartarus>
Meeting time everyone
<Tartarus>
sjg1: So, yes, it is.
<Tartarus>
sjg1: And it was standalone, happily.
monstr has quit [Ping timeout: 252 seconds]
enok has quit [Ping timeout: 252 seconds]
sally has joined #u-boot
sally_ has quit [Ping timeout: 248 seconds]
<sjg1>
Tartarus: Ah yes I mean which branch
mmu_man has quit [Ping timeout: 252 seconds]
dsimic has quit [Ping timeout: 276 seconds]
dsimic has joined #u-boot
<Tartarus>
git reflog is your friend in that case :)
mmu_man has joined #u-boot
<sjg1>
Guest313: I'm not sure how that would work. For EFI a different handoff protocol is used, so it is likely that the registers are wrong. In any case, even if it did start, I'm not sure what it would do, since the setup block might not be found
frieder has quit [Remote host closed the connection]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mckoan is now known as mckoan|away
<marex>
Tartarus: did I miss it again ?
<Tartarus>
marex: yes
<marex>
hum
Guest313 has joined #u-boot
<Guest313>
sjg1: What is the standard procedure? Building the kernel as efi stub / creating an fit image with efi stub, setup and initrd section / boot it with u-boot bootm?
<apalos>
Guest313 what exactly are you trying to do ?
<apalos>
there's a bootefi command as well
<xypron>
Guest313: On a generic distro you would typically boot via EFI. In time constrained embedded scenarios you may want to boot via Linux legacy entry point.
<apalos>
Guest313: also zboot is just an internal Linux thing nowadays implemented in the stub,
<apalos>
So you can boot a compresssed kernel etc
<apalos>
Also there's 'eficonfig' which helps configure the image you want to boot from a ncurses-like gui
<apalos>
(and you can also configure the initrd & DTB you want with the kernel)
<sjg1>
Guest313: Yes, if U-Boot is booting an EFI app then it expects the kernel to be packaged as an EFI app, i.e. be built with the EFI stub. It sounds like we need to add some checking there, if that is possible, so it doesn't hang and gives a sensible error message
ldevulder has quit [Ping timeout: 260 seconds]
enok has joined #u-boot
Guest313 has quit [Quit: Client closed]
ungeskriptet has quit [Ping timeout: 248 seconds]
Guest313 has joined #u-boot
Poltawer has joined #u-boot
<Guest313>
apalos: I'm trying to use u-boot as unified bootloader for arm and x86. Currently i am working on the x86 part. The x86 devices could have intel atom / i3 / i5 / i7 cpus (for example the advantech mio series). All of them supporting uefi. For building the whole system i am using yocto. I made a few minor changes to u-boot to fit my use case (find
<Guest313>
env partition/root partition with gpt part uuid / etc.). I am building fit images (with kernel / setup / initramfs) and can boot them with u-boot without any problems. There is also a working A/B update system (including bootloader update). The current issue is the one core limitation, caused by an acpi problem i guess.
Jones42 has quit [Ping timeout: 252 seconds]
<apalos>
ok and is there a specific reason to use FIT?
<apalos>
You might as well use UKI if you want to bundle things together, which is support for all distros
<apalos>
supported on most distros*
<apalos>
Guest313: &&
<Guest313>
apalos: in a later step i want to use the secure-boot feature so i thought the fit image would be the better way.(?)
clamor has quit [Read error: Connection reset by peer]
enok has quit [Read error: Connection reset by peer]
enok has joined #u-boot
enok has quit [Read error: Connection reset by peer]
enok has joined #u-boot
enok has quit [Ping timeout: 260 seconds]
lehmanju has joined #u-boot
Poltawer has quit [Quit: WeeChat 4.6.1]
<sjg1>
Guest313: I'm going to bow out of this side of it and let you sort it out with Ilias. Secure boot normally means 'measured boot', i.e. that you will load and run anything, but the TPM may later tell you that something went wrong and you have to halt. Verified boot means that everything that gets loaded is verified before execution. They each have different goals
<sjg1>
Guest313: If you are wanting to boot the kernel using EFI protocols, then build it with CONFIG_EFI_STUB=y and you will have more luck