umbramalison has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
flyback is now known as canuck
canuck is now known as flyback
thopiekar_ has joined #u-boot
thopiekar has quit [Ping timeout: 268 seconds]
akaWolf has quit [Ping timeout: 252 seconds]
akaWolf has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
vagrantc has quit [Quit: leaving]
LeSpocky has quit [Ping timeout: 265 seconds]
LeSpocky has joined #u-boot
behanw has joined #u-boot
<hanetzer>
so, about extlinux.conf booting. a lot of linux distros plop the dtbs in /boot/dtbs/<vendor>/<dtb-files>; on arm, I could do fdtdir /boot/dtbs and that was fine; similar for aarch64 with that subdir setup?
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
crb_ has quit [Ping timeout: 268 seconds]
crb has joined #u-boot
crb_ has joined #u-boot
crb has quit [Ping timeout: 268 seconds]
crb_ has quit [Read error: Connection reset by peer]
crb has joined #u-boot
behanw has quit [Quit: Connection closed for inactivity]
sszy has joined #u-boot
mmu_man has joined #u-boot
persmule has quit [Ping timeout: 258 seconds]
monstr has joined #u-boot
mckoan|away is now known as mckoan
persmule has joined #u-boot
guillaume_g has joined #u-boot
cbmuser has joined #u-boot
ikarso has joined #u-boot
prabhakarlad has joined #u-boot
tre has joined #u-boot
<hanetzer>
seems like this is the case. so in other news, I've determined the bits to fiddle in the rk3399 dts to enable uart over the sdcard; problem is I still only can input via it, output still only goes out to vidconsole :P
<hanetzer>
ahhh I may have figured it.
flyback has quit [Ping timeout: 250 seconds]
flyback has joined #u-boot
sstiller has joined #u-boot
<milkylainen>
Hmm. I have a stm32mp1 based board without a u-boot env partition. It's fip based, where the u-boot is used as BL33. I don't understand how it can save env stuff and where it does it.
<milkylainen>
It shouldn't be in the fip. That is signed stuff.
<milkylainen>
Is there anything inside u-boot to tell me where the actual env storage is at?
<milkylainen>
I can't find it.
apritzel has joined #u-boot
<LeSpocky>
milkylainen: there should be, look out for ENV_IS_IN_* variables in Kconfig and/or include/configs
<milkylainen>
LeSpocky: Tnx. I just found it. It's beyond fugly.
<milkylainen>
st writes to the fip partition, at a hard offset.
<milkylainen>
partition is 0x80000 -> 0x480000. 4M. Configuration writes at mmc offset 0x280000, ignoring any data there.
<milkylainen>
Even if you had fixed the default configuration, it finds the fip or ssbl partition and tries to write in that area, hoping to not trash whatever is there.
<LeSpocky>
so it's CONFIG_ENV_IS_IN_MMC but not respecting partitioning of the actual mmc?
<milkylainen>
LeSpocky: It env handling, that fetches a env partition. That is declared as fip or ssbl. If that fails it goes for an offset. Like CONFIG_ENV_OFFSET=0x280000. So either way it lands in the default fip area when using their platform.
<LeSpocky>
board specific?
mmu_man has quit [Ping timeout: 248 seconds]
<milkylainen>
LeSpocky: Hmm. I don't think so. More like u-boot behavior. But not sure. Like declare your partition, if that fails it goes after an offset on mmc if that is available?
<LeSpocky>
sounds odd, I mean in U-Boot "menuconfig -> environment" I don't see any option to declare a partition
<LeSpocky>
well it's a mmc device number and partition number in CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART
<marex>
qschulz: hey, you around for a bit of puma gpio discussion ?
<qschulz>
marex: o/
<marex>
qschulz: lemme finish the email
<marex>
qschulz: but well, I don't get how the GPIO hog and boot mode select fit together
<qschulz>
marex: in short, we have a switch on the devkit which allows to cut the power and clock lines to the eMMC and put the SPI-NOR flash in HOLD mode (reset basically)
<qschulz>
marex: we then have a GPIO we can control with SW that allows to electrically override this switch on the devkit so that at runtime we can enable eMMC and SPI-NOR flash
<marex>
oh
<marex>
so like you flip some hardware switch , plug in SD card, power on => the board boots from SD card => in SPL you set this GPIO hog which inhibits the behavior of the hardware switch and continues booting from eMMC which is now connected again ?
<qschulz>
yes
<qschulz>
well, not exactly
<qschulz>
to be pedantic, I still want U-Boot proper to boot from SD card as first option (see same-as-spl in Device Tree)
<qschulz>
but if it's not available, allow to load it from eMMC or SPI-NOR flash
<qschulz>
I still want U-Boot proper to boot from SD card as first option *if U-Boot SPL was loaded from SD card*
<marex>
qschulz: ok, so in U-Boot SPL you want to implement board_boot_order() to do that part
<marex>
qschulz: i.e. separate topic I think
<qschulz>
marex: yup, rockchip already has one
<marex>
qschulz: but /wrt the gpio hog, dm_init_and_scan() should bring that up for you
<marex>
does it ?
<qschulz>
marex: all I can say is that without the patch I can load U-Boot proper from eMMC but not with the patch (when loading SPL from SD card)
guillaume_g has quit [Quit: Konversation terminated!]
<marex>
qschulz: can you check whether your DT contains u-boot,dm-pre-reloc for the GPIO controller and the hogs ?
<marex>
qschulz: that might be why the hogs are ignored
<marex>
also you likely need u-boot,dm-spl
<qschulz>
marex: it works without your patch, so yes, I do have u-boot,dm-pre-reloc for the GPIO controller otherwise it wouldn't have worked at all I'd have assumed
<marex>
qschulz: and the hogs too ?
<qschulz>
if the hogs are not working I cannot load U-Boot proper from eMMC, and I can, so yes :)
<marex>
qschulz: can you double-check that ? the gpio_hog_probe_all() does not check any flags, while dm_probe_devices() does check presence of DM_FLAG_PRE_RELOC
<qschulz>
marex: u-boot,dm-pre-reloc should be enough? I don't think I need u-boot,dm-spl?
<marex>
qschulz: actually ... add the following to the beginning of drivers/core/root.c dm_probe_devices()
<qschulz>
marex: gpio3 has the flag now but still no U-Boot proper loading from eMMC
<marex>
qschulz: could it be the line 375 above device_probe() call returns negative value ? can you check the return value of device_probe() above for the bios_disable_override device ?
apritzel has joined #u-boot
<marex>
qschulz: and maybe stick a printf() into drivers/gpio/gpio-uclass.c gpio_hog_probe() and enable the debug statements there, to see if that gets called and maybe fails ?
mmu_man has joined #u-boot
<qschulz>
marex: wait, line 375 is incorrect I believe
<LeSpocky>
milkylainen: okay after reconsidering, I guess partitions in DT and that env offset must be coordinated anyway
<qschulz>
that's why it does not probe, it never enters it
<qschulz>
because we have one mroe flag than DM_FLAG_PROBE_AFTER_BIND;
<marex>
qschulz: which flag ?
<qschulz>
marex: the == mask is incorrect I believe?
<qschulz>
0x40
<PaulePanter>
I registered at https://source.denx.de/users/sign_in yesterday and sent an email to the source admins, but my account has not been approved yet. Any idea, how long it’s going to take?
<qschulz>
marex: DM_FLAG_BOUND
<milkylainen>
LeSpocky: I'll poke the vendor about it.
<LeSpocky>
milkylainen: is it some defconfig in mainline u-boot?
<marex>
qschulz: well look at that ...
<milkylainen>
LeSpocky: my u-boot gets built with ENV_OFFSET and ENV_OFFSET_REDUND set to specific offsets.
<qschulz>
marex: all devices printed in drivers/core/root.c have this flag set
<marex>
qschulz: wait ...
<marex>
the check is (flags & mask) == mask
<marex>
so even if flags has DM_FLAG_BOUND set, it gets cleared in the flags & mask part
<marex>
(or do I really not see it?)
<qschulz>
marex: no no, i just misread, you're right
<qschulz>
however, it does not enter the if condition
<marex>
qschulz: can you print the $flags and $mask separately then ?
<LeSpocky>
milkylainen: that's okay if those offsets point to some "free" space not used otherwise
<qschulz>
marex: on it
<marex>
thanks
<hanetzer>
I get the feeling that my issue is somewhere in GRF_SOC_CON7:grf_uart_dbg_sel... its not documented in the TRM and u-boot only has GRF_UART_DBG_SEL_C listed. I'm trying to use uart2dbga
<milkylainen>
LeSpocky: It doesn't. And I prefer to have some type of logical formatting to prevent mishaps.
<milkylainen>
logical partitioning even.
<LeSpocky>
that would probably be nice
<qschulz>
marex: ah, I put the printf in the wrong location
<qschulz>
marex: the issue is that the mask is not only DM_FLAG_PROBE_AFTER_BIND
<qschulz>
it also has DM_FLAG_PRE_RELOC in it
<qschulz>
which none of the device actually have set
<milkylainen>
LeSpocky: Since I can't boot anymore. I conclude that u-boot just trashed my boot partition which happens to be at that offset.