<apritzel>
PC0-PC2 are connected to the NAND, and PC3 is not connected at all (which is probably a show stopper for any hacks with tapping into the NAND pins)
<veremitz>
SPI elsewhere?
<apritzel>
doesn't help, the BootROM only uses SPI0 on PortC
<veremitz>
oh dangit right
* veremitz
back to SPI on opi0+
<apritzel>
veremitz: ah, I should delete that file ;-)
<veremitz>
LUL
<apritzel>
I think this is for the SLC support on the CHIP Pro
<veremitz>
is that sunxi too?
<veremitz>
I guess it could be .. ahem . hacked
<apritzel>
but it speaks of working NAND support in U-Boot proper
<veremitz>
that's what I'm reading ..
<apritzel>
what do you mean with "is that sunxi too"?
<veremitz>
. . whilst hunting config scripts
<veremitz>
is the Chip Pro another sunxi cpu?
<veremitz>
oh lok I've found its defconfig .. :P
<veremitz>
CONFIG_ARCH_SUNX answers my question
<veremitz>
CONFIG_MTD=y
<veremitz>
CONFIG_MTD_RAW_NAND=y
<veremitz>
CONFIG_SYS_MAX_NAND_DEVICE=8
<veremitz>
interesting
wasutton3 has quit []
<apritzel>
the CHIP Pro is a development board with the A13 and SLC NAND flash
<apritzel>
and as mentioned before, that's the only one supported, though I am not sure if anyone has tested this in recent years
<veremitz>
ah so.. theoretically I can port that to the A13-OlinuXino with NAND ..
<veremitz>
Theoretically LOL
<apritzel>
... if you bridge the huge gaps that MLC vs. SLC create
<veremitz>
bleh ok ok
<apritzel>
but to pull off this "we just want to load U-Boot from NAND" stunt, you can practically use any board with NAND flash
<veremitz>
right...
<apritzel>
not sure how useful this is when you don't have SATA and thus the only useful mass storage are SD cards anyway ...
<veremitz>
for my use case .. failed uSD card .. :D
<veremitz>
for my friend .. SATA ..
<veremitz>
like you say .. you just gotta fire the right code to access the right device .. which -should- be trivial once you got it loading .. LOL
<apritzel>
failed SD card? then just use a new one? And while it might look cool to be able to boot U-Boot regardless, with a failed SD card you cannot proceed much further, except maybe by with PXE and NFS root
<veremitz>
it just means you get Something on the UART :P
<apritzel>
yeah, well, low expectations always help ;-)
<veremitz>
its not Very useful, no .. but it might assist a n00b in assessing what went wrong
<veremitz>
"connect this lead, restart/replug the device, what shows up?"
<apritzel>
if a noob is able to flash something to the NAND flash: my respects ;-)
<veremitz>
haha well yes..
<apritzel>
I mean normally it goes like: download this image file, "dd" it to an SD card and off you go
<veremitz>
so... this SPI config for uboot on the opi-0+ .. :P
<veremitz>
yes yes, I been doing this a few years now myself :P
<veremitz>
its just uboot config, no extra code?
<veremitz>
olook.. I see sensible stuff on the opi-0 (no-plus)...
<apritzel>
yes, the key is CONFIG_SPL_SPI_SUNXI=y, check for other defconfig files that do that, and then send a patch
<veremitz>
CONFIG_SPI_FLASH_xxx too?
<apritzel>
we recently used that on the Orange Pi Zero 3, and it works like a charm there
<apritzel>
yes
<veremitz>
do I need the CONFIG_SPI and _SPL=y too?
<veremitz>
dangit I should spin these up ..
wasutton3 has joined #linux-sunxi
<apritzel>
you should, but similar story like what we discussed above: for just loading U-Boot proper, you would only need CONFIG_SPL_SPI_SUNXI
<veremitz>
ahh yes gotcha..
<apritzel>
that is where I am coming from: the amount of code to get this working in just the SPL is much less
<veremitz>
oh of course, yes.. getting SP's mixed up
<veremitz>
yeah uboot doesn't need to see SPI
<apritzel>
it's easy to do, just add CONFIG_SPI=y and select the flash chip manufacturer, and the rest works fine
<veremitz>
it /should/ see the SATA/MMC/etc
<apritzel>
which gives you the ability to write to the SPI flash from U-Boot (to update the firmware, for instance), or to save the environment there
<apritzel>
plus to be able to load small payloads, like grub, or a tiny rescue system
<veremitz>
nod.. can't do much in 2Mb though (on the opi0+)
<veremitz>
or even 2MB
<apritzel>
ah, it's only 2MB, then yes it's a bit small
<veremitz>
ah grub loads kernel so..
<veremitz>
I had this perverted idea to get an rpi to load uboot to load grub XD
<veremitz>
I screwd it up one day when I tried to naively update grub from linux LOL
<apritzel>
what's perverted about it, I consider this a very important boot flow
<apritzel>
because it ties in with what distros set up
<veremitz>
yes I respectd a great deal the work the opensuse guy did for uboot
<veremitz>
there's a small gotcha getting TF-A working, but its very doable
<veremitz>
slightly easier than uboot on NAND XD
<apritzel>
TF-A? why? what's the problem?
<veremitz>
err arm8 cores need tfa? I believe..
<apritzel>
and?
<apritzel>
it supported in mainline TF-A for years now
<veremitz>
well there is't a problem .. just home-brewing it isn't entirely trivial :D
<veremitz>
because of that dumb rpi gpu rom...
<veremitz>
I should revisit it actually
<veremitz>
ENOTIME though
<apritzel>
have a good one, and happy to assist you with TF-A and U-Boot and grub, be it on sunxi or RPi4's, actually ;-)
<veremitz>
I need to finish getting gpioleds sorted for the opi0+
<veremitz>
ahem .. gpios as sys/class/leds ..
<veremitz>
I think I was 3/4 of the way
<veremitz>
its all device-tree magic
<veremitz>
oh yeah .. I was messing with it on my pine64 .. but the wifi is a bit dodgy on that here for some reason ..
<veremitz>
now my guest has left I can dangle an ethernet cord back there...
<apritzel>
LEDs controlled by GPIOs, you mean?
<veremitz>
yes, and also .. through the sysfs led class sstuff /driver
<apritzel>
that would be automatic
<veremitz>
so I can assign them eg. heartbeat or ethernet stuff
<apritzel>
you just need one DT node
<veremitz>
yup.. I think..
<apritzel>
there are two defined already in the mainline .dts (for the OPi0+)
<veremitz>
you need the -right- DT node ;D
<veremitz>
oof mainline kernel?
<apritzel>
sure, check sun50i-h616-orangepi-zero.dtsi for the most up-to-date properties
<apritzel>
(label is deprecated and won't be accepted anymore for new DTs)
<apritzel>
those GPIO LEDs are actually the most satisfying DT additions, since you can actually see something very easily, you just need to know the pin and polarity
<veremitz>
yup yup
<veremitz>
ah now .. hrm .. something is using some pins for input
<veremitz>
I don't think I've copied the DT over yet ..
<veremitz>
gah let me find a cable damnit .. lol ..
juri_ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
juri__ has quit [Ping timeout: 480 seconds]
norton has quit [Ping timeout: 480 seconds]
<veremitz>
now the sodding thing won't come up on ethernet either..
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
<veremitz>
not really in the mood for troubleshooting networking at 1am LOL
KREYREN_ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
tlwoerner__ has quit [Read error: Connection reset by peer]
tlwoerner_ has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
KREYREN_ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
KREYREN__ has quit [Remote host closed the connection]