rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
victhor has quit [Remote host closed the connection]
cmeerw has quit [Ping timeout: 272 seconds]
thalesfragoso has joined #linux-sunxi
thalesfragoso has quit [Client Quit]
netlynx has quit [Quit: Ex-Chat]
dev1990 has quit [Quit: Konversation terminated!]
Mangy_Dog has quit [Ping timeout: 246 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
t3st3r has quit [Remote host closed the connection]
t3st3r has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 264 seconds]
asdf28 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
gameblabla has joined #linux-sunxi
gameblabla has quit [Client Quit]
cmeerw has joined #linux-sunxi
apritzel has joined #linux-sunxi
jbrown has quit [Ping timeout: 258 seconds]
apritzel has quit [Ping timeout: 256 seconds]
jbrown has joined #linux-sunxi
apritzel has joined #linux-sunxi
asdf28 has quit [Ping timeout: 264 seconds]
asdf28 has joined #linux-sunxi
victhor has joined #linux-sunxi
yann has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
_whitelogger has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
popolon has joined #linux-sunxi
apritzel has joined #linux-sunxi
sunshavi has quit [Ping timeout: 260 seconds]
<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
<apritzel> bauen1: which SoC? A64 or H6?
<bauen1> h6
<bauen1> might have to do some digging to update the sram page
<apritzel> On the H6 I could load up to 139KB via eGON, and also via FEL
<bauen1> actually i don't see the expected behaviour of that memory area, so probably compiling u-boot wrong
<bauen1> is there a fork of u-boot that includes the changes to make it work with a bigger spl ?
<apritzel> I think the "weird" behaviour was on the A64, and presumably because some clock was already too high
<apritzel> bauen1: yes, jernej's h616-v1 branch contains some solution
<apritzel> it's mostly some artificial limits in the build system, to avoid disappointment
<bauen1> that's exactly what i'm looking for :)
sunshavi has joined #linux-sunxi
<apritzel> n
<apritzel> bauen1: https://github.com/jernejsk/u-boot/commit/fab8023ebf4c1e is the one for the SPL loading part
lkcl has quit [Ping timeout: 256 seconds]
gaston1980 has joined #linux-sunxi
<apritzel> and there is the last part of this patch: https://github.com/jernejsk/u-boot/commit/be3dda6a89e6d3
<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
<bauen1> apritzel: thanks, the last patch is what i'm looking for
<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
<apritzel> the H616 manual explicitly mentions that SRAM C can be used at "boot time"
<apritzel> not sure if that is not really true for older SoCs, or just something that just got officially documented now
lkcl has joined #linux-sunxi
lurchi_ is now known as lurchi__
<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
<apritzel> yeah, the whole loading logic is something separate
<apritzel> at the moment it loads it expects a FIT image at 40KB (8KB SPL offset + 32 KB max SPL size)
lurchi__ is now known as lurchi_
<bauen1> probably legacy image loading
<bauen1> which i need to switch to fit anyway for verification
<apritzel> H6 SPLs should be able to autodetect the type
<bauen1> yes, and it seems to happily load parts of itself without any form of checksum whatsoever, at least that is my hypothesis
<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
jstein has joined #linux-sunxi
dev1990 has joined #linux-sunxi
andy25225 has quit [Ping timeout: 240 seconds]
andy25225 has joined #linux-sunxi
lurchi_ is now known as lurchi__
lucascastro has joined #linux-sunxi
<smaeul> bauen1: you will need something like https://github.com/jernejsk/u-boot/commit/fab8023ebf4c1e but modified for TOC0 magic
<smaeul> or modify CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR manually
<smaeul> I have loaded TOC0 SPL up to 48k on H6 (changing that config from 0x50 to 0x70)
<bauen1> smaeul: does binman use CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR or do i need to turn some additional knobs for that ?
<smaeul> no, that's only used at runtime, to determine where to look for the FIT on the SD card
<smaeul> really it should be `0x10 + (CONFIG_SPL_PAD_TO / 512)`, where CONFIG_SPL_PAD_TO defaults to 32768
<bauen1> huh, great so this works now to some extend
<bauen1> kind of stuck on `## Checking hash(es) for Image atf ...` :D
lurchi__ is now known as lurchi_
<smaeul> the hardcoded constant also breaks FIT loading on H3 because the SPL is too small
<bauen1> but that is something to go of
<apritzel> smaeul: this one takes care of finding the image after the SPL now: https://github.com/jernejsk/u-boot/commit/fab8023ebf4c1e0392a9
<apritzel> smaeul: feel free to extend this to your needs
<apritzel> for instance by checking for the TOC0 magic and using the TOC0 size
<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 ...)
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #linux-sunxi
<smaeul> apritzel: I don't see how computing the size at runtime is helpful. it doesn't change after compile time
<smaeul> and U-Boot already enforces padding: include/config_fallbacks.h:16:2: error: #error CONFIG_SPL_PAD_TO < CONFIG_SPL_MAX_SIZE
<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`
<smaeul> for H6 and up
<smaeul> (actually V5 is the lowest-numbered SoC to have the new MMIO layout)
warpme_ has joined #linux-sunxi
<apritzel> smaeul: I am not sure we always know the offset at the *beginning* of compile time
<apritzel> since it depends on the SPL code size
<apritzel> so we could somehow patch in back in later, but what's actually the problem with detecting it?
dev1990 has quit [Read error: Connection reset by peer]
<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
dev1990 has joined #linux-sunxi
<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
<apritzel> yeah, that's rubbish ...
<apritzel> it should be more of a alignment value
<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
<smaeul> yeah, and the aligned size is only known after mkimage
<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?
<smaeul> and does as-is include the alternate SPL offset?
<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
<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
<smaeul> giving you 120k for the eGON and 128k for the TOC0
<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?
<apritzel> but yeah, I am all for some autodetection, but still being able to force it to a fixed value
<smaeul> most likely, I haven't tried TOC0 at 128K
<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
<smaeul> maybe that's fine, if building a universal image needs extra tooling anyway
<apritzel> I think I tried TOC0 on my Remix at 128K, and had an image that booted on a normal Pine64 and a Remix
<apritzel> indeed with specifying different offsets
<apritzel> and yeah, an universal image might be something special
<apritzel> not sure the current build system is ready for building that out of the box
ldevulder__ has joined #linux-sunxi
ldevulder_ has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
apritzel has quit [Ping timeout: 264 seconds]
lurchi_ has quit [Ping timeout: 260 seconds]
luke-jr has quit [Ping timeout: 265 seconds]
gaston1980 has quit [Quit: Konversation terminated!]
luke-jr has joined #linux-sunxi
sunshavi has quit [Quit: ERC (IRC client for Emacs 27.1.90)]
sunshavi has joined #linux-sunxi
vagrantc has joined #linux-sunxi
linkmauve has quit [Ping timeout: 260 seconds]
sunshavi has quit [Ping timeout: 240 seconds]
maciejjo has joined #linux-sunxi
sunshavi has joined #linux-sunxi
megi has joined #linux-sunxi
apritzel has joined #linux-sunxi
linkmauve has joined #linux-sunxi
megi has quit [Quit: WeeChat 3.0]
megi has joined #linux-sunxi
megi has quit [Client Quit]
megi has joined #linux-sunxi
megi has joined #linux-sunxi
megi has quit [Client Quit]
asdf28 has quit [Ping timeout: 260 seconds]
megi has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
<bauen1> alrighty, so after some testing hunting down heisenbugs, it seems that "just" setting the size to 63kb doesn't work
<bauen1> so there's probably more to it
<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