<Forty-Bot>
do we care about sandbox fitting in a 32-bit address space?
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #u-boot
sakman has joined #u-boot
sakman has quit [Quit: Leaving]
sakman has joined #u-boot
urja has quit [Read error: Connection reset by peer]
urja has joined #u-boot
<dsimic>
diederik: (re: does the fdtdir *have* to be on the same partition as the boot partition) I'd suggest that you go through boot/pxe_utils.c in the U-Boot source code, searching for "ftddir" case-insensitively
<dsimic>
basically, the DT is read by U-Boot and passed to the kernel, so all you have available is the partition that's selected to be booted from
<dsimic>
also, perhaps it would be better to use FDT instead of FDTDIR, just to be on the safe(r) side, if the goal is to have the generic image customized for each board/device
goliath has joined #u-boot
apritzel_ has joined #u-boot
monstr has joined #u-boot
monstr has quit [Ping timeout: 255 seconds]
mckoan|away is now known as mckoan
apritzel_ has quit [Ping timeout: 260 seconds]
ikarso has joined #u-boot
frieder has joined #u-boot
ldevulder has joined #u-boot
Clamor has joined #u-boot
Clamor has quit [Remote host closed the connection]
Clamor has joined #u-boot
mmu_man has joined #u-boot
monstr has joined #u-boot
sszy has joined #u-boot
pgreco has joined #u-boot
pgreco_ has quit [Ping timeout: 260 seconds]
ezulian has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
prabhakar has joined #u-boot
prabhakarlad has joined #u-boot
mmu_man has quit [Ping timeout: 258 seconds]
slobodan has joined #u-boot
mmu_man has joined #u-boot
<xypron>
diederik: U-Boot does not use mounts in the way Linux does. So ftdtdir must be relative to the root of the partition (not necessarily the root in Linux) containing extlinux.conf. On 32bit arm Linux v6.5 has changed added vendor directories for device-trees. This may create some issues depending on your distro.
mripard has joined #u-boot
<mps>
iirc there were vendor directories for some boards in earlier kernels versions but don't remember which ones
<mps>
I have it for starfive visionfive V1 board about year ago
Clamor has quit [Ping timeout: 255 seconds]
Clamor has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
tnovotny has joined #u-boot
<diederik>
dsimic: if I had to set FDT, that would mean I'd have to set it during image build and I'd thus have to run a build for each device to set that. And that would be the only difference between those images. And that's precisely what I wanted to avoid
<diederik>
xypron: Excellent, that's precisely what I needed to know, thanks!
<diederik>
I should've put "u-boot irc" into a search engine much earlier LOL
<mps>
diederik: https://tpaste.us/MRm8 is script by which I build disk/mmc image for gru-kevin chromebook which is rockchip rk3399 SoC. Look at the end where extlinux.conf is created
<mps>
I have such scripts for more devices, arm32, arm64, riscv
<mps>
(maybe is the time to unify all them and put on web)
tnovotny has quit [Ping timeout: 255 seconds]
<diederik>
I let u-boot-menu create my extlinux.conf which seems to do sth similar but is more generic
<diederik>
But I did see some other things which may be useful :) (fat32 comment seems incorrect?)
<diederik>
I'm currently focussed on arm64, but that will be just a parameter in my build script
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #u-boot
tnovotny has joined #u-boot
<diederik>
Does u-boot.bin contain its own (copy of the) FDT? To be used as a fallback in case it can't find the fdt on disk? Or will it just fail to boot then?
prabhakarlad has quit [Quit: Client closed]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
mmu_man has quit [Ping timeout: 258 seconds]
ldevulder has quit [Quit: Leaving]
frieder has quit [Ping timeout: 260 seconds]
tnovotny_ has joined #u-boot
tnovotny has quit [Ping timeout: 258 seconds]
<mps>
diederik: yes, this comment is probably from some of my scripts where is grub used
frieder has joined #u-boot
<mps>
also, you could pack kernel, dtbs and even initram in FIT image
<mps>
for example I've built 'unified' FIT image for mediatek and rockchip chromebooks
<diederik>
I've only heard about FIT image in context of android, but I actually don't know what it is. Should I learn it? (I'm only a user of u-boot)
ldevulder has joined #u-boot
frieder has quit [Ping timeout: 255 seconds]
<mps>
Flattened uImage Tree - FIT
<mps>
well, also I'm only u-boot user and maintainer for alpine. but using arm boxes for long time forced me to learn more deeply about u-boot
umbramalison has quit [Quit: %So long and thanks for all the fish%]
<diederik>
haha, I figured out that I needed to learn more about u-boot too.
umbramalison has joined #u-boot
frieder has joined #u-boot
<Clamor>
Tartarus: hello! May I include you into pmic related mailing list which is hanging for 2.5 months on the next resend?
devarsh has joined #u-boot
mmu_man has joined #u-boot
naoki has quit [Quit: naoki]
<dsimic>
diederik: I see... maybe the solution could be to edit the extlinux.conf file inside generated images, i.e. after dd'ing the boot loader to it
<diederik>
dsimic: what would the benefit be of (explicitly) specifying FDT? IIUC I don't need to do that as I want to use the default as defined in the u-boot.bin
<dsimic>
being 100% sure that the right DT is loaded
<Sout_>
signed images. / verify you know what is being loaded.
<dsimic>
using FDTDIR makes U-Boot build the filename of the final DT, which has many things to go wrong
<dsimic>
as you're already dd'ing the boot loader to the images, maybe mounting their /boot and modifying extlinux.conf wouldn't be much of an extra step
<dsimic>
regarding using the built-in DT, it can be out of date quite ofteh
<dsimic>
s/ofteh/often/
<diederik>
AIUI, it's not using the built-in DT, but using the *value* of the default FDT and use that, combined with FDTDIR, to load the DT provided by my/the kernel image
sakman has quit [Quit: Leaving]
<dsimic>
have you checked that in boot/pxe_utils.c ?
<diederik>
AIUI I need to specify FDT if I want a *different* value then that (or apparently for signed images)
devarsh_ has joined #u-boot
<dsimic>
yes, that ends up defining FDTFILE, see include/configs/rk3568_common.h, and it should work fine in boot/pxe_utils.c
<diederik>
I'm not using PXE boot. While I can read C code to some extend, probably not enough to be sure I know what's really happening
<dsimic>
that's just a wrong name inside U-Boot
<dsimic>
i.e. parsing the extlinux.conf commands happens in a file with a rather wrong name
<diederik>
ah ok
<diederik>
As I'm unfamiliar with both u-boot itself and the code base, I can't figure out how to do things myself. That's why I asked here
<dsimic>
sure
<diederik>
"using FDTDIR makes U-Boot build the filename of the final DT, which has many things to go wrong" I guess I'm not seeing what would go wrong here and is actually exactly what I want?
mmu_man has quit [Ping timeout: 245 seconds]
<paulbarker>
Is there any preference between wait_for_bit_*() and read*_poll_timeout() in u-boot? Both do pretty much the same thing, though wait_for_bit_*() calls schedule() each time it cycles
prabhakarlad has joined #u-boot
<dsimic>
diederik: with the CONFIG_DEFAULT_FDT_FILE and the include/configs/rk3568_common.h stuff in place, it should work fine
<diederik>
ok, cool :)
<dsimic>
of course, testing is the right thing to do, as always :)
<dsimic>
BTW, hmm, there's quite a lot of stuff that could be dedupicated in various include/configs/rk*_common.h files
<dsimic>
s/dedupicated/deduplicated/
<diederik>
yep. My earlier question whether if it can't find _my_ DT if it would then fallback to the u-boot.bin contained one or whether the boot would then fail, is related to that
mmu_man has joined #u-boot
<dsimic>
it should fall back to the built-in DT
<dsimic>
however, that's something I've never actually tested
<diederik>
guess I should add some dummy string to the 'model' string in the dts to be sure I'm actually using mine. A failed boot would actually much easier for me ;)
frieder has quit [Ping timeout: 264 seconds]
<dsimic>
yes, that would be a surefire way to test that the right DT ends up being used
frieder has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
goliath has quit [Quit: SIGSEGV]
Xogium has left #u-boot [leaving channel]
frieder has quit [Remote host closed the connection]
ukky has joined #u-boot
monstr has quit [Ping timeout: 255 seconds]
FergusL has quit [Quit: FergusL]
FergusL has joined #u-boot
ldevulder has quit [Quit: Leaving]
mmu_man has joined #u-boot
tnovotny_ has quit [Quit: Leaving]
mripard has quit [Ping timeout: 240 seconds]
Mis012- has joined #u-boot
Mis012 has quit [Remote host closed the connection]
<alpernebbi>
mps: booting bare-metal was broken last time I checked, but I've been only chainloading from depthcharge/coreboot for a while, even that broke with that commit
<sjg1>
alpernebbi: I wonder when it last worked? I have had my board in the lab for long enough that I didn't notice it breaking
<sjg1>
alpernebbi: I also see this: 9a2e9cc659a mmc: Use regulator_set_enable_if_allowed
<alpernebbi>
git grep "vcca\?1v8_hdmi\|vcca\?0v9_hdmi" shows regulator names are hard-coded in driver, but missing from device trees
<alpernebbi>
maybe it never worked?
<alpernebbi>
for regulator refcounting, maybe it shouldn't have considered already-enabled and already-disabled as errors? (that's how I had done it for phy-uclass so that'd need updating if otherwise)
<sjg1>
alpernebbi: I was wondering about those missing regulators. So strange. I am pretty sure I had it running in January
<sjg1>
alpernebbi: I don't see regulators in Linux either
<alpernebbi>
maybe it's just a case of the driver aborting because it can't find the hard-coded regulators it doesn't need to enable
_whitelogger has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
slobodan has quit [Ping timeout: 245 seconds]
goliath has quit [Quit: SIGSEGV]
<sjg1>
alpernebbi: Hmmm, very sadly it turns out to be the monitor being picky. It works with other boards but not this one. Then I tried another monitor and it is working fine on ToT
<marex>
Tartarus: another great release, :thumbs:up: