<Jookia>
Ok, I'm geting close to the end of my SPI NAND journey. Will it be acceptable for me to dump notes on the sunxi wiki and links to kernel+uboot+configs and stuff?
<Jookia>
I have knowledge and pain I need to dump
<apritzel>
Jookia: definitely
<Jookia>
yay :)
sunshavi_ has quit [Remote host closed the connection]
<apritzel>
I don't see any page related to SPI NAND yet, so it's all yours to create one
<Jookia>
i also found something a little interesting
<Jookia>
i will mention this of course, but the SPI NAND boot source checks multiple offsets (this is already documented)
<Jookia>
but the boot source register sets its high nibble based on which NAND block it loaded from
<apritzel>
that's a good find!
<apritzel>
we have something similar for MMC boot sources: the BROM checks 8K and 128K, and also sets the high nibble accordingly
juri__ has quit [Ping timeout: 480 seconds]
<apritzel>
though I think SPI NOR only loads from the beginning
<apritzel>
I once sprayed eGON headers over the first few MBs, and none of them triggered
juri__ has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]
juri_ has joined #linux-sunxi
juri__ has quit [Ping timeout: 480 seconds]
juri_ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
juri__ has quit [Ping timeout: 480 seconds]
<Jookia>
smart way of detection :D
juri__ has joined #linux-sunxi
<Jookia>
so u-boot needs filter out the high nibble for boot sources?
juri_ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
juri__ has quit [Ping timeout: 480 seconds]
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
<apritzel>
yes, though we might need to use the offset information, to calculate the offset of the SPL payload (FIT iamge)
<Jookia>
hopefully next week i'll get my code somewhat polished and put up
<Jookia>
i am very happy to have gotten UBI working for everything except the SPL on this board
juri_ has joined #linux-sunxi
juri___ has joined #linux-sunxi
juri__ has quit [Ping timeout: 480 seconds]
juri_ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
juri___ has quit [Ping timeout: 480 seconds]
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
juri__ has quit [Ping timeout: 480 seconds]
<Jookia>
just as a question: how do people handle sharing the same u-boot and kernel with multiple boot devices? ie nand and mmc. do they just use a script to check the boot device and set bootargs based on that?
juri_ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
juri__ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
juri_ has quit [Read error: Connection reset by peer]
<apritzel>
well, you always have a DTB, and you should put in into U-Boot
<apritzel>
that's what fdtcontroladdr does
<apritzel>
that's the address where U-Boot holds its own DTB, and there is no reason the one for the kernel should be different
<apritzel>
machinehum: if you have recent U-Boot, then the one in the kernel tree and the one in the U-Boot tree are identical
<apritzel>
yeah, no output with earlycon often means something wrong with the DTB
<machinehum>
Gotcha
<apritzel>
32-bit kernels support earlyprintk (with some extra parameters), which gives output a little earlier, but if the DTB if botched, that doesn't help you, as the command line is in the DTB...
<apritzel>
machinehum: also, where does the kernel come from? Is that your own config?
<machinehum>
buildroot, it's my own config
<apritzel>
yeah, now you have about a few hundred problems, all starting with CONFIG_ ;-)
<apritzel>
try multi_v5_defconfig, that should boot on an F1C200s
<apritzel>
if that gets too big, disable support for some platforms other than Allwinner (with make menuconfig)
<machinehum>
What baord is that for?
<machinehum>
I just realised I was specifying a custom dtc for uboot
<machinehum>
Whoops
<machinehum>
What's multi_v5_defconfig for?
<apritzel>
well, putting all of this into buildroot's hands doesn't make this easier ...
<apritzel>
to be clear, I am talking about kernel configs, not buildroot configs
<apritzel>
multi_v5_defconfig is a config that is known to run fine on multiple boards with ARMv5 cores
<apritzel>
dtc? that shouldn't matter. Or do you mean a dtb?
<machinehum>
I was using an old dtc I ripped from somewhere, didn't even look at it just wiped the line and used the mainline one
<machinehum>
Alright I'll give multi_v5_defconfig, and yeah, linux config
<apritzel>
last time I checked multi_v5_defconfig got a bit on the bigger side, so you might want to try to shrink this down, by using "make menuconfig", and deselecting some platforms under "System Type"
<machinehum>
Willdo
gsz has quit [Ping timeout: 480 seconds]
<apritzel>
it should be fine though, 6.7-rc1 is a bit shy of 7MB compressed, and extracts to a bit more than 11 MB
<machinehum>
hmm okay I'm in the same spot using multi_v5_defconfig and setenv fdt_high 0xffffffff