<Jookia>
Is linux-next hanging on boot for anyone else?
<Jookia>
it seems like maybe USB gadget is hanging in the kernel
macromorgan has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
chewitt has joined #linux-sunxi
<Jookia>
Seems like usb ethernet gadget now hangs the 'ip' command actually
<Jookia>
nope, it just hangs as soon as it turns on
Halamix2 has quit [Quit: Gone (and/or ZNC is doing something stupid)]
Halamix2 has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
<Jookia>
A long bisect later, found the issue commit. Time to revert and email the author :(
<Jookia>
Oh, they've already submitted a revert :)
tlwoerner_ has joined #linux-sunxi
tlwoerner has quit [Read error: Connection reset by peer]
<Jookia>
Allright, after spend time moving to mainline Linux with u-boot and friends, I now hit an LCD 5 seconds after power on instead of 35 seconds
<Jookia>
Not sure where those 35 seconds went. I didn't even mean to optimize anything
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
pg12 has quit [Remote host closed the connection]
pg12 has joined #linux-sunxi
warpme has joined #linux-sunxi
tlwoerner__ has joined #linux-sunxi
tlwoerner_ has quit [Read error: Connection reset by peer]
KREYREN_oftc has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest9845
dsimic has joined #linux-sunxi
Guest9845 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
gsz has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
ftg has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has quit []
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
kuba2k2 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
<Jookia>
I found a very good criticism of BASIC that's made me think a bit about language design
<Jookia>
BASIC is good at numbers and has no data structures, so almost all the BASIC examples use numbers
<Jookia>
Bash doesn't really have data structures either
<Jookia>
But it has good support for strings, which is what most people and command line things use
<Jookia>
C makes it painful to use data structures or do string operations because you have to track memory use
<Jookia>
Oops, wrong chat
<Jookia>
Sorry everyone :)
warpme has quit []
warpme has joined #linux-sunxi
Boris has joined #linux-sunxi
Boris has quit []
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
junari has quit [Remote host closed the connection]
kuba2k2 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit []
KREYREN_oftc has joined #linux-sunxi
JohnDoe_71Rus has quit []
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
kuba2k2 has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
kuba2k2 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
vagrantc has joined #linux-sunxi
vagrantc has quit []
warpme has quit []
warpme has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
apritzel has joined #linux-sunxi
vagrantc has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
warpme has quit []
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
norton has joined #linux-sunxi
<norton>
Hello guys
<norton>
My device is A20 OLinuXino Micro with 4 GB NAND flash memory. Allwinner A20 SOC, sun7i. My Linux filesystem is on SATA SSD and U-boot currently is on SD card. I want to move U-boot to the NAND flash memory. According to this article I need to compile U-boot from lichee-dev branch
<apritzel>
I don't know what it takes to support MLC flash loading in U-Boot, maybe someone could do some research? IIUC there is some limited support in Linux?
<apritzel>
maybe those old U-Boot branches contain enough information to do a proper port?
<apritzel>
I think many people want to load kernels from flash, and probably use it for a rootfs, which is then a different story
<veremitz>
hmm, how so?
<apritzel>
the SPL loading routines are separate and somewhat hacked up already, also have a very limited scope
<veremitz>
I'm trying to remember which of my boards have A20 on them ..
KREYREN_ has quit [Remote host closed the connection]
<veremitz>
I definitely have an A20linuXino ..
<apritzel>
the Cubieboards have NAND flash
<veremitz>
so I'm seeing ..
KREYREN_ has joined #linux-sunxi
<apritzel>
if all you need the flash for is loading U-Boot, we can make some simplifications
<veremitz>
mhmm
<apritzel>
for instance avoid MLC read disturbance by spreading out the payload
<apritzel>
and we can use whatever error correction seems easiest
<apritzel>
I am not a raw NAND expert (I actually just hate it), but IIUC those are two of the more prominent problems that prevent easy MLC support
<veremitz>
there must be devices booting uboot from nand/flash though out there?
<veremitz>
or do they cheat and use some other method
<apritzel>
two more problems to solve would be: how do we mangle the SPL to be accepted by the BROM (I think it expects a certain pattern? there is nand-image-builder.c in sunxi-tools.git)
<veremitz>
yeah there's a fudge involving android addresses/ids...
<apritzel>
AFAIK there is only mainline support for the SLC flash used on the C.H.I.P. Pro board
<apritzel>
the other problem is how to actually write the SPL+payload to the NAND
<apritzel>
if anyone could look into this, document this properly and upstreams support for this (limited to SPL only), I am pretty sure a lot of people would be eternally grateful
<veremitz>
sun-7i doesn't need TFA does it..
<veremitz>
think that kicked in for 8+
<apritzel>
no, and the actual U-Boot proper contains everything, so all you need is something that loads that to 0x4a000000 and kicks it off
<veremitz>
sounds doable theoretically at least..
<apritzel>
indeed, and it would be a good start to convince one of the existing SPLs to just load a mainline U-Boot proper payload
<apritzel>
existing SPLs as in: one of those ancient and potentially hacked up branches
<apritzel>
U-Boot was very different about a decade back, so forward porting anything in an upstreamable manner (which is the only reasonable and acceptable way!) is quite difficult
<veremitz>
yeah I could understand that
<apritzel>
but if it's just for the SPL, that much less of a problem, since the SPL loading part is quite separate and somewhat self-contained
<apritzel>
for instance we do most of the SPI NOR flash loading in one separate file, and there are efforts underway to support SPI NAND in a similar manner
<veremitz>
makes sense
<veremitz>
NOr that was the other tech I was thinking of..
<apritzel>
modern boards either have SPI NOR flash or eMMC boot partitions, which are both quite well supported
<veremitz>
yes it was obvious when devices switched to emmc .. which makes a lot of sense since its 'compatible' with ordinary mmc/uSD/etc
<apritzel>
indeed, and it hides the hideous part of MLC NAND flash in the eMMC controller
<veremitz>
presumably thats easier done in dedicated silicon..
<apritzel>
IIUC it's actually firmware running on a controller inside the eMMC chip
<veremitz>
gotcha
<apritzel>
doing this reliably and fast seems to be actual rocket science, that's why there is both little documentation and also little code out there to copy from
<veremitz>
this thread is [kinda] interesting too. Perhaps I need to dig into the uboot SPL code though ..
<apritzel>
NAND flash support pops up every few weeks or months here, and it's always a PITA, and most of the time people run away screaming, in my impression
<apritzel>
there is raw NAND flash support for SLC flash in mainline, see CHIP_pro_defconfig and drivers/mtd/nand/raw/sunxi_nand_spl.c
<apritzel>
norton: the short answer is: there is no easy and certainly no clean way to do this right now
<norton>
I need this
<apritzel>
buy a board with SPI NOR or eMMC
<norton>
that's not a viable option
<apritzel>
or go to the vendor
<norton>
what is SLC flash?
<veremitz>
#olimex exists on Libera IRC
<norton>
yep and I joined it
<apritzel>
single level cell: one bit per flash cell
<norton>
apritzel: what do you want me to do?
<norton>
what is this "drivers/mtd..." things?
<norton>
I don't get it
<apritzel>
I don't know, I am just saying there is no easy to follow instruction to get this supported
<apritzel>
Olimex might have something, but this might not be recent, and I don't know how well this plays with mainline kernels (which work fine otherwise on those boards)
<apritzel>
the path is to the existing SLC flash support code in mainline U-Boot
<norton>
how do I use it?
<apritzel>
all modern devices use MLC flash (multi-level cell), because that is cheaper/more dense, but is horrible on the software support side
<apritzel>
again: there is no easy mainline way (which is what this channel is about, mostly), and you cannot use the SLC code, because the Olimex boards use MLC flash
<veremitz>
ok I'm getting a better understanding of the 'why not's now :D thanks apritzel
<norton>
okay, why not use "legacy" sunxi way?
<norton>
legacy U-boot with mainline linux, is it possible?
<apritzel>
I don't know for sure, but it's surely problematic
<apritzel>
and it's *legacy*, and every second invested into that is a waste of time - unless you extract information and knowledge to make proper mainline patches from that
wasutton3 has quit []
<apritzel>
norton: if you got this board in the hope you can use it *fully* with modern, mainline maintained code: I am sorry, but welcome to Allwinner ;-)
<apritzel>
there is a lot of features that work in mainline, including 3D graphics and video decoding, but MLC flash is not one of them
<norton>
wtf, 3d graphics and video decoding? I heard the other way around, that sunxi supports it but mainline does not
<apritzel>
there has been quite some progress on that front in the last years
<apritzel>
as we sketched above: for just loading U-Boot from NAND, to continue loading the rest from SATA, there might be reasonable way out, but it still involves quite some work
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
<norton>
yep that's what I want, what is the way?
wasutton3 has joined #linux-sunxi
<apritzel>
figure out how to avoid read disturbance, what error correction is needed, how the SPL needs to be formatted/packed to be accepted by the BROM, and how to write the image to the flash
<apritzel>
that involves research, and quite some experiments, the actual coding would then probably be the least of the problems
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
<apritzel>
norton: or you choose the path to the dark side, and explore what other people hack^Wcame up with in the 2022 email thread that veremitz dug out...
<norton>
i'm currently doing `nandinstall` from very old 3.4 kernel image from Olimage
<norton>
that should write u-boot to the nand
<norton>
also it would write debian system too, but I don't care
<apritzel>
yes, but that's probably an ancient U-Boot as well, and from what veremitz checked above, this doesn't support SATA
wasutton3 has quit []
<apritzel>
you could still compile a mainline U-Boot image, and chainload the resulting u-boot-dtb.bin from that old U-Boot, by somehow getting it onto the flash, loading it to 0x4a000000 and executing it (go 0x4a000000)
wasutton3 has joined #linux-sunxi
<veremitz>
I've found my older ARM boards .. the oliniuXino is actually an A13 .. the A20 is my banana-pi :D
<veremitz>
I do have an uSD in the A13 .. but I had it booting from NAND ..
<veremitz>
so theoretically(!!) I could do as apritzel suggests, get an old uBoot SPL in, old uboot -> new-uboot-> somethng else
<veremitz>
did the bpi have NOR on it? *looks* ..
<apritzel>
A13 has no SATA, but I think NAND wise this should be the same, so would be good enough for development and experiments
<apritzel>
the original BananaPi (M1) has no onboard storage
<veremitz>
yup just the SATA port
<veremitz>
which was crippled iirc
<apritzel>
I am not sure if you can connect a bootable SPI NOR flash chip to the header pins, I used that on other boards (Pine64) with success
<veremitz>
hmm.. like?
<apritzel>
the SATA port is not the fastest implementation, but IIRC you can get > 120MB/s out of it, which is not bad
<veremitz>
tangentially .. SPI flash for uboot .. doable? (on an opi-zero-plus)
<veremitz>
I don't think 2MB gives space for a kernel, certainly not initramfs
<apritzel>
SPI NOR flash is well supported in U-Boot
<veremitz>
so the H5 should jump and run OK/
<apritzel>
it's indeed mostly meant for firmware (U-Boot), you then load the kernel from a proper mass storage, like SD card, eMMC, USB, NFS, ...
<veremitz>
yup
<apritzel>
OPi Zero Plus should work with SPI flash, though no one bothered to send the few lines for the U-Boot defconfig it takes to activate that