Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2023.10, v2024.01-rc3 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2024.01 is scheduled for 08 January 2024 / Channel archives at https://libera.irclog.whitequark.org/u-boot
vagrantc has quit [Quit: leaving]
swiftgeek has quit [Ping timeout: 256 seconds]
<Hammdist> hm. well I think the memory init is working now, but nothing happens (no serial port output for example) when I jump into u-boot.elf
<ukky> Hammdist: if you just need to initialize DDR memory before starting U-Boot, one option would be to compile Xilinx FSBL with your ps_init.c. FSBL should detect JTAG via boot mode register, initialize PS including DDR memory, then exit. And you load this FSBL via JTAG.
<Hammdist> ukky: I think the memory init is working now. with GDB I can now load u-boot.elf and examine its contents and it seems OK
<Hammdist> problem is when I jump to it using "j *0x4000000". when I breakpoint that address first I can single step with "si" and the PC advanced by 2 bytes only. must something be done to turn off thumb mode before jumping (I know too little about arm)
<ukky> I only use xsdb to work with my chip, ZynqMPUS+. Are you building 32- or 64-bit U-Boot?
<Hammdist> 32-bit. the zynq-7000's are all 32-bit
<Hammdist> (afaik)
<Hammdist> here you can see it going from address 4000000 to 4000002: https://paste.ee/p/2MLBK
<Hammdist> I should figure out how to enable the D/I caches
<Hammdist> but likely not the culprit of anything except slowness
<Hammdist> also when I disassemble in gdb I don't get the right disassembly code though I figured the machine would still execute correctly, but maybe somehow gdb is putting it in a wrong mode
<Hammdist> ah it just worked. the trick is to load the elf both with load and with 'file' as well then gdb knows what to do
<Hammdist> interestingly if I interrupt after u-boot has booted, the D/I caches still show as disabled
ikarso has quit [Quit: Connection closed for inactivity]
qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #u-boot
swiftgeek has joined #u-boot
<marex> Hammdist: did you pass DT to that U-Boot ?
<marex> Hammdist: if not, that could be the problem
mmu_man has quit [Remote host closed the connection]
mmu_man has joined #u-boot
<Hammdist> marex: ah ok. just getting back to this. indeed I did not pass a DT to u-boot (I'm just loading through gdb). will try with CONFIG_OF_EMBED=y
zsoltiv_ has quit [Ping timeout: 256 seconds]
zsoltiv_ has joined #u-boot
jclsn has quit [Ping timeout: 255 seconds]
jclsn has joined #u-boot
<Hammdist> ok I have a DT for sure now and it shows the board name and everything but still no caching
LeSpocky has quit [Ping timeout: 268 seconds]
LeSpocky has joined #u-boot
<Hammdist> this may be normal: https://support.xilinx.com/s/article/59473?language=en_US one apparently cannot enable the data caches without enabling the MMU. u-boot similarly does not enable the MMU as far as I can tell
<Hammdist> maybe the gdb stub disables the mmu while the jtag is active or something
zsoltiv_ has quit [Ping timeout: 264 seconds]
<Hammdist> ok so bootelf is not suitable for my purposes (no SMP possible). is there a way to turn an elf into a uImage?
qqq has joined #u-boot
Clamor has joined #u-boot
Clamor has quit [Ping timeout: 245 seconds]
Clamor has joined #u-boot
ikarso has joined #u-boot
<Hammdist> I have got working with bootm with FIT image. the trick is to convert elf to bin first then put it in FIT. if left as ELF, the ELF file format itself will be loaded without interpretation of program headers and things won't work
monstr has joined #u-boot
Clamor has quit [Ping timeout: 246 seconds]
Clamor has joined #u-boot
stefanro has joined #u-boot
Clamor has quit [Ping timeout: 255 seconds]
Clamor has joined #u-boot
Clamor has quit [Ping timeout: 245 seconds]
Clamor has joined #u-boot
goliath has joined #u-boot
frieder has joined #u-boot
jmasson has joined #u-boot
Hammdist has quit [Ping timeout: 250 seconds]
sszy has joined #u-boot
<apalos> /q mwalle
<apalos> oops
ezulian has joined #u-boot
jaganteki has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
jmasson has quit [Ping timeout: 246 seconds]
slobodan has joined #u-boot
jaganteki has quit [Quit: Client closed]
norton has joined #u-boot
dsimic has quit [Ping timeout: 256 seconds]
dsimic has joined #u-boot
jmasson has joined #u-boot
prabhakarlad has joined #u-boot
Stat_headcrabed has joined #u-boot
Stat_headcrabed has quit [Quit: Stat_headcrabed]
rvalue has quit [Read error: Connection reset by peer]
Hammdist has joined #u-boot
rvalue has joined #u-boot
Clamor has quit [Ping timeout: 245 seconds]
Clamor has joined #u-boot
Clamor has quit [Ping timeout: 264 seconds]
Clamor has joined #u-boot
Clamor has quit [Ping timeout: 245 seconds]
Clamor has joined #u-boot
stefanro has quit [Quit: Leaving.]
<mkorpershoek> Tartarus: I see that https://patchwork.ozlabs.org/project/uboot/patch/20231215041919.2197788-9-sjg@chromium.org/ is delegated to you even if there are fastboot patches. I assume you will take the whole series through your tree? If my assumptions are wrong and I should pick up the fastboot patches from that series, let me know.
<mkorpershoek> (i'm happy both ways)
qqq has quit [Remote host closed the connection]
mmu_man has quit [Quit: Lost terminal]
Stat_headcrabed has joined #u-boot
thopiekar has quit [Ping timeout: 260 seconds]
thopiekar has joined #u-boot
Stat_headcrabed has quit [Quit: Stat_headcrabed]
torez has joined #u-boot
vagrantc has joined #u-boot
GNUtoo_ has quit [Ping timeout: 240 seconds]
thopiekar has quit [Read error: Connection reset by peer]
GNUtoo has joined #u-boot
thopiekar has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
Hammdist has quit [Quit: Client closed]
ldevulder has quit [Ping timeout: 256 seconds]
gsz has joined #u-boot
Hammdist has joined #u-boot
slobodan has quit [Ping timeout: 245 seconds]
monstr has quit [Remote host closed the connection]
ldevulder has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
sakman has quit [Ping timeout: 276 seconds]
<Tartarus> mkorpershoek: yes, I'd take the whole series since you ack'd the patches. For a project the size of u-boot, I think that makes more sense than having the strict sub-tree breakdowns that the linux kernel tends towards mandating
sakman has joined #u-boot
jmasson has quit [Ping timeout: 276 seconds]
<mkorpershoek> Yep! I agree. Just wanted to make sure I'm not doing anything wrong :)
jmasson has joined #u-boot
jmasson has quit [Ping timeout: 260 seconds]
<Tartarus> sjg1: Can you point to the thread about trying to get SMBIOS without EFI in the kernel?
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Hammdist has quit [Quit: Client closed]
jmasson has joined #u-boot
slobodan has joined #u-boot
vagrantc has quit [Quit: leaving]
gsz has quit [Ping timeout: 245 seconds]
Clamor has quit [Ping timeout: 260 seconds]
vfazio_ has joined #u-boot
vfazio has quit [Ping timeout: 268 seconds]
vfazio_ has quit [Ping timeout: 260 seconds]
vfazio has joined #u-boot
vagrantc has joined #u-boot
Hammdist has joined #u-boot
<xypron> Tartarus: I guess sjg1 had that SMBIOS3 patch set which needs to be fixed and rebased.
torez has quit [Quit: torez]
prabhakarlad has joined #u-boot
<xypron> sjg1: qemu-riscv64_smode_defconfig without PREBOOT crashes because the devicetree is not found. Why should we need PREBOOT to find a device-tree from QEMU?
<xypron> This should be hard coded and not preboot.
<xypron> Automatically booting via EFI fails on qemu-riscv64_smode_defconfig. It seems there is havoc.
<Tartarus> Er, hm
jmasson has quit [Ping timeout: 255 seconds]
<Tartarus> xypron: Is something "funny" going on with riscv? I see PREBOOT is just settting fdt_addr to fdtcontroladdr
<Tartarus> Which should be the fallback used when booting the kernel anyhow
<xypron> Tartarus: if I remove it I get a crash
<Tartarus> Yes, but that sounds like a riscv problem
<Tartarus> We don't do that on qemu-arm*, yes?
<Tartarus> And I know in general when we EFI boot on arm, if there's no fdt set, fdtcontroladdr is what's used for the OS
<Tartarus> xypron: sifive is doing that too
<Tartarus> Which seems WRong
vagrantc has quit [Quit: leaving]
vagrantc has joined #u-boot
<xypron> Tartarus: A builtin script runs 'if fdt addr -q ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi'
<xypron> fdt_addr_r is not set
<Tartarus> Ah, so part of distro_bootcmd
ezulian has quit [Ping timeout: 240 seconds]
<Tartarus> But even then, er
<xypron> I will have to debug that script which leads to do_fdt crashing.
<Tartarus> Yes, if fdt_addr_r isn't set, then it still falls back to fdtcontroladdr
<Tartarus> You could just migrate to bootstd :)
<sjg1> Tartarus afk but the series is ffi acpi or something like that
Hammdist has quit [Quit: Client closed]
<xypron> Tartarus: The problem is in do_fdt: "fdt addr -q $fdt_addr_r" does not check if 0x8c000000 is within the available RAM. This leads to a crash with 128 MiB RAM which is the default of QEMU.
yang has quit [Ping timeout: 252 seconds]
yang has joined #u-boot
<Tartarus> Ah, so fdt_addr_r is set wrong? And should be unset?
<Tartarus> Because I assume ram starts at 0 in that case
<Tartarus> er, oops
<Tartarus> But yeah, that means include/configs/qemu-riscv.h is wrong
<Tartarus> and someone should audit the rest of the riscv configs that're doing fdt addr $fdtcontroladdr in PREBOOT
norton has quit [Ping timeout: 256 seconds]
slobodan has quit [Ping timeout: 245 seconds]
vfazio has quit [Ping timeout: 256 seconds]
prabhakarlad has quit [Quit: Client closed]
<xypron> Tartarus: the address is wrong. We simply do no check in do_fdt() that the address passed is accessible. This may lead to a crash.
<Tartarus> xypron: Yes, we never do that kind of checking
<Tartarus> Pass an invalid address, get a crash