Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2023.07.02, v2023.10-rc2 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2023.10 is scheduled for 02 October 2023 / Channel archives at https://libera.irclog.whitequark.org/u-boot
bryanb has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
camus has joined #u-boot
LeSpocky has quit [Ping timeout: 245 seconds]
LeSpocky has joined #u-boot
sukrutb has joined #u-boot
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
camus has quit [Quit: camus]
camus has joined #u-boot
wooosaiiii has joined #u-boot
thopiekar has quit [Ping timeout: 260 seconds]
thopiekar_ has joined #u-boot
stipa_ has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
stipa has quit [Ping timeout: 244 seconds]
stipa_ is now known as stipa
monstr has joined #u-boot
monstr has quit [Ping timeout: 246 seconds]
goliath has quit [Quit: SIGSEGV]
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
monstr has joined #u-boot
sng has joined #u-boot
sng has quit [Remote host closed the connection]
ikarso has joined #u-boot
goliath has joined #u-boot
stefanro has joined #u-boot
frieder has joined #u-boot
mckoan_ is now known as mckoan
<mckoan> good morning
valdemaras has joined #u-boot
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
ldevulder has joined #u-boot
ezulian has joined #u-boot
tnovotny has joined #u-boot
valdemaras has quit [Quit: valdemaras]
flyback has quit [Ping timeout: 248 seconds]
monstr has quit [Ping timeout: 258 seconds]
monstr has joined #u-boot
sng has quit [Remote host closed the connection]
valdemaras has joined #u-boot
mwalle has joined #u-boot
sng has joined #u-boot
valdemaras has quit [Quit: valdemaras]
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
mmu_man has joined #u-boot
prabhakarlad has joined #u-boot
Clamor has joined #u-boot
sakman has quit [Remote host closed the connection]
frieder_ has joined #u-boot
frieder_ has quit [Remote host closed the connection]
sakman has joined #u-boot
monstr_ has joined #u-boot
monstr has quit [Ping timeout: 256 seconds]
frieder has quit [Ping timeout: 246 seconds]
monstr_ has quit [Ping timeout: 250 seconds]
frieder has joined #u-boot
naoki has quit [Quit: naoki]
valdemaras has joined #u-boot
sng has quit [Remote host closed the connection]
sukrutb has quit [Ping timeout: 245 seconds]
flyback has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<paulbarker> Hi folks. Is there any documentation for how `mem_map` is used on arm64 devices (declared in arch/arm/include/asm/armv8/mmu.h)? Or what the `PTE_*` and `MT_*` symbols mean?
prabhakarlad has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
<Sout_> while not that helpful, i assume MT == memory type from the documentation, and PTE == page table entry?
<rfs613> paulbarker: I only know of this nice article, which is for 32-bit arm, not 64, so not much help to you either: https://people.kernel.org/linusw/arm32-page-tables
<rfs613> some googling let me to https://wenboshen.org/posts/2018-09-09-page-table.html not sure if that helps any...
<paulbarker> Sout_, rfs613: I'm reading https://developer.arm.com/documentation/102376/0200 which is making some sense of it
<paulbarker> Slowly
<rfs613> paulbarker: yes the ARM docs are certainly good reference... and they take a long time to digest...
<paulbarker> It's starting to make a bit of sense
<paulbarker> And looking at the code, `mem_map` is just used to set up the TLB
elpogo has joined #u-boot
<marex> paulbarker: I also recall a talk at ELCE (?) from uh ... one of the ARM people ... about formal memory model for kernel
<paulbarker> marex: I'll do a bit of a google
<elpogo> hello. is there any way to get the u-boot prompt to show up on qemu's virtconsole device? i'm using u-boot.bin from guix's u-boot-qemu-arm64 package
<paulbarker> marex: The context here is I need to update `arch/arm/mach-rmobile/memmap-gen3.c` to support the RZ/G2L family, which has a slightly different memory map.
Leopold has joined #u-boot
<paulbarker> And I don't want to just copy paste things without understanding what the defines mean
<marex> ah
rfs613 has quit [Ping timeout: 246 seconds]
rfs613 has joined #u-boot
<paulbarker> marex: I think I now just need to understand what PTE_BLOCK_INNER_SHARE means
<marex> https://lwn.net/Articles/718628/ Will Deacon I think
mmu_man has joined #u-boot
<marex> paulbarker: ah, cfr inner shareable then
<marex> it is somewhere in ARM ARM memory attributes section
<paulbarker> "The division between inner and outer is IMPLEMENTATION DEFINED" (https://developer.arm.com/documentation/100941/0101/Memory-attributes). Looks like I need to dig through our SoC datasheet
frieder has quit [Ping timeout: 252 seconds]
mckoan is now known as mckoan|away
<rfs613> well, that was a fine time for my internet link to drop...
<marex> rfs613: you did not miss anything important
valdemaras has quit [Quit: valdemaras]
<Clamor> marex: That ehci is a fragile mix of chipidea controller and tegra phy. I will not perform this split.
mmu_man has quit [Ping timeout: 250 seconds]
frieder has joined #u-boot
<kwizart> Clamor, pong #ac100 ;)
sng has joined #u-boot
mmu_man has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
sng_ has joined #u-boot
srk- has joined #u-boot
sng has quit [Ping timeout: 256 seconds]
sng_ has quit [Remote host closed the connection]
srk has quit [Ping timeout: 252 seconds]
srk- is now known as srk
sng has joined #u-boot
frieder has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
sng_ has joined #u-boot
sng has quit [Read error: Connection reset by peer]
sng_ has quit [Remote host closed the connection]
jpanisbl has joined #u-boot
jpanisbl has quit [Client Quit]
stefanro has quit [Quit: Leaving.]
tnovotny has quit [Quit: Leaving]
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
LordKalma has quit [Quit: Ping timeout (120 seconds)]
LordKalma has joined #u-boot
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
goliath has joined #u-boot
Clamor has quit [Ping timeout: 245 seconds]
Clamor has joined #u-boot
sukrutb has joined #u-boot
Stat_headcrabed has joined #u-boot
Stat_headcrabed has quit [Quit: Stat_headcrabed]
sng has quit [Ping timeout: 245 seconds]
niska has quit [Ping timeout: 246 seconds]
niska has joined #u-boot
sng has joined #u-boot
<sng> Tartarus sjg1: So Tom had earlier flagged a concern about the sandbox_capsule.dtsi file being added for the capsule generation series - https://lists.denx.de/pipermail/u-boot/2023-August/526987.html
<sng> and I have been able to make changes to move the capsule generation through binman to the test/py/tests/test_efi_capsule/capsule_gen_binman.dts file for the tests. so i was wondering if I should be sending a V11 series which makes this change?
<sng> since the series has not been merged yet
<marex> Clamor: imx also uses chipidea ehci + PHY
<sng> Tom had earlier suggested sending a follow-up series. but since I have this working, and the series has not been merged, I was wondering if I should send a next version of the series, so that this gets addressed before getting merged
<Clamor> marex: may you send me a link to this bundle
valdemaras has joined #u-boot
<NishanthMenon> sjg1: https://github.com/u-boot/u-boot/blob/master/include/env_default.h#L115 -> Any reason for env file to be overwriten by comon CFG_EXTRA_ENV_SETTINGS ? I am trying to set the board/xyz.env to change boot_targets=mmc0 mmc1 usb pxe set in my common config.h file to boot_targets=mmc1 mmc0 usb pxe and it does'nt work..wondering if there is a good reason I am missing
niska has quit [Quit: Leaving]
<marex> Clamor: here is the whole thing
<Clamor> marex: thanks, I will look into this but I will not be able to do anything until I handle other stuff in uboot
ezulian has quit [Ping timeout: 244 seconds]
<marex> Clamor: take your time, and possibly throttle back a little
niska has joined #u-boot
<marex> the PHY stuff is really simplistic
persmule has quit [Ping timeout: 246 seconds]
persmule has joined #u-boot
<Clamor> marex: issue is not in PHY itself but in tegra phy
<Tartarus> sng: Yes, a v11 that just incorporates both cleanly would be nice.
mmu_man has quit [Ping timeout: 246 seconds]
valdemaras has quit [Quit: valdemaras]
<sng> Tartarus Okay. will send V11 with the said changes. thanks
<sng> Tartarus sjg1 I will send a V11 which contains the capsule generation patches, combined with the capsule public key embedding series - https://lists.denx.de/pipermail/u-boot/2023-August/527810.html
<sng> so that all the patches can be applied together. the series for embedding the public key for capsule authentication now has a r-b on all relevant patches from Tartarus
<sng> Tartarus: hope that is fine with you
<Tartarus> sounds good, thanks
mmu_man has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
LeSpocky has quit [Quit: reboot]
<sjg1> sng: Tartarus: I think it is best to let your first series be merged. Perhaps Tom might want to take them both at the same time, not sure. But the series are logically separate IMO
<sjg1> sng: Tartarus Oh just saw the reply above...well...I don't want to review another version of the first series, but it sounds like Tom will
<sjg1> Tartarus: What happened to the ipv6 series?
<marex> Clamor: why ?
<sng> sjg1: Tartarus: Simon, there is only one patch which undergoes a change. that is moving the binman nodes for capsule generation under the test directory. the rest of the patches are the same
<kwizart> Clamor, your tree boots on ac100 but there fastboot isn't enabled (to test fastboot usb as requested) and flash_uboot failed with error finding u-boot-dtb-tegra.bin which isn't surprising as ls mmc dev 0:1 outputs my /boot partition (/ is f2fs formatted, so can't list)
<sng> Tartarus: sjg1: regarding clubbing of the two series (capsule gen + pub key embed), I am fine with whatever approach that suits you and Tom
<Clamor> marex: stuff you have sent is irrelevant apart imx one I suppose. Why? Because tegra ehci is a wild mix of controller and phy involving clock setups, reset setups and a ton of registers configuration for all tegra generations. One wrong move and all this glass store crashes.
<marex> Clamor: maybe tagr can help test it all ?
<Clamor> marex: I have said, I already have too much stuff to upstream, I would like to handle those first. And then I might return to ehci
<Clamor> kwizart: as always, too much knowledge makes testers bad ;)
<Clamor> But non the less thanks, good to know that it boots
foxtrot has quit [Remote host closed the connection]
foxtrot has joined #u-boot
<sjg1> sng: Me too, but I won't be reviewing the first one again. There were a lot of revisions and I suspect we are both exhasusted
ikarso has joined #u-boot
wkennington has joined #u-boot
<marex> Clamor: take your time, I know the feeling /wrt walls of patches
<wkennington> I'm trying to debug an issue with an rk3588 board where when I load a fitImage of larger than 4MB it fails to validate it when trying to `bootm`
<wkennington> any pointers on what config values to check to reason about why it fails to validate?
<wkennington> i figure it's 2 overlapping memory regions
<Clamor> marex: thanks
<marex> wkennington: look at the load address embedded in the fitImage image/ node entries , maybe you are overwriting something ?
<marex> wkennington: compare it with fitImage loadaddress (the one you are passing to bootm)
rvalue has quit [Read error: Connection reset by peer]
vagrantc has joined #u-boot
<wkennington> marex: wouldn't it validate the fitimage before loading?
<wkennington> i feel like the fitimage printout would start printing the first entry
rvalue has joined #u-boot
sng_ has joined #u-boot
sng has quit [Read error: Connection reset by peer]
sng_ has quit [Remote host closed the connection]
<wkennington> from what i can tell there is enough space, the fit load addr is 162M and the loadaddr is ~12M
<wkennington> this works fine if i drop the initrd
<wkennington> purely because the size of the fit is small enough
<marex> wkennington: what is the content of $loadaddr ?
<marex> wkennington: printenv loadaddr
Clamor has quit [Read error: Connection reset by peer]
<wkennington> 0x00c00800
<wkennington> `## Loading kernel from FIT Image at 00c00800 ...`
<marex> wkennington: how big is the fitImage ?
<marex> wkennington: fdt addr $loadaddr ; fdt header something
<marex> see help fdt
<wkennington> 8.4MB
<marex> you can dump the size of the fitImage (if not with external data) from its header
<wkennington> frig
<marex> what ?
<wkennington> i think the first load isn't big enough
<wkennington> let me fix that....
<marex> 0x8000 sectors of 512 Bytes is 16 MiB
<wkennington> yeah nvm
<wkennington> i thought i did that correctly
<wkennington> let me dump the header
<marex> btw you can read just the header, then use fdt + fdt header commands to figure out the size, then run the load with the right size always
<marex> (or use filesystem)
<marex> does it work if you tftp the same image from e.g. network ?
<wkennington> i don't have that working due to lack of support
Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2023.07.02, v2023.10-rc3 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2023.10 is scheduled for 02 October 2023 / Channel archives at https://libera.irclog.whitequark.org/u-boot
<wkennington> 0x812e33
<wkennington> is the size
<marex> wkennington: btw do you have ZSTD support enabled in U-Boot ?
<wkennington> yeah, it works fine if the image is 4MB or less
<marex> hmmm
<marex> Bad FIT kernel image format! (err=-42)
<marex> $ git grep 42 include/ | grep errno
<marex> include/linux/errno.h:#define ENOMSG 42 /* No message of desired type */
<wkennington> yeah
<marex> $ git grep -C 3 ENOMSG
<marex> boot/image-fit.c- /* mandatory / node 'description' property */
<marex> boot/image-fit.c- log_debug("Wrong FIT format: no description\n");
<marex> boot/image-fit.c- if (!fdt_getprop(fit, 0, FIT_DESC_PROP, NULL)) {
<marex> boot/image-fit.c: return -ENOMSG;
<marex> boot/image-fit.c- }
<marex> that is the only occurrance
<wkennington> yeah, and they all have descriptions....
<marex> wkennington: hmmm, do you have some md5sum/sha1sum/crc32 command built in ?
<wkennington> i'll turn on debug
<marex> wkennington: load the fitImage as you did before, but before bootm'ing it , calculate its crc
<marex> use the correct fitImage file size, and compare it with the same checksum on your PC (source file)
<marex> could it be the file is corrupted during load ?
<wkennington> it could be, but i can't imagine why
<marex> could it be you wrote the file short ? (i.e. you wrote only part of the file into storage?)
<wkennington> i checked that already
<marex> wkennington: read back + checksum ?
<wkennington> yeah, sha256 is good for the whole segment
<marex> wkennington: does it also match the source file e.g. on your PC ?
<marex> wkennington: how did you run the checksum in U-Boot ?
<wkennington> wait... it does work now
<wkennington> it looks like my old invocation wasn't reading enough
<wkennington> we are all good
<wkennington> my old invocation had an older build...
<wkennington> :sigh:
<wkennington> user error
<marex> Good
<wkennington> thanks for taking a look
<marex> sure
<marex> wkennington: btw look at setexpr
<marex> wkennington: that would allow you to calculate the $filesize / 0x200 block count for 'mmc write'
<marex> wkennington: then you won't have these issues anymore
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
<wkennington> yeah, this is just an image for bringup
<wkennington> i need to plumb some metadata for stored images in the flash
<marex> why not use a filesystem ?
<wkennington> i've been wanting to avoid using a vfat to do a static a/b setup
<marex> use ext4 ?
<wkennington> i mean, i want guarantees neither file can exceed certain boundsa
<wkennington> so one bad update couldn't prevent another
<marex> wkennington: like ... filesystem indicates it is full kind of thing ?
<wkennington> yeah, although i could have checks in the OS to prevent writing out files that are too big
<marex> wkennington: if you are doing A/B updates, then just have two /boot and two /root partitions
<wkennington> sure, but a /boot with a single fitimage file is kinda dumb
<marex> wkennington: you dont have to write the full partition image, although it is probably a good idea with boot partition to make sure the filesystem is always consistent
<marex> wkennington: why ?
<marex> wkennington: it gives you the "metadata" part
<wkennington> yeah, it's just silly
<marex> wkennington: you can also stick a fitImage into a partition, then read the whole partition in U-Boot and you would be sure you did read enough
<wkennington> that was my plan
<marex> wkennington: or you can read the fitImage header, determine the size, and then read the whole thing
<wkennington> yep
<wkennington> this was my plan
<wkennington> but i just wanted to get the kernel booting before i hacked that in
<marex> I'd probably just opt for as standard and as wildly used (=tested) option available
prabhakarlad has joined #u-boot
<wkennington> is there any way to store the stdout result of some commands to a var?
<wkennington> i guess most command output is just for debugging
<marex> wkennington: nope
<marex> at least not yet
<marex> wkennington: why ?
<wkennington> just wondering for scripting sake
<marex> wkennington: what are you trying to script ?
goliath has quit [Quit: SIGSEGV]
zar has quit [Ping timeout: 244 seconds]
zar has joined #u-boot
redbrain has quit [Ping timeout: 245 seconds]
prabhakarlad has quit [Ping timeout: 246 seconds]