<ccf>
marex: only puts() get displayed, using printf does not show anything at all.
ccf has quit [Ping timeout: 264 seconds]
apritzel_ has quit [Ping timeout: 246 seconds]
<marex>
sjg1: events are not inlined by the compiler
<marex>
sjg1: I dont need more bloat
thopiekar has quit [Ping timeout: 255 seconds]
thopiekar has joined #u-boot
<sjg1>
marex: Well I can't help with that as there is NSTAAFL. But in a trade-off between invisible and 12 bytes smaller... that might matter with SPL, but here we are talking about U-Boot proper. How much do events really cost?
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
<marex>
ccf: could it be the other printf is not even called ?
<ccf>
I have no clue
<marex>
if one of the printf outputs is printed , so should be the others , assuming they get called and something very wrong doesnt happen
<marex>
probably spam the function with printfs and figure out where it fails
mmu_man has quit [Ping timeout: 246 seconds]
torez has joined #u-boot
<ccf>
already done that, only the first print is shown and when it comes to %p for blob it shows nothing. It seems the spl_relocate_stack_gd() is the first printf. Disabling CONFIG_SPL_SYS_MALLOC_SIMPLE then printf() works again but no fdt-loading but going back to BOOTROM...
<ccf>
CONFIG_SPL_STACK_R that is what I disabled, not CONFIG_SPL_SYS_MALLOC_SIMPLE
mmu_man has joined #u-boot
goliath has joined #u-boot
apritzel_ has quit [Ping timeout: 246 seconds]
<marex>
ccf: could you be hitting SPL size limits ?
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<ccf>
wouldn't be there an error message? I just used the rock-pi-4-rk3399_defconfig so nothing fancy
<ccf>
In some minutes I can test it on a realy rock-pi-4, not a custom one.
<ccf>
At least that what's amazon telling me
persmule has quit [Ping timeout: 255 seconds]
persmule has joined #u-boot
stefanro has quit [Quit: Leaving.]
apritzel_ has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #u-boot
<marex>
ccf: I am not familiar with rockchip
<marex>
ccf: try and ask qschulz
<marex>
ccf: in general, if the SPL is over limit in some obscure way, you may see very odd errors
BobBeck has joined #u-boot
MWelchUK4 has joined #u-boot
<ccf>
marex: Thanks, I now have a rockpi4 here to compare and it just boots into u-boot fine. So the issue seems to be on the custom board config somewhere, ... mhm
<marex>
ccf: gee, uh, is the DT even pasted at the end of the SPL blob ?
<marex>
is the SPL blob comparably large ? ls -la or aarch...size
<ccf>
I'm using the same dt for rockpi4 and the customrk3399-board here, it is not even booting into TF-A or SPL, only TPL gets the RAM initialized - at least it seems so (as pasted yesterday). But maybe it (the RAM) did not fully train... mhm
<ccf>
Is there a RAM check in TPL after sd_ram3399 initialization? or something to check?
<ccf>
I'm even using the same u-boot-rockchip.img just to test how far I can get (both hw have 2g RAM)
<marex>
ccf: there is cmd/mtest.c , you could pull it into SPL
<marex>
I think the test can be easily copied-pasted somewhere after SPL initied RAM (I did this a few times) and you'd see whether DRAM works then
<marex>
but you can also do a simple test, write the RAM and read back using writel() / readl() , if the DRAM is completely dead , you'd see that
apritzel_ has quit [Ping timeout: 246 seconds]
<ccf>
marex: Thanks, I'll try.
LordKalma has quit [Quit: Server has probably crashed]
<marex>
ccf: one more thing, isn;t the SPL DT just too big ?
<marex>
compare that, ls -la spl/*dtb
zPlus has joined #u-boot
<zPlus>
I've noticed that there's a "bootefi hello" command that loads the "helloworld" program. I'm curious, what would be the difference between using uboot's efi_api.h, and using something else instead like gnu-efi?
<marex>
xypron: ^
<xypron>
zPlus: With gnu-efi you can build an EFI binary. With U-Boot's bootefi command you can launch that binary. U-Boot will provide the EFI API that your EFI binary will consume.
<xypron>
helloworld.efi is an example EFI program.
<xypron>
It can be baked into U-Boot.
<xypron>
Normally you would load EFI binaries with the load command.
<ccf>
marex: It's 11k
<marex>
ccf: both of them ?
<marex>
ccf: the rock board and the custom board ?
<marex>
i.e. are they roughly the same size ?
prabhakarlad has joined #u-boot
<ccf>
marex: I use the same binary image for both boards because they are nearly identical.
<ccf>
I use the same u-boot-rockchip.img on both boards
<zPlus>
sorry xypron I'm new to efi and I'm struggling a little bit to understand. Right now I'm building my program with gnu-efi, then I "load" and "bootefi" it. What I don't understand, is if I can remove gnu-efi entirely from my program and replace it with uboot's efi_api.h, and then "load" and "bootefi" it
<zPlus>
I guess what I'm trying to understand is if efi_api.h is can replace gnu-efi
<zPlus>
or if they are two different things entirely
matthias_bgg has quit [Quit: Leaving]
<xypron>
zPlus: gnu-efi is not needed to build EFI binaries. What needs to be done is packaging your code using the PE-COFF format (https://learn.microsoft.com/en-us/windows/win32/debug/pe-format). Essential parts are the header crt0-efi*.S for the PE-COFF header, and a linker script elf_*_elf.lds. efi_api.h only describes the EFI API. You could write your own headers based on what is written in the UEFI specifiation.
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<zPlus>
xypron: so if I understand correctly, uboot's helloworld is compiled to elf and then somewhere during compilation it's "converted" to PE? In other words it's the same thing that gnu-efi does?
apritzel_ has joined #u-boot
<xypron>
zPlus: the Makefile snippet for efi binaries can be found here: scripts/Makefile.lib:425:$(obj)/%.efi: $(obj)/%_efi.so
marc1 has quit [Quit: WeeChat 3.6]
<zPlus>
xypron: looking at the makefiles, it seems to me that both gnuefi and uboot do the same thing. They compile a shared object and then build the efi binary from it.
<ccf>
marex: Got it, writel() and then readl() from (CONFIG_SPL_STACK_R_ADDR - 0x10000) does not work on the custom board, ...
<xypron>
zPlus: gnu-efi addtionally provides library functions encapsulating EFI API calls. Without gnu-efi you have to call the EFI API directly.
goliath has quit [Quit: SIGSEGV]
<zPlus>
xypron: what's the advantage of encapsulating efi api calls? Like, does it make using efi easier or are there other reasons?
<xypron>
zPlus: Look for instance at gnu-efi's Print(). It works like printf(). The EFI API only supports writing strings.
<zPlus>
I see
<zPlus>
well, thank you a lot for the help xypron
marc1 has joined #u-boot
<zPlus>
is there a command for launching a efi app directly from filesystem instead of load-ing and bootefi-ing it? For example "boot virtio 0:1 hello.efi" instead of loading the binary to memory and then "boot" it?
apritzel_ has quit [Ping timeout: 248 seconds]
<marex>
ccf: yeah, so likely DRAM issues
<xypron>
zPlus: You can define a variable with a macro and use the 'run' command to execute it. The dhcp command can load a binary encapsulated as a FIT image from a TFTP server and directly execute it.
<ccf>
marex: Yes, I think so too. So now I want to use rockchip its rk3399_ddr_800MHz_v1.27.bin, how to integrate this with binman instead of u-boot-tpl?
<ccf>
marex: I just hacked it into the dts binman in rockchip-u-boot.dtsi, it now boots!!!
<ccf>
So the routine in drivers/ram/rockchip/sdram_rk3399.c does not seem to work for this custom-board its DRAM population, ... *sigh*