15:23 <bauen1> apritzel: so i've tried to up the spl size to 64kb (minus toc0 magic bytes ~2kb ?) but it fails to execute properly, it actually loads as evidented by a lack of fel, i've setup the headers so the toc0 firmware isn't actually moved (the copy still happens but is effectively a nop) to 0x20840, could this be because after the 32kb SRAM A1 comes the SRAM C which is shared with AR100 and "weird" according

15:23 <bauen1> to https://linux-sunxi.org/SRAM_Controller_Register_Guide ?

15:24 <apritzel> bauen1: which SoC? A64 or H6?

15:26 <bauen1> h6

15:26 <bauen1> might have to do some digging to update the sram page

15:28 <apritzel> On the H6 I could load up to 139KB via eGON, and also via FEL

15:28 <bauen1> actually i don't see the expected behaviour of that memory area, so probably compiling u-boot wrong

15:28 <bauen1> is there a fork of u-boot that includes the changes to make it work with a bigger spl ?

15:29 <apritzel> I think the "weird" behaviour was on the A64, and presumably because some clock was already too high

15:29 <apritzel> bauen1: yes, jernej's h616-v1 branch contains some solution

15:30 <apritzel> it's mostly some artificial limits in the build system, to avoid disappointment

15:31 <bauen1> that's exactly what i'm looking for :)

15:33 <apritzel> n

15:33 <apritzel> bauen1: https://github.com/jernejsk/u-boot/commit/fab8023ebf4c1e is the one for the SPL loading part

15:34 <apritzel> https://github.com/jernejsk/u-boot/commit/3d5c058667a53579c0d is for mksunxiboot

15:37 <apritzel> and there is the last part of this patch: https://github.com/jernejsk/u-boot/commit/be3dda6a89e6d3

15:39 <apritzel> bauen1: for my large SPL tests I just had less than 8KB of code, filled up with a pattern up to the limit, which got verified by the code

15:39 <bauen1> apritzel: thanks, the last patch is what i'm looking for

15:40 <apritzel> so it could well be that there could be problems if those SRAM C areas are used in anger, for instance to fill the I cache

15:40 <apritzel> the H616 manual explicitly mentions that SRAM C can be used at "boot time"

15:41 <apritzel> not sure if that is not really true for older SoCs, or just something that just got officially documented now

15:59 <bauen1> yes, so making the spl bigger (up to maximum of ~63kb) seems to work but for some reason the spl then just starts entering some kind of loop of printing the welcome message, probably after loading something from the sd

16:00 <apritzel> yeah, the whole loading logic is something separate

16:01 <apritzel> at the moment it loads it expects a FIT image at 40KB (8KB SPL offset + 32 KB max SPL size)

16:01 <bauen1> probably legacy image loading

16:01 <bauen1> which i need to switch to fit anyway for verification

16:01 <apritzel> H6 SPLs should be able to autodetect the type

16:02 <bauen1> yes, and it seems to happily load parts of itself without any form of checksum whatsoever, at least that is my hypothesis

16:09 <apritzel> bauen1: to be honest, I only built a 40KB SPL from the *U-Boot source* so far, there might be more surprises (in the build system, memory map or linker scripts) if we exceed certain limits like 64KB

17:16 <smaeul> bauen1: you will need something like https://github.com/jernejsk/u-boot/commit/fab8023ebf4c1e but modified for TOC0 magic

17:16 <smaeul> or modify CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR manually

17:17 <smaeul> I have loaded TOC0 SPL up to 48k on H6 (changing that config from 0x50 to 0x70)

17:19 <bauen1> smaeul: does binman use CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR or do i need to turn some additional knobs for that ?

17:22 <smaeul> no, that's only used at runtime, to determine where to look for the FIT on the SD card

17:24 <smaeul> really it should be `0x10 + (CONFIG_SPL_PAD_TO / 512)`, where CONFIG_SPL_PAD_TO defaults to 32768

