Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
sng_ has quit [Remote host closed the connection]
sng_ has joined #u-boot
sng_ has quit [Remote host closed the connection]
sng_ has joined #u-boot
sng_ has quit [Remote host closed the connection]
sng_ has joined #u-boot
camus has quit [Ping timeout: 252 seconds]
camus has joined #u-boot
mripard has joined #u-boot
frieder has quit [Ping timeout: 255 seconds]
mmu_man has quit [Ping timeout: 245 seconds]
frieder has joined #u-boot
<deathmist>
mps: I think you were doing VF2 NVMe boot drive, may I ask how that's setup? it looks like I'd have to mess with U-Boot on SPI especially if I want to boot without any other storage attached
<deathmist>
(and still have properly working extlinux that is so kernel upgrades are seamless etc)
<mps>
deathmist: I do it manually, i.e. from u-boot prompt set some env variables and then run 'boot' cmd
<deathmist>
hm I was fearing that. apparently up-to-date downstream U-Boot can do it directly from NVMe these days but I've not looked much into it and it may require uEnv.txt
<mps>
don't have enough free time to add patces to the board in u-boot and don't want to change default env config in the flash
<mps>
deathmist: no, even vendor/starfive u-boot need manual boot
<mps>
ofc, this could be changed by setting proper variables and save to flash
<mps>
I intended to add some tweaks for VF2 board and post patches to u-boot ML but I think it is too late for next stable release
<mps>
(thought I will have more free time for open/free source when becoming older but looks like it is opposite)
<deathmist>
I should've sent my mainline DTB selection thing when I figured it out but meh, it's the only extra patch remaining now on my package relevant to booting the board
<deathmist>
I don't particularly enjoy dealing with mailing lists
<mps>
ML and IRC is my preferred workflow, I don't like web
<mps>
s/is/are/
frieder_ has joined #u-boot
frieder has quit [Ping timeout: 245 seconds]
vagrantc has quit [Quit: leaving]
sng_ has quit [Remote host closed the connection]
gmcastil has joined #u-boot
frieder_ has quit [Ping timeout: 252 seconds]
frieder_ has joined #u-boot
rockosov has quit [Quit: WeeChat 3.4-dev]
sng_ has joined #u-boot
frieder_ has quit [Ping timeout: 255 seconds]
frieder_ has joined #u-boot
frieder_ has quit [Ping timeout: 255 seconds]
<bswartz>
mps: Welcome to the early 90s! You might like to try gopher
<dormito>
Hmmm. I have a lx2162a system, and a emmc chip plugged into an emmc->SDmicro adaptor in an sdcard slot. I have noticed that u-boot failes to configure the emmc chip... but if I "#define DEBUG 1" in drivers/mmc/mmc.c, it IS able to detect the chip. Is there a timing/timeout setting for mmc/sdcard detection?
<mps>
bswartz: oh, thanks for reminder. My first internet browser was gopher
<mps>
deathmist: git-send-email is useful thing
<deathmist>
I always mess up something when I have to use email based patch workflow, we'll see in a bit I guess..
sng_ has quit [Quit: Leaving...]
sng_ has joined #u-boot
sng_ has quit [Remote host closed the connection]
sng_ has joined #u-boot
sng_ has quit [Client Quit]
frieder_ has quit [Remote host closed the connection]
<sjg1>
Tartarus: Move fdt_support to boot/ - seems to be something to do with the file moving and being linked as part of a different lib, but I couldn't figure out what
<sjg1>
Tartarus: For ' spl: Drop SPL/TPL_RAM_SUPPORT option for SPL_LOAD_FIT_ADDRESS': It does change Kconfigs (although not size), so I believe this is actually correct
<sjg1>
Tartarus: Re the buildman patch, perhaps I could add it as another flag, like --more-reproducible ?
<lvrp16>
I'm trying to go through the code and there's fdtaddr fdt_addr fdt_addr_r. Is there a page that describes the differences or is it just legacy variables?
<lvrp16>
sjg1: this is also an area where bootstd deviates from the previous behavior
<sjg1>
lvrp16: can you share a little more detail, or a patch?
<lvrp16>
Tartarus: if you can provide some guidance for the variables, if they serve different purposes, or if they should be cleaned up and unified, please let me know. Maybe we can start sending patches to unify them or not.
<lvrp16>
sjg1: for the previous distro_bootcmd, the running commands will pass the fdt_addr_r env to bootefi. since we did away with distro_bootcmd, bootefi just reads fdt_addr. this causes all the boot scripts that rely on fdt_addr_r (meson, rockchip, allwinner, etc) to not load the right dt.
<lvrp16>
also the pollution of different variables, perhaps for the same purpose, is making the code difficult to read.
<lvrp16>
fdtaddr/fdt_addr/fdt_addr_r
<Tartarus>
sjg1: file moves can change link stuff and so optimizations/etc, yeah, so it's sometimes best for testing to just drop that patch
<Tartarus>
but the non-tiny changes on #05 and 09 are worrying. Perhaps just don't move things first, and just focus on Kconfig reworking?
<Tartarus>
sjg1: No, just make a note like the other things that can change size and be things you just have to be confident in the change otherwise being correct
<Tartarus>
phy_interface_strings 22528 22784 +256
<Tartarus>
that's a worrying line
<Tartarus>
pico-nymph-imx7d: all +4 text +4
<Tartarus>
if you look in to the change itself and the platform, is not.
<Tartarus>
And yes, we have some legacy cases like "loadaddr" vs "load_addr" that really are the functional equiv
<Tartarus>
whereas fdt_addr (address that the fdt is at, might not be writable ie NOR flash) vs fdt_addr_r (fdt address, in memory so must be writable)
<lvrp16>
Tartarus: thanks for the explanation, makes sense!
goliath has quit [Quit: SIGSEGV]
powderhorn has quit [Quit: Client closed]
powderhorn has joined #u-boot
persmule has quit [Remote host closed the connection]