07:14 <j`ey> marex: sorry, I was just grumpy and it was nearly midnight, so it felt like a good time to stop :p

13:19 <marex> j`ey: you could still be a bit more specific -- which platform, how are you loading the blobs etc.

13:32 <j`ey> marex: it's on the Apple M1, there's a program (called m1n1) that copies u-boot to memory somewhere and jumps to it

13:38 <marex> oh that

13:39 <marex> j`ey: look at U-Boot load address, make sure that u-boot.bin or whatever you load ends up at that address

13:39 <marex> then, take u-boot.bin , pad it so the next (kernel arm64 Image) blob is at 2 MiB offset

13:39 <marex> then concatenate them

13:40 <marex> then boot the result , and then booti from U-Boot the kernel Image at wherever you originally loaded the combo blob + 2 MiB

13:40 <marex> that _should_ work assuming u-boot relocation doesn't corrupt the concatenated Image (it shouldn't unless you load it very close to the u-boot relocation address , or early malloc area)

13:42 <j`ey> I will give that a try

13:43 <j`ey> I've been trying something where I include the kernel image in the u-boot build with '.incbin'

13:44 <marex> j`ey: probably dont bother, cat u-boot.bin padding Image > output.blob should do fine

13:44 <marex> j`ey: just read https://www.kernel.org/doc/Documentation/arm64/booting.txt about the alignment requirements

13:45 <j`ey> yeah this is just what I last tried last night, I will try again the other way

13:52 <j`ey> marex: that has gotten me further! getting "FDT and ATAGS support not compiled in" now, looking at the code to try find out which bit exactly is failing

13:53 <marex> the FDT bit

13:53 <marex> did you do booti on the kernel image ?

13:53 <marex> you might need DT too, I'm not sure how that works on the m1

13:53 <marex> either you can build the DT into the kernel image or bundle it again at the end

13:54 <j`ey> yeah I booti the kernel image

13:54 <marex> but then, it might be easier to assemble fitImage of kernel Image and DT and paste it at the end of your bootloader blob instead of the arm64 Image

13:54 <marex> as a bonus, you won't need such a huge padding, since the bootloader would relocate the components to the correct location

13:54 <marex> j`ey: dont you need to booti <kernel image> - <fdt address> ?

13:55 <j`ey> Im not sure, this is my first time using uboot!

13:55 <marex> j`ey: isnt there some howto for the M1 ?

13:56 <marex> if it behaves like a normal arm64 machine, then booti <kernel> - <fdt>

13:56 <j`ey> I'll try that, just have to figure out the fdt address!

13:57 <marex> do you have a .dtb blob for the board ?

13:57 <j`ey> yeah

14:01 <marex> j`ey: well, then just stick at at another 2 MiB pad past the Image and start with that

15:16 <sys64738> hi, im trying to limit the amount of physical memory linux can access on a zynq (because the second core needs to run a baremetal thing, which needs a separate dram range to live in), and, while i can select eg. the uart baudrate in the dtb passed to the kernel, the memory settings seem to persist from uboots builtin device tree, instead of those passed to the kernel from the dtb file loaded from

15:16 <sys64738> the boot medium. what could be the cause of this and is there any way to make linux use the memory configuration in the dtb file instead? (or should i ask this in a different channel?) thanks

15:29 <j`ey> marex: I got further now, "Starting kernel ...", but then nothing :'(

16:02 <marex> j`ey: setenv bootargs console=<specify kernel console> ... might be missing ?

16:03 <marex> sys64738: use reserved-memory { no-map } to define carveout in DT

16:03 <j`ey> marex: I can try that (later)

16:04 <sys64738> marex: ah thanks, ill try that!

16:06 <j`ey> marex: and thanks for the help so far!

16:11 <marex> sure