<marex>
Tartarus: the log files contain nothing useful, they are just random churn
<marex>
Tartarus: there is nothing which would indicate why binman ignored mkimage, or why section makes binman no longer generate symbols
persmule has quit [Remote host closed the connection]
<marex>
I feel like I am just wasting time with this tool, like I am going in circles, making literally zero progress
apritzel_ has quit [Ping timeout: 252 seconds]
rvalue has quit [Ping timeout: 240 seconds]
rvalue has joined #u-boot
<marex>
also, why does binman first run mkimage (if it ever runs it) on a content of a section in its node , and only then patches in BSYM into the input files for mkimage ?
<marex>
mkimage obviously already ran, so, all those data are lost, resulting in useless image
pgreco_ is now known as pgreco
cJ has quit [Server closed connection]
cJ has joined #u-boot
teejay has joined #u-boot
<marex>
hmmm, section in a section results in binman skipping the filename of inner section and picks just some random filename further down the tree ?
<jclsn>
cambrian_invader: Maybe I should just use gpio_request_by_line_name then :)
<jclsn>
It is more convenient for my use case
ldevulder has joined #u-boot
sszy has joined #u-boot
jaganteki has joined #u-boot
jaganteki has quit [Quit: Client closed]
kwizart has quit [Server closed connection]
kwizart has joined #u-boot
jaganteki has joined #u-boot
sng has quit [Remote host closed the connection]
<jclsn>
There is only request_by_phandle in my case. Maybe my version is too old
ikarso has joined #u-boot
sng has joined #u-boot
sng has quit [Ping timeout: 245 seconds]
<sjg1>
Tartarus: For binman, the output directory is explicitly specified, so intermediate files are preserved. There are no actual log files, but you can use BINMAN_VERBOSE=5 to turn on max logging
sng has joined #u-boot
<sjg1>
marex: 'binman test -X testMkimage' will let you see how it works with mkimage. That example is very simple and just usese a single test file - 156_mkimage.dts. It doesn't have the mkimage in a section, so it resembles what you want
<sjg1>
marex: If you push a tree somewhere with what you have done and what you are expecting, I could tell you why it is doing what it is doing, but I don't have any information to go on. I am working UK time today/tomorrow
sng has quit [Read error: Connection reset by peer]
sng_ has joined #u-boot
prabhakarlad has joined #u-boot
<marex>
ah yes, the usual "run hello world" answer
<sjg1>
What is the patch 'binman: Convert mkimage to Entry_section' ? That probably changes the behaviour of the mkimage entry type
<sjg1>
marex: In fact, 'binman test testMkimage' fails with your patches!
<marex>
sjg1: without that spl is not expanded or whatever
<marex>
sjg1: you can revert it and see that there are other failures
<sjg1>
marex: OK, but you have broken the mkimage etype, which is probably why it isn't working properly
<marex>
sjg1: again, this is mandatory to get any useful result at all, otherwise binman would either ignore the SPL binary altogether, or won't expand it, or fail in different weird ways
<marex>
sjg1: you can try and revert it to see the other failures
<marex>
sjg1: this mkimage etype section entry whatever it is was the only meaningful progress I made in the last few days on this (without being able to get any help as usual)
<sjg1>
marex: OK, then create a test with the case you want to support - e.g. testMkimageSpl and I can take a look getting it to pass
<sjg1>
marex: You would find it much easier to start with a test that does what you need...how do I run this (after reverting that patch) and see the failures?
<marex>
you have to be kidding me ... so ... nothing works, I cannot get anything meaningful out of it or even wrap my head around the tool and the answer is ... take the next step, write a test ?
<marex>
make verdin-imx8mp_defconfig ; make flash.bin
<marex>
for example ... compare the flash.bin before and after and see how it differs
<sjg1>
marex: That is how you can learn how the tool works, which will help you. That is how I enhance it...I figure out what I want and then add a test for it, then get it to pass without breaking anything else
ldevulder has quit [Quit: Leaving]
<sjg1>
marex: Will take a look in a bit
<marex>
sjg1: that is great, but did it ever occur to you that I already burns tens of hours on this tool and made no progress at all, so either, I am complete moron, or the tool is at fault ?
ldevulder has joined #u-boot
<marex>
*burnt
<marex>
sjg1: same would apply to NXP who also tried and ... no result
prabhakarlad has quit [Quit: Client closed]
sng has joined #u-boot
sng_ has quit [Read error: Connection reset by peer]
Jacmet has quit [Server closed connection]
Jacmet has joined #u-boot
ldevulder has quit [Quit: Leaving]
sng has quit [Remote host closed the connection]
ldevulder has joined #u-boot
sng has joined #u-boot
<sjg1>
marex: I think you would do better if you take some notice of my suggestions.
<sjg1>
For me I get this with the first command: binman: Filename 'lpddr4_pmu_train_1d_imem_202006.bin' not found in input path (.,/home/sjg/c/src/third_party/u-boot/files,/home/sjg/c/src/third_party/u-boot/files/board/toradex/verdin-imx8mp,arch/arm/dts) (cwd='/tmp/b/verdin-imx8mp')
<sjg1>
marex: so I don't know if it is working or not. The second command is odd, because flash.bin should be an output if binman is enabled. i.e. it doesn't seem to be needed?
<sjg1>
marex: Perhaps we can meet up next week and look at it?
<sjg1>
marex: I see what you mean about mkimage...easiest for now is to add a section inside, as you have done. I will look at what is needed to convert mkimage to a section
<marex>
$ stat -tc %n:%s lpddr4_pmu_train_*
<marex>
lpddr4_pmu_train_1d_dmem_202006.bin:1660
<marex>
lpddr4_pmu_train_1d_imem_202006.bin:32364
<marex>
lpddr4_pmu_train_2d_dmem_202006.bin:1404
<marex>
lpddr4_pmu_train_2d_imem_202006.bin:25456
<marex>
that's the blobs and their filesize, easiest is to just dd so many bytes from urandom into those files
<marex>
sjg1: flash.bin is the ONLY output that is required
mmu_man has joined #u-boot
<sjg1>
marex: OK so now it builds...now what? There is no FDT map in the image so I can't really look at it