warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
obinou3 has joined #u-boot
obinou has quit [Read error: Connection reset by peer]
obinou3 is now known as obinou
warpme_ has joined #u-boot
terminaldweller has quit [Remote host closed the connection]
terminaldweller has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
persmule has quit [Quit: Leaving]
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
fgarcia has quit [Quit: Remote host closed the connection]
<marex>
wbx: and does it work ?
<rfs613>
shadow: there is $(objtree), but you could also just remove $(srcdir) on the destination, since the build directory will be the PWD during compiling
haritz has joined #u-boot
haritz has joined #u-boot
haritz has quit [Changing host]
<rfs613>
shadow: for the SPL size, there are even more than those two unfortunately, different ways of checking the size limit (total size, just code, code+data, excluding stack space, etc). There are different limitations on various hardware.
<rfs613>
for example on socfpga cyclone V, the BootROM code will load the SPL into on-chip RAM. There are 64kB of on-chip RAM, but while BootROM is loading SPL, the top 4 kB are reserved for BootROM. So the maximum SPL size is 60 kB. However as soon as SPL begins executing, the top 4KB is available (BootROM is done), hence there are 64 kB while SPL runs. For example the BSS can go in those 4 kB.
goliath has quit [Ping timeout: 256 seconds]
alpernebbi has quit [Ping timeout: 264 seconds]
Stat_headcrabbed has joined #u-boot
persmule has joined #u-boot
goliath has joined #u-boot
alpernebbi has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
memset has joined #u-boot
<shadow>
rfs613: very helpful thanks for that explanation :)
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<rfs613>
ah yes, I've had that same battle with .its files.
<shadow>
should I copy the .its file to the (presumably $(objtree) ) before running mkimage or how do I inform mkimage where to look for paths
<rfs613>
it looks like your .its refers to all the data files using relative paths, for whatever reason in the parent directory
<rfs613>
this will work fine as long as you are in the right directory when running mkimage
<shadow>
as-is the target's config.mk copies and builds all the files, so that breaks when setting O=
Stat_headcrabbed has joined #u-boot
<shadow>
how would you control the invocation pwd of mkimage from the make build system, adding "cd [path] &&" to the start of the command?
<rfs613>
yeah that would work, even if it's a bit of a big hammer.
<rfs613>
but you might first try running /bin/pwd to see what directory you are in, right before mkimage is called
<rfs613>
AFAIK you should be in the build directory already
<shadow>
it ends up being in $(srctree)/board/spacemit/k3/configs/ because the .its file is in that directory
<shadow>
so I call mkimage refering to that path and its, and relative to the its its 'data = /incbin/(../foobar.ext);' directives are relative to that path in $(srctree)/board/spacemit/k3/configs
<rfs613>
the directory that holds the .its can be different than the directory in which mimage runs
<shadow>
I don't think "cd [path] &&" to start of mkimage command changes where the relative path to an its file is searched
<shadow>
oh, yes to your direct question though the PWD is according to O=
<shadow>
the only thing I can think of different than what the vendor authors did modifying u-boot for their target by copying all the built files to the $(srctree)/board/spacemit/k3 recursively so that the relative path from .its and mkimage would find it, is to copy instead the .its file prior to running mkimage
<rfs613>
you can certainly copy the .its file, though that is normally only necessary if you're going to modify it (eg. adjust paths, or dynamically generate sections of the .its)
<rfs613>
when mkimage starts, you will be in some directory, hopefully it is the O= build directory
<shadow>
yes
<rfs613>
it will then read the .its file (you give it a relative or an absolute pathname)
<rfs613>
and then it will try to open each file exactly as listed, so in your case "../u-boot-nodtb.bin"
<rfs613>
if you are in O= then the ../ is likely incorrect, it should be just "u-boot-notdtb.bin"
<shadow>
I pass the absolute filename since O= set, yes. The trouble is that it is opening each file relative to the path of the .its itself
<shadow>
not the PWD
<shadow>
maybe I am mistaken? when I try this manually from commandline this is how it is
<rfs613>
unless they changed how mkimage works (to change the directory) each file is relative to PWD and not the location of .its
<shadow>
I'll have another look at it, thank you
<rfs613>
in the makefile right before the call to mkimage, you can check the current directory, and you can also check for paths such as "../u-boot-nodtb.bin"
<shadow>
I just try this
<shadow>
data = /incbin/("u-boot-nodtb.bin"); this is relative to the path of the .its file
<shadow>
it does not regard mkimage PWD invocation?
<shadow>
FATAL ERROR: Couldn't open "u-boot-nodtb.bin": No such file or directory
<shadow>
ls u-boot-nodtb.bin -l
<shadow>
-rwxrwxr-x 1 es es 1391032 Aug 5 19:39 u-boot-nodtb.bin
<shadow>
if I symlink ../../source/u-boot.git/board/"spacemit"/"k3"/configs/uboot_fdt.its to the current directory and run mkimage on that, it is successful
<rfs613>
hmm, so that is not how it behaves for me. I solved my problem by removing absolute paths inside the .its file, and then relative paths (which happened to be in the PWD or subdirectories) worked fine.
<shadow>
this is u-boot circa 2022.10 however, if it works differently now that may be why
<rfs613>
i don't think this has changed in years... though it's possible that the vendor modified mkimage.c
<shadow>
no modification from vendor
<shadow>
well.. maybe. re-checking that
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
Stat_headcrabbed has joined #u-boot
<rfs613>
ah, it seems you migh tbe right afer all
<rfs613>
i'm looking at the code that parses /incbin/ and it uses srcfile_relative_open() defined in scripts/dtc/srcpos.c
<shadow>
when was that changed hmm
<shadow>
or is it we just invoke it differently somehow
<rfs613>
looks like since 2017 at least
* shadow
shrugs
<rfs613>
so now I'm wondering why it works for me ;-)
<shadow>
I'm building a different round of u-boot from u-boot mainline to try the tool and see if it actually does behave any different with recent mkimage
goliath has quit [Quit: SIGSEGV]
<rfs613>
the "dtc" command has a "-i" flag for specifying extra search paths, and that gets used by srcfile_relative_open(). But when called from mkimage there doesn't seem to be a way to specify extra search paths.
<rfs613>
actually, there is!
<rfs613>
mkimage -D "-I <searchpath>"
<shadow>
ah!
<rfs613>
I was wondering why it worked for me, and that was the answer
<shadow>
that doesn't seem to do anything for the .its file here at first blush, but I did confirm it's not some change in mkimage from then until more recently
<shadow>
oh -I is input format lol not include
<shadow>
lowercase -i is successful
<rfs613>
yeah sorry
<shadow>
rfs613: lovely, thank you
<rfs613>
I wrote it two years ago and had long forgotten the details
<rfs613>
keep in mind that -D replaces all the options passed to dtc
<rfs613>
so there might be some default ones that "get lost" unless you specify them (in addition to -i )
<shadow>
hmm... not sure how I would discover what those options are being passed.
<rfs613>
see MKIMAGE_DEFAULT_DTC_OPTIONS
persmule has quit [Ping timeout: 252 seconds]
persmule has joined #u-boot
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #u-boot
frieder has quit [Remote host closed the connection]
apritzel_ has quit [Ping timeout: 252 seconds]
sszy has quit [Remote host closed the connection]
<wbx>
marex: with this version I can transfer a file via tftp.