<rfs613>
to run "make htmldocs" seems to require Sphinx 2.4.4... I can see that is in Ubunty Jammy, but not in previous (eg Focal). Also it seems that even Fedora only has 2.2.11 currently.
<rfs613>
anyhow, the question is, what distro/version are folks who run "make htmldocs" running?
frieder_ has quit [Ping timeout: 252 seconds]
frieder_ has joined #u-boot
prabhakarlad has joined #u-boot
<hanetzer>
marex: sadface. I think the storm we had yesterday may have destroyed the device :/
frieder_ has quit [Ping timeout: 256 seconds]
<Tartarus>
rfs613: use pip
<rfs613>
Tartarus: virtualenv? (or is that even still fashionable)?
<Tartarus>
rfried: moved to freenix since it's NXP stuff and he owns that now
<marex>
hanetzer: ouch, is it dead, Jim ?
<Tartarus>
rfs613: Yes
<marex>
hanetzer: how come ?
<rfs613>
Tartarus: ack, will give it a try
<hanetzer>
marex: bad weather, woke up, tried to fiddle with it, no serial output at all.
<Tartarus>
afk vacation again
<rfs613>
Tartarus: thanks, enjoy your time afk ;-)
<rfs613>
hanetzer: was it the bad weather, or the fiddling, that broke it? :P
<marex>
hanetzer: maybe just the PSU ?
<hanetzer>
rfs613: to be honest I'm not 100% sure.
<hanetzer>
the psu is usb type c to computer :P
<hanetzer>
and it doesn't help that I have *no* confidence in the usb/uart adapter they provided
<rfs613>
hmm, in that case, it seems less likely that bad weather would have killed it (unless the host computer also died?)
<hanetzer>
its a ch340 with some jst header on the end
<hanetzer>
host computer is fine. however, the netgear switch I had it plugged into whines while plugged in now.
<rfs613>
hmm, so maybe some damage did occur. The ch340 seems to be a RS232-to-USB type thingy, you could probably try any other similar converter (just check the voltage levels first...)
<hanetzer>
yeah, but as mentioned, it has a particular header that I don't have anything that fits for
frieder_ has joined #u-boot
<rfs613>
oh I see
<hanetzer>
(instead of just some pins or the like)
alan_ has quit [Quit: Leaving]
alan_ has joined #u-boot
alan_ is now known as alan_o
alan_o has quit [Remote host closed the connection]
alan_o has joined #u-boot
<hanetzer>
but considering that the switch seems fucked (and *maybe* my pcie network card too :/) I think that's all she wrote for it, and the uart is probably fine :/
<rfs613>
right, so pip install gave me sphinx v5.1.1... which did not like "language = None" in doc/conf.py
<rfs613>
forcing that to "en" instead seems to have worked though.
<Forty-Bot>
rfs613: I think there is a requirements.txt
<Forty-Bot>
e.g. pip install -r doc/sphinx/requirements.txt
<rfs613>
ah yes, that might have save me a few guesses
hanetzer1 has joined #u-boot
hanetzer has quit [Killed (NickServ (GHOST command used by hanetzer1))]
hanetzer1 is now known as hanetzer
MWelchUK has quit [Quit: Ping timeout (120 seconds)]
MWelchUK has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
indy has quit [Ping timeout: 256 seconds]
mmu_man has joined #u-boot
justache has quit [Remote host closed the connection]
justache has joined #u-boot
indy has joined #u-boot
vagrantc has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<rfs613>
does patman have an option to add To/CC address to an individual commit? I see Series-To: but not Commit-to: documented.
prabhakarlad has joined #u-boot
<cambrian_invader>
rfs613: Patch-cc
<cambrian_invader>
somehow we ended up with both Patch- and Commit- prefixes for tags
<rfs613>
cambrian_invader: ah, right, thanks... I was sure I saw it, but couldn't find it again ;-)
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
<hanetzer>
sjg1: well, since that thing I had died, think ya could provide some info on how one uses jtag thru the servo board?
<milkylainen>
Umm. Did anyone ever actually look at stm32image?
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #u-boot
frieder_ has quit [Remote host closed the connection]
<milkylainen>
I think u-boot and tf-a should declare that struct as packed. Also it would be useful if they actually had the same declaration. :)
astroid has quit [Killed (NickServ (GHOST command used by astroid_))]
astroid_ has joined #u-boot
<rfs613>
marex: I'm finally making sense of my problem last week with roundup() macro. The problem is actually due to include search path.
<rfs613>
the roundup() macro is defined in u-boot/include/linux/kernel.h
<rfs613>
my code therefore does #include <linux/kernel.h>
<rfs613>
however since it is host-side took (for mkimage), I end up pulling in /usr/include/linux/kernel.h, which lacks roundup()... and a pile of other things present in the u-boot version.
<rfs613>
if do #include "../include/linux/kernel.h" to forcibly pull in the u-boot version, then those "other things" like USHRT_MAX collide with toolchain definitions, resulting in lots of redefined symbol warnings.
<rfs613>
... so I think the best approach is to just put roundup() directly in my .C file
<marex>
sjg1: OK, I finally got around to this CSF again
<marex>
sjg1: during usual test build, I get this
<marex>
Image 'main-section' is missing external blobs and is non-functional: spl uboot
<sjg1>
hanetzer: But I cannot find the dstream stuff that used to be on the site
<sjg1>
hanetzer: It used to be on the chromium.org site but I cannot see it now
<sjg1>
marex: Yes, that makes sense, since binary blobs are missing
<marex>
sjg1: the SPL blob is generated by U-Boot ?
<marex>
if I add no-expanded to the u-boot-spl {} section, it somehow works ...
<marex>
its not clear why
<marex>
u-boot.itb is also at wrong non-fixed offset, no longer 0x57c00
Xeroine has quit [Ping timeout: 256 seconds]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
<hanetzer>
sjg1: dstream?
mmu_man has quit [Ping timeout: 252 seconds]
<sjg1>
marex: OK I can take a look at some point, perhaps in the morning. Can you push a tree somewhere?
<sjg1>
hanetzer: ARM JTAG unit...actually most Chromebooks cannot use JTAG for the AP
<hanetzer>
ah
mmu_man has joined #u-boot
gsz has quit [Ping timeout: 256 seconds]
<marex>
sjg1: it's enough to just compile your tree to detect the failure
<marex>
sjg1: hexdump -vC flash.bin | head
<marex>
the u-boot-spl.bin should start at 0x40
<marex>
with no-expanded it does
<marex>
and u-boot.itb should be at 0x57c00 , that also doesnt need anything built outside of u-boot to be there
<marex>
git clean -fqdx ; make -j imx8mm_venice_defconfig ; make V=1 -j65 flash.bin
<marex>
that's how you can compile the example
<sjg1>
marex: OK I will take a look
<marex>
sjg1: thanks
<marex>
maybe it makes sense to first rework the flash.bin generation, before doing any of the secure-boot attempts, those are completely broken anyway
<marex>
i.e. so that the flash.bin would be generated correctly first
<macromorgan>
where is the maximum size of an itb supported by SPL defined? I noticed when messing with Optee the larger my ITB got the less likely it was I could boot off of it...
<macromorgan>
somewhere between 970k and 1M for the uboot.itb image is where I can no longer boot
<hramrach>
macromorgan: what is the error?
<hramrach>
if you get timeout loading from mmc on rk it's more likely mmc driver limitation than SPL limitation
<hramrach>
the timeout handling is just horrble, and it looks like SPL is 32bit so the calculation is more likely to overflow
<macromorgan>
it's a system freeze on the handoff between A-TF and Optee
<macromorgan>
for some reason enabling fit signature checking works though... weird
<marex>
macromorgan: are you sure you're not rather overwriting the reserved secure RAM area , or accessing it somehow ?
redbrain has quit [Ping timeout: 268 seconds]
<marex>
look at optee CFG_DDR_SIZE=0x20000000 , the optee ends up reserving I think 32 MiB at the end of DRAM