ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
juri__ has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
vagrantc has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
apritzel has quit [Quit: Leaving]
macromorgan has quit [Quit: Leaving]
<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
<norton> But I don't see configs directory there, and in boards.cfg there is only sun4i and sun5i. So how do I compile it?
<norton> Sorry, I forgot to link the U-boot git repository. Here it is: https://github.com/linux-sunxi/u-boot-sunxi/tree/lichee-dev
<veremitz> I sense a lot of that stuff has simply been .. forgotten about ..
<veremitz> although I've wondered about putting uboot into on-board storage elsewhere recently too ..
<veremitz> and for some weird reason I ended up in #mtd ..
<veremitz> possibly to do with on-board flash
<apritzel> norton: there is no good support story for raw MLC NAND flash in mainline branches in U-Boot
<apritzel> and those linux-sunxi repos are horribly outdated
<norton> so what do I do? I want to boot my board without SD card, just SATA. As I understand, it's not possible to install U-Boot to the SATA drive
<norton> apritzel: outdated or not, I don't really care, as long as it boots up my Mainline system.
<apritzel> ... which is probably a problem
<apritzel> you might be able to chainload mainline U-Boot from SATA
<apritzel> there is some raw SLC flash support in mainline U-Boot
<norton> I don't understand
<norton> can you point me to the links so I can read up on how to do it?
<veremitz> that sounds a bit scary..
<apritzel> which part is scary? The chainloading should not be, it would just be custom script
<apritzel> but I don't know if the old U-Boot even supports SATA
kuba2k2 has quit []
<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?
<veremitz> also https://groups.google.com/g/linux-sunxi/c/zKrT_wWFUkE/m/ujtPQ54AExQJ .. but there's quite a bit to piece together
<veremitz> the first post is recentish though
<apritzel> all it seems pretty awfully hacked up, though
<apritzel> if we have some NAND capable SPL, that might be enough to plant some mainline U-Boot proper into that
<veremitz> yes well it would be ..
<veremitz> ^ git repo might need forward-porting perhaps idk
<veremitz> 2017/8 probably better than lychee?
<apritzel> still a looong way, but if it's just the SPL that needs to read from raw NAND, that might be doable in a reasonably clean fashion
<veremitz> https://github.com/moddevices/u-boot-sunxi-mainline/tree/wills/v2020.01-rc4%2Ba20_200116b/drivers/ata has SATA .. and looks like mtd has been .. 'fixed' .. lol..
<veremitz> I think its ROM->spl->uboot no?
<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 ..
<norton> what do :-(
<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
<veremitz> apritzel: something like https://www.adafruit.com/product/5643 should work?
<veremitz> ah, I'll look into PR#ng that then :eyeroll:
<veremitz> 16MB is a nice size :D