17:27 <bauen1> huh, great so this works now to some extend

17:27 <bauen1> kind of stuck on `## Checking hash(es) for Image atf ...` :D

17:28 <smaeul> the hardcoded constant also breaks FIT loading on H3 because the SPL is too small

17:28 <bauen1> but that is something to go of

17:28 <smaeul> see https://github.com/smaeul/u-boot/commit/0943eed3274a

17:37 <apritzel> smaeul: this one takes care of finding the image after the SPL now: https://github.com/jernejsk/u-boot/commit/fab8023ebf4c1e0392a9

17:37 <apritzel> smaeul: feel free to extend this to your needs

17:38 <apritzel> for instance by checking for the TOC0 magic and using the TOC0 size

17:39 <apritzel> this config time CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is really some old U-Boot legacy (because we hardcode everything, you know ...)

18:26 <smaeul> apritzel: I don't see how computing the size at runtime is helpful. it doesn't change after compile time

18:27 <smaeul> and U-Boot already enforces padding: include/config_fallbacks.h:16:2: error: #error CONFIG_SPL_PAD_TO < CONFIG_SPL_MAX_SIZE

18:38 <smaeul> probably best to drop CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and CONFIG_SPL_PAD_TO entirely and do `return 0x10 + spl_size / 512`

18:39 <smaeul> for H6 and up

18:53 <smaeul> (actually V5 is the lowest-numbered SoC to have the new MMIO layout)

19:02 <apritzel> smaeul: I am not sure we always know the offset at the *beginning* of compile time

19:03 <apritzel> since it depends on the SPL code size

19:03 <apritzel> so we could somehow patch in back in later, but what's actually the problem with detecting it?

19:06 <apritzel> but I agree to dropping CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, just not sure this guards something else in the generic SPL code

19:11 <smaeul> apritzel: if CONFIG_SPL_PAD_TO is defined, we know it at the beginning, because that's the only value the offset can be

19:13 <apritzel> yeah, that's rubbish ...

19:13 <apritzel> it should be more of a alignment value

19:14 <smaeul> so that's why I changed my mind on detecting, becase we don't want to force SPL to always be the max size

19:14 <smaeul> yeah, and the aligned size is only known after mkimage

19:16 <smaeul> so the question is: if the user manually enables SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR, should we take into account the SPL size, or assume they know what they're doing and use the value as-is?

19:16 <smaeul> and does as-is include the alternate SPL offset?

19:17 <smaeul> to make a TOC0/eGON universal image, you have to use both SPL locations, so U-Boot proper has to follow the second SPL

19:19 <smaeul> so it'd be nice to say "U-Boot starts at 256k from the start of the disk" regardless of which SPL was loaded

19:20 <smaeul> giving you 120k for the eGON and 128k for the TOC0

19:26 <apritzel> but the boot source byte (@0x28 for eGON) encodes whether it's loaded from 128K or 8K, isn't that true for TOC0 as well?

19:27 <apritzel> but yeah, I am all for some autodetection, but still being able to force it to a fixed value

19:28 <smaeul> most likely, I haven't tried TOC0 at 128K

19:29 <smaeul> but currently I would have to compile SPL twice: once with CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200 and once with 0x110 to undo the offset

19:30 <smaeul> maybe that's fine, if building a universal image needs extra tooling anyway

19:31 <apritzel> I think I tried TOC0 on my Remix at 128K, and had an image that booted on a normal Pine64 and a Remix

19:32 <apritzel> indeed with specifying different offsets

19:32 <apritzel> and yeah, an universal image might be something special

19:33 <apritzel> not sure the current build system is ready for building that out of the box

22:51 <bauen1> alrighty, so after some testing hunting down heisenbugs, it seems that "just" setting the size to 63kb doesn't work

22:52 <bauen1> so there's probably more to it

22:53 <bauen1> or rather, the second that i push the spl just over ~32kb, resulting in padding to 60kb (wtf that shouldn't happen) things just kind of break randomly