07:08 <MoeIcenowy> hantro graduated, when for cedrus?

10:46 <warpme> guys: looking on various help outputs from u-boot tools and can't find: is there any way to "decompile" boot.scr to source text file?

10:49 <apritzel> warpme: you can just remove the first 64 bytes

10:50 <warpme> apritzel: indeed - it looks to me like a bit brute - but effective way to get what i want :-)

10:52 <ndufresne> MoeIcenowy: feel free to send a patch to move it, it's ready for restaging

10:56 <apritzel> warpme: you may find: "$ tail -c +65 your.image" less brutal ;-)

11:01 <warpme> apritzel : are you sure that 64 bytes needs to be removed? I done dd bs=64 skip=1 if=boot.scr of=boot.txt and boot.txt still has binary data at beginning. dd bs=72 skip=1 if=boot.scr of=boot.txt seesm to give me correct result.....

11:03 <apritzel> warpme: pretty sure a "legacy" U-Boot image format header is 64 bytes. What does "file boot.scr" say, is that identified as a U-Boot image?

11:07 <warpme> apritzel : file says: " boot.scr: u-boot legacy uImage, , Linux/ARM 64-bit, Script File (gzip), 1418 bytes, Mon May 29 08:24:32 2023, Load Address: 00000000, Entry Point: 00000000, Header CRC: 0XF0D960D9, Data CRC: 0XE657AC15"

11:13 <apritzel> warpme: is that a *zipped* boot script? Usually you create scripts with "-C none", there is little point in compressing them, really

11:46 <warpme> apritzel : i'm using command like this: mkimage -A arm64 -T script -O linux -d boot.txt boot.scr Adding -C none changes nothing. In all cases I need to remove first 72bytes to get clean .txt source....

12:27 <apritzel> warpme: I see what you mean, there is something between the header (which is 64 bytes, confirmed by the source), and the actual payload. I thought it was just the 64 bytes header, but just keep using 72 bytes instead ;-)

12:28 <warpme> apritzel : thx. I tested 72bytes approach and it works well. thx!

17:51 <wens> seems like h616 r-ahb clock has no parent