<bauen1>
hi, i'm playing around again with my pine boards, is there an "easy" way of temporarily preventing boots from the SPI NOR Flash for testing ? I know there is an SD-Card image to drop back in to FEL, but maybe there is a way of pulling 1-2 pins down to make the Allwinner chip on my Pine H64 not recognize the SPI NOR Flash as valid boot image ?
rajkosto has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
JohnDoe_71Rus has joined #linux-sunxi
mripard has quit [Read error: Connection reset by peer]
mripard has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
jelly has quit [Server closed connection]
<gamiee>
Hi bauen1, I'm on the phone at the moment, but as far as I remember, on GPIO PI-2 bus, the SPI on it is the same SPI used for SPI Flash, so when you short MOSI with GND (or other SPI) pin, you will bypass SPI boot, but better verify it by checking schematics
evadot has quit [Server closed connection]
evadot has joined #linux-sunxi
jelly has joined #linux-sunxi
hlauer has joined #linux-sunxi
hlauer has quit [Quit: Leaving]
cnxsoft has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
apritzel has joined #linux-sunxi
rajkosto has joined #linux-sunxi
veremitz has quit [Server closed connection]
veremitz has joined #linux-sunxi
vpeter has quit [Remote host closed the connection]
vpeter has joined #linux-sunxi
JohnDoe_71Rus has quit []
landnode has joined #linux-sunxi
<landnode>
Hi everyone, I wanted to ask about D1 and specifically the image format used (IMAGEWTY) burned to an sd card with a utility called PhoenixCard.
<landnode>
is the format written specifically to the SDCard or is it 'deconstructed' by PhoenixCard and then standard partitions added to the SD Card?
bauen1 has quit [Server closed connection]
bauen1 has joined #linux-sunxi
Nemo_bis has quit [Server closed connection]
Nemo_bis has joined #linux-sunxi
rellla has quit [Server closed connection]
rellla has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
rm has left #linux-sunxi [#linux-sunxi]
rm_ has joined #linux-sunxi
<rm_>
landnode, IMAGEWTY image is not written as is to an SD card, the program unpacks it in some way, yes
<rm_>
but it is hard to call the end result "standard", with its 8 GPT partitions, broken GPT, Android boot image and all that :)
<rm_>
but it expects a PHOENIX_CARD_IMG signature instead of IMAGEWTY
<rm_>
so it needs to be modified and I'm not sure if the signature is the only difference
cnxsoft has joined #linux-sunxi
ignne has joined #linux-sunxi
apritzel has joined #linux-sunxi
<landnode>
ok thanks, I managed to finally get my board to boot now with the link you provided.
<landnode>
i'm installing win10 on a vm to checkout the PhoenixCard tool.
<landnode>
I was surprised they still require windows in the toolchain.
<landnode>
this is a Lichee RV, it's interesting it has quiescent draw through the uart RX to power some of the LEDs...
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<aggi>
which is the earliest linux-kernel version supporting any decent ARM SBC?
<aggi>
i am asking, since i explained some time ago, i want to drop GCC (and llvm already is) entirely, and use TinyCC instead
<aggi>
which was known to work with kernel-2.4
<aggi>
currently i am digging inside a kernel-4.6 branch (which had increased ten-fold in memory consumption and LoC since 2.4);
<aggi>
this kernel-4.6 was patched to support x86_64 with tinycc, however i am not sure where i am heading at currently
<aggi>
besides, earlier kernel versions supported various extensions which are gone (OpenSSI/beowulf type clustering, fbui in-kernel window manager, e2comp, etc.), and old kernel versions were more efficient (less LoC, less memory, smaller kernel image)
<aggi>
and i fear, i may not succeed anymore to feed kernel 5.10LTS into TinyCC for bare-metal aarch64 or aarch32
<aggi>
downgraded to gcc-4.7 already, and removed all c++ dependencies from my gentoo-profile, however currently kernel is a huge challenge
<aggi>
which is the first component i desire to compile with tcc, next u-boot, and then the entire user-space which was cleaned up already
<ignne>
Are you doing that just for fun, do you need Linux abi/features, or do you have a certain goal? Because it sounds like you could get even better results in that regard with an rtos
evgeny_boger has joined #linux-sunxi
<aggi>
gm ignne, good question, keep it at "just for fun", since there isn't any commercial nor political interests involved at all, it is merely technical concerns which made me conclude
<aggi>
i am willing to replace both a linux kernel and/or particular hardware, if it doesn't meet various criteria
<ignne>
aggi: So your goal is to have the least overhead /most efficiency possible, right?
<aggi>
if i can spawn gentoo-portage on top of anything this would be helpful, with dependency tracking of whatever upstream does
<aggi>
ignne: i am willing to compromise and are aware of the trade-offs, otherwise i wouldn't use GNU/Linux kernel and GCC currently
<aggi>
another limiting factor is this: hardware, which is currently some ARM SBC
<aggi>
however, if i fail with feeding any linux-kernel/aarch64/v5.10LTS into TinyCC , then chances are i'll quit entirely with any efforts at that frontline
<ignne>
Interesting project! I don't know too much about gentoo, but I think they only support Linux as a kernel.
<aggi>
i am not insisting on gentoo/portage, although it was very helpful to crossdev/downgrade to gcc-4.7(no-c++) and cleanup the entire userspace
<aggi>
however, i fear, next on TODO was compiling linux kernel and u-boot loader for aarch64 (or aarch32) with TinyCC for verification, because those are the most crucial to retain any ARM SBC type system
<ignne>
I think Linux itself only reliably compiles on GCC and clang
<ignne>
In that order, usually
<aggi>
Michael Matz, from SUSE, had demonstrated, he could compile linux-4.6 for x86_64 with tcc
<ignne>
Really? Didn't know that
<aggi>
however, for the ARM SBC i got here i would need v5.10LTS and aarch64 already; in any case the corner-stone of proof currently is if and what can be compiled with tcc (which supports aarch32,aarch64, C99, some gnu extensions, some C11)
<aggi>
ignne: youtu.be/iU0Z0vBKrtQ
<ignne>
A lot of SoCs from 5+ years ago are still around and happily run on 3.x
<ignne>
I think another big chunk runs on 4.14
<aggi>
side note: i verified some ARM SBC vendor kernel branch of v4.4 and didn't manage anymore to scrape a clean diff of what they added there
<aggi>
otherwise, i had downgraded to v4.4 already
<aggi>
furthermore, even if i succeed with v5.10 and tcc compiler, then the problem of bloat (10x the size of v2.4) problem remained
<aggi>
ignne: any hardware or RTOS kernel recommended?
<ignne>
Yeah, but lots of that stuff could probably be avoided
<ignne>
You can shave off a lot of compile time and LoC if you don't support any extra hardware or features
<aggi>
already did, the minified .config for a decent aarch64 kernel yields a kernel image of 14MiB with modules statically included (which is still insanely huge, in comparison to v2.4 and 2MiB at it's time)
<aggi>
and this still requires ~30min to compile on an a53 quadcore, which is insane too, given the project from SUSE managed with <10S for this alone
<aggi>
anyway, coffee flooded into brain meanwhile, i'll see what i can do
<ignne>
Hm, that looks quite large, I don't have access to my build computer right now, but even a full-fledged android 3.10 with bells and whistles is around 20MB
<ignne>
*android kernel
<aggi>
to summarize: compiling kernel v5.10 and u-boot loader with tcc, if anyone had some interest
<aggi>
and this is some old repo which implemented JIT compilation of kernel v2.4 with tcc as a boot-loader, tccboot: https://github.com/seyko2/tccboot
<aggi>
target: bare-metal aarch32/aarch64
gsz has quit [Ping timeout: 480 seconds]
<ignne>
I took a quick look, and both Allwinner and "original" Raspberry kernels are at least 3.x
<ignne>
So do most phones that aren't completely obsolete by now
<aggi>
i'll verify first v4.6 which is known-good for x86_64 with tcc; see what this yields for aarch64/32 bare-metal
<ignne>
My best bet for really old kernels would be x86, it is supposed to still be dos-compatible, and you can get used Atom tablets for cheap. Otherwise, there should be reasonably well working kernels all the way down to 3.X for the A20 and the like
<apritzel>
aggi: I don't think you can even compile U-Boot without a more recent compiler
<apritzel>
the official requirement is GCC 6, since compilers before that lacked the toolchain garbage collection we rely on to get the SPL fit in 32KB
<apritzel>
aggi: you would need to have a *very good* reason for your approach, I'd say: otherwise you just waste a lot of time on your side and throw away years of development efforts from the community
<apritzel>
in the past embedded systems really lacked resources like storage and DRAM to run off-the-shelf kernels, but the smallest Allwinner ARMv8 board I know of has at least 256MB of DRAM
<apritzel>
so 14MB for the kernel image is not really a problem, I'd say
<ignne>
If you really want to go low, I'd say use FreeRtos or something like that, as long as you don't care about all the nice high-level Linux features
<apritzel>
indeed, that would be another approach
<apritzel>
if you are after image size: why not work on a modern kernel and see what you can do to bring the size down? That would be so much more useful for *everyone*
<apritzel>
aggi: did you compress your kernel? I remember putting a compressed 11MB arm64 5.15 kernel into SPI flash, which still leaves room for a 4MB of initrd
<aggi>
greetings apritzel: i welcome any critique, however if anyone had wasted time and efforts it wasn't me; as far as politics of this are concerned
<aggi>
and the very good reasons are merely technical concerns
<aggi>
otherwise, compressing kernel image does not reduce the final uncompressed image size in memory
<aggi>
the metrics were only shown as an indicator, what went wrong
<aggi>
tccboot JIT compiled kernel-2.4 (with networking support) during boot in ~10s, the minified 14MiB kernel image of mine required ~30min with gcc-6.5
<apritzel>
aggi: kernel 2.4 had arm64 support?
<aggi>
of cause not, the PoC was for x86 at that time
<aggi>
with v4.6 Michael Matz demonstrated x86_64, and currently i am revisitting this for an aarch64 kernel
<aggi>
aarch64 support was introduced with gcc-4.8/9; that's why i asked about aarch32 support for cortex a53 some time ago, because i downgraded gcc to v4.7.4 already (for userspace, all c++ removed), and had to retain an aarch64 kernel-5.10 for the hardware i got
<apritzel>
aggi: have you followed the effort it took to make the kernel compile with clang? That took years, and at the end LLVM just gave up and picked up most of the GCCisms.
<aggi>
apritzel: i am aware of the llvm/clang strategy, yes
<aggi>
even worse, recently GNU/Linux vendor-locked into >=gcc-4.9 (which is written in c++); that's why i patched kernel-5.10 to remove some C11 magic already
<aggi>
linux Kbuild requires some support to output asm (gcc -S), which tcc -S cannot yet; which is a problem which can be solved (maybe hook into objdump to output required asm)
<aggi>
anyway, i am not too optimistic about GNU/Linux kernel and u-boot; at least i can try to compile the entire userspace which i downgraded to gcc-4.7.4 already, and removed all c++ dependencies from
<aggi>
however, then, i got a userspace, without u-boot/kernel/hardware which would meet some minimum acceptance criteria
<apritzel>
aggi: vendor-locked? wow ...
<aggi>
a rather aggressive one
<apritzel>
I mean "wow, you are in some weird place" ;-)
cnxsoft1 has quit []
<bauen1>
smaeul: i'm testing your smauel/patch/mkimage-toc0 branch while booting from SPI NOR Flash, and I've ran across another hard coding of the eGON format in arch/arm/mach-sunxi/spl_spi_sunxi.c with `int load_offset = readl(SPL_ADDR + 0x10);`, that should probably be replaced by a call to `sunxi_get_spl_size`
<bauen1>
gamiee: thanks a lot, i eneded up attaching a wire to the flash chip itself as its on a different spi bus
<bauen1>
aggi: i'd recommend you to check out https://bootstrappable.org/ and the #bootstrappable irc channel on libera, they / we have some goals in common
<bauen1>
seems that i never setup sasl for oftc so i've been shouting into the void since a few hours *facepalm*
<apritzel>
bauen1: we can hear you now ;-)
<apritzel>
aggi: most people expect the Linux kernel to be fast, stable, scale-able, maintain-able and with vast driver and platform support. This is what people focus their development efforts on.
<apritzel>
aggi: "being able to compile with some specific compiler" is not very high on that priority list, and certainly must not hurt the other requirements
<aggi>
apritzel: i am well prepared for political argument
<apritzel>
aggi: I am not. And that's the point: that is not a political argument
<bauen1>
aggi: i'm not sure what exact C11 features the kernel uses, but the tinycc mailing list wants to implement more of them iirc
<apritzel>
it's a sheer case of "you focus on what's useful and what people ask for"
<aggi>
tccboot with kernel2.4 demonstrated just that: fast, scale-able, maintain-able etc.; and since then the situation got worse, alot
<apritzel>
I don't getit
<aggi>
and, to remove c++ dependencies with the downgrade to gcc-4.7.4 was weeks of work
<apritzel>
kernel 2.4 is ancient, it supported a fraction of the features a modern kernel does
<aggi>
bauen1: noticed. currently i am fighting at too many frontlines already; gcc -S / tcc -S is the current showstopper, to output asm which is required with Kbuild procedure
<aggi>
anyway, a moment ago my goals have regressed considerably, to re-consider which kernel and hardware could meet minimum acceptance criteria
<apritzel>
aggi: didn't Michael Matz built the kernel without kbuild for that exercise?
<aggi>
apritzel: no. there was two projects. the original tccboot for kernel2.4, and michael matz coped with kernel4.6
<aggi>
tccboot/v2.4 replaced the entire kbuild
<apritzel>
you mean the kbuild as of >20 years ago?
<aggi>
no, tccboot/kernel-2.4 was year 2005
<apritzel>
oh, sorry, 17 years, that makes a difference ;-)
<aggi>
at the same time, btw., tcc too demonstrated it could bootstrap gcc, something i talked about in #gcc yesterday
<aggi>
too #gentoo-arm already confirmed they saw little hope for GNU/Linux anymore with tinycc
<aggi>
it's total dead-end at all frontlines
<apritzel>
I think compilers in general are somewhat designed to be bootstrap-able with random other compilers, because that's required to get it to work on any platform
<apritzel>
aggi: I appreciate your fight against bloat, but you have to certainly pick your battles more wisely ...
<bauen1>
apritzel: you'd be surprised how wrong that statement is in practice, at least if you mean bootstrappable from source code :(
<bauen1>
aggi: live-bootstrap currently builds the linux kernel 4.9.10 using gcc-4.0.4 so you might want to take a look at that
<aggi>
bauen1: i already patched v5.10 and it passes gcc-4.7.4; however i couldn't boot this aarch32 kernel with the hardware i got
dliviu has quit [Ping timeout: 480 seconds]
dliviu has joined #linux-sunxi
ftg has joined #linux-sunxi
<smaeul>
bauen1: thanks! I will include that fix in the next version of the series
<bauen1>
and u-boot actually has an UEFI, UEFI SecureBoot Implementation and TPM support, so apart from the horribly broken secure boot support in the h64 bootrom, technically i'm all set for a secure boot chain
<bauen1>
smaeul: thanks for working on toc0 support :)
ftg has quit [Ping timeout: 480 seconds]
<bauen1>
yes, so i can just load the grub efi to memory, run it, then load linux, initrd, boot and it just works ; this feels very weird
<bauen1>
and now I'm wondering why I don't know of any projects that use that provide a u-boot for the spi flash on those arm boards, which then behaves just like a UEFI BIOS
apritzel has quit [Ping timeout: 480 seconds]
ignne has quit [Ping timeout: 480 seconds]
ignne has joined #linux-sunxi
vagrantc has joined #linux-sunxi
apritzel has joined #linux-sunxi
wingrime has joined #linux-sunxi
gsz has joined #linux-sunxi
<apritzel>
bauen1: I am using that approach for years, on SPI flash and on eMMC boot partitions
<apritzel>
this is all towards an installer image, which boots from an SD card, then offers to copy U-Boot to the SPI flash or eMMC boot
JohnDoe_71Rus has quit []
<bauen1>
"As an added bonus there is some whacky code to make the SPI flash usable in Linux on H6 boards." - i didn't notice that was broken
<bauen1>
apritzel: i have a pine a64 lts and a pine h6, but the pine h6 is using secure boot, so i need to also use smaeul patches for that
<apritzel>
bauen1: one pin is shared between SPI0 and the eMMC
<apritzel>
yeah, we need to push on those mkimage patches again. patch 1 got blocked on some stupid openssl problem
<smaeul>
I think I will respin with just skipping that patch an only worrying about sunxi
<smaeul>
bauen1: see https://tow-boot.org/ which intends to distribute U-Boot builds that Just Work like a PC BIOS
rajkosto has quit [Read error: Connection reset by peer]
wingrime has quit [Remote host closed the connection]
ignne has quit [Read error: Connection reset by peer]
<bauen1>
smaeul: another thing i did when building my toc0 images was to set CONFIG_SPL_TEXT_BASE=0x20840 ; this matches the address where the toc0 "content" is loaded, the default of 0x20060 would make the SBROM copy the content over the initial toc0 image
gsz has quit [Ping timeout: 480 seconds]
<bauen1>
and i still have to set CONFIG_SPL_LOAD_FIT_ADDRESS to something, i'm not really sure why or if the pine_h64_defconfig is broken (i guess not)
<aggi>
reminds me, tried to document an address mappings table for some pine64 boards, and gave up on it
<aggi>
besides some "reserved"/undocumented regions of dozens of Megs, i couldn't track down another almost 100MiB removed from free memory available
<bauen1>
aggi: you mean the memory in the DRAM ?
<aggi>
bauen1: no. i mean the entire address space, which i think was 32bit (even with aarch64)
<aggi>
as said, i gave up at this frontline too
<bauen1>
aggi: I made a nice table of the H6 Memory map here (https://linux-sunxi.org/H6/Memory_map), NBROM,SBROM are ROM, SRAM A1, SRAM C, SRAM A2, DE, CE_KEY_SRAM, VE_SRAM, CSI_SRAM, DRAM are potentially memory, but for the SRAM theres some sharing / weirdness with the coprocessor and i'm not sure about the DE, VE, CE_KEY
<bauen1>
aggi: if CONFIG_SPL_LOAD_FIT_ADDRESS is not set it defaults to 0, but it should only be used if loading the FIT from ram, so i'm a bit confused what's happening here
<apritzel>
aggi: are you missing something from the memory map in the A64 user manual?
<bauen1>
huh, it does indeed have no effect so it's not CONFIG_SPL_LOAD_FIT_ADDRESS but something else that's causing u-boot load failure
<aggi>
sorry for the misunderstanding, it wasn't some allwinner chip from pine64, otherwise the A64 pinebook didn't ship anywhere anymore otherwise i certainly had looked at it
<bauen1>
apritzel: so i'm having trouble disabling CONFIG_SPL_MMC, which should be fine since i'm loading u-boot from spi flash, could that also be because of this shared pin ?
<apritzel>
bauen1: "trouble disabling" as in: doesn't build?
<apritzel>
disabling or enabling random Kconfig options often doesn't work easily in U-Boot, there are too many built-in assumptions
<bauen1>
apritzel: "trouble disabling" as in: does not boot
<bauen1>
Trying to boot from sunxi SPI
<bauen1>
SPL: failed to boot from all boot devices (err=-6)
<apritzel>
bauen1: interesting
<bauen1>
apritzel: perhaps it's also removing some other rather important part from the SPL related to the SPI sunxi driver, but I haven't found something, and it's only this config option being disable
<apritzel>
bauen1: can you "#define DEBUG" to the top of arch/arm/mach-sunxi/board.c? Maybe other files of interest? That should give you more output
<apritzel>
must be defined before including anything
<apritzel>
bauen1: why do you want to disable it in the first place? to remove an attack vector?
<bauen1>
apritzel: yes, and it's huge, disabling brings down the spl size from ~40kb to ~26kb, and also seems to make the boot a lot faster, probably because the sbrom isn't particularely fast
<apritzel>
bauen1: in general we want to avoid those custom changes, and keep the firmware universal
<apritzel>
for instance I do "mmc read ...; sf write" to copy U-Boot, just booted from an SD card, to the SPI flash
<bauen1>
apritzel: that's after the spl, and i mostly want to leave that alone, but i want to make the spl a bit smaller if possible
<apritzel>
I just saw CONFIG_SPL_MMC_TINY, maybe that's worth a look
<apritzel>
bauen1: the idea is to have that bootable SD card that installs itself to SPI flash, for that you need SPL MMC & SPI support
<bauen1>
oh i see
<apritzel>
it's OK to play around with those changes for your experiments, but it would be better to find a better solution
<bauen1>
apritzel: this spl won't ever see other users apart from me
<apritzel>
bauen1: the error message you posted looks more like the boot source selection somehow fails
<apritzel>
bauen1: famous last words ... ;-)
<apritzel>
bauen1: but it would be good to fix this anyway
<bauen1>
apritzel: hehe yes
<apritzel>
bauen1: did you *need* to bring down the SPL size
<apritzel>
because technically the H6 doesn't have the 32KB limit, even with NBROM
<apritzel>
but the U-Boot build system still believes so, I think
<bauen1>
apritzel: not yet, i know i even have a very messy patch somewhere that tells u-boot about the better 64kb limit
<apritzel>
bauen1: but the actual limit is much later, isn't it? I measured 144KB for the H6 (NBROM eGON)
<bauen1>
apritzel: where did you start to load ?
<apritzel>
beginning of SRAM, where eGON puts us into. I had some code there, then a large pattern, that the code verified
<bauen1>
apritzel: it does look like it's failing to actually select the sunxi spi boot method for some weird reason, let me figure out why
ftg has joined #linux-sunxi
<apritzel>
yeah, that was my thought as well
<apritzel>
does it work with SPL_MMC enabled?
<bauen1>
apritzel: yes, that is the only config i have toggled off to make it stop working
<apritzel>
I see
<bauen1>
sunxi_get_boot_source does return 3, for SUNXI_BOOTED_FROM_SPI, so that's working correctly
<apritzel>
that's good info
<apritzel>
I think DEBUG in common/spl/spl.c would reveal more
<bauen1>
so i think that spl_spi_load_image is returning -22
<bauen1>
returned from spl_parse_image_header
<bauen1>
oh this is weird
<bauen1>
when running with SPL_MMC=y then it will print `Found FIT image`, but that is only done in arch/arm/mach-sunxi/spl_spi_sunxi.c but is in the other side of a IS_ENABLED if than without it
<bauen1>
so SPL_MMC=n either somehow affects `IS_ENABLED(CONFIG_SPL_LOAD_FIT)`, it shouldn't or it makes `image_get_magic(header) == FDT_MAGIC` no longer true, so maybe a bad read
<apritzel>
the SPL is weird in places, so there could be side effects with stuff like malloc() or BSS usage
<bauen1>
apritzel: true, and i've not ruled out the most fun contender: a heisenbug due to memory corruption somewhere \o/
<bauen1>
so `image_get_magic(header) == FDT_MAGIC` is false when setting SPL_MMC=n, so that's a failed read then
<bauen1>
and if i'd have to guess it's some clock setup that doesn't get done
<apritzel>
ha, exactly my thought 5 seconds ago
<apritzel>
or it is actually something with that pinmux conflict ...
<apritzel>
bauen1: does it help to set CONFIG_MMC_SUNXI_SLOT_EXTRA to -1?
landnode has quit [Ping timeout: 480 seconds]
<bauen1>
apritzel: no, that doesn't seem to do anything
<apritzel>
I don't think the sunxi code cares too much about CONFIG_SPL_MMC at all, so it must be something generic or a spooky side effect
macromorgan has quit [Quit: Leaving]
<bauen1>
let me try if SUNXI_SLOT_EXTRA = -1 and SPL_MMC=y still boots
<bauen1>
that would skip some init code for the mmc1, but still init mmc0
<bauen1>
no, still boots
<bauen1>
i can literally not find any code from the mmc that should be called before the sunxi spi driver is asked to load the FIT ...
<smaeul>
how are you disabling SPL_MMC? in .config or in defconfig?
apritzel has quit [Quit: Leaving]
<bauen1>
smaeul: defconfig
<bauen1>
but i'm comparing the full .config to a known-good .config and the only difference is the toc0 changes (those work) and the SPL_MMC=n
apritzel has joined #linux-sunxi
<smaeul>
hmm ok
<smaeul>
bauen1: look to see if the FIT image is actually at the offset where SPL expects it to be
<smaeul>
some offsets may have changed due to the SPL binary being smaller than previously
<bauen1>
yes that is, "unless SPL is larger than 32 KiB", it's now 24kb
<bauen1>
so the "load_offset" calculation does a max on the sbrom reported size and CONFIG_SYS_SPI_U_BOOT_OFFS ; and the FIT image is now at 0x6000 not 0x8000 ; so it will wrongly look at 0x8000
<smaeul>
yes, that, or you could say the FIT image is wrongly at 0x6000 ;-)
<bauen1>
smaeul: yeah, i'm not really sure which is right, i mean i think there is no offset property in the dtsi for binman
sunshavi has joined #linux-sunxi
<bauen1>
so i've added the offset tag for now, and things work :)
<apritzel>
bauen1: the rule is: at 32KB, or later, if needed
<smaeul>
what's right is mostly just convention, and so far the convention was that U-Boot was at SPL+32k, even for SoCs like A10, where max SPL size is 24k
<smaeul>
the offset property was never needed for arm64 because nobody ever made an SPL smaller than that :)
<smaeul>
what I'm hearing now is that if we can convince board makers to include SPI flash, we have plenty of space to enable SPL_DM and SPL_OF_CONTROL ;->
<bauen1>
smaeul: you can basically put u-boot on there and have a mostly working UEFI "BIOS"
<bauen1>
smaeul: or make u-boot smaller and skip the SPL ;)
<apritzel>
bauen1: why is your SPL so big in the first place? Is it just by a bit because of the TOC0 overhead?
Pinchiukas has joined #linux-sunxi
<Pinchiukas>
Sorry to be off-topic but maybe there is some image that I could burn onto an Amlogic s905 so that it would boot? Looks like I managed to toast the UART of the board. :(
<bauen1>
apritzel: i think the toc0 adds another 4kb
<apritzel>
Pinchiukas: try some Armbian image?
<Pinchiukas>
apritzel: so I just find one that's also Amlogic based and use that?