Hi, On Sat, Jul 24, 2021 at 06:04:32PM +0100, Andre Przywara wrote: > On Sat, 24 Jul 2021 18:27:53 +0200 > Petr Vorel <petr.vo...@gmail.com> wrote: > > Hi Petr, > > > [ Dropping Greg and linux-...@vger.kernel.org ] > > > Peter, > > > > > On Sat, 24 Jul 2021 at 15:22, Petr Vorel <petr.vo...@gmail.com> wrote: > > > > > > Hi Greg, > > > > > > > On Sat, Jul 24, 2021 at 03:41:42PM +0200, Petr Vorel wrote: > > > > > > > Why is this even a driver at all, it looks like you can write a > > > > > > > small > > > > > > > userspace program using libusb to do everything it does, right? > > > > > > > What > > > > > > > exactly is this driver needed for? > > > > > > > > I'm sorry for not providing more info at the beginning. This is a > > > > > > driver for > > > > > > host computer (i.e. developers laptop) used by LiveSuit tool [2] to > > > > > > flash Images > > > > > > to the NAND of Allwinner devices. LiveSuit itself [3] is > > > > > > unfortunately provided > > > > > > only in binary form. The only open source code with GPL v2 license > > > > > > is awusb > > > > > > driver. Thus I thought I could ease my life with upstreaming at > > > > > > least the > > > > > > kernel driver. But maybe it's not a good idea. I'm using LiveSuit > > > > > > for flashing > > > > > > Allwinner A31, but it requires quite old distro due libqtgui4. > > > > > > Maybe sunxi folks > > > > > > use something newer nowadays, but I haven't found anything in their > > > > > > wiki. > > > > > > > Ah, that's not going to be good then. Really, this doesn't seem to > > > > > need > > > > > to be a driver at all, and the ioctls are really strange so we would > > > > > need to change them anyway before it could be merged. But with no > > > > > access to userspace code, that will be quite difficult, so I would > > > > > push > > > > > back on allwinner and have them work on resolving this. > > > > Understand, it makes sense. Thanks for your time! > > > > > > @Sunxi community: am I missing something? Using LiveSuit with old > > > > distro chroot > > > > and Xephyr with out-of-tree module isn't fun :(. > > > > > Suggest you take a look at sunxi-tools - specifically the sunxi-fel > > > tool. This is a libusb-based userland tool to talk to these devices. > > > I'm not sure if it supports flashing to nand on A31 - never tried it - > > > but have used it to flash to eMMC and SPI flash on their other chips. > > Thanks for a tip. Looking into sources it does not look like sunxi-fel > > supports > > NAND. > > > > Also from Debian wiki [1] (which describes bootable SD Card) it looks like > > only > > old Allwinner u-boot supported access to NAND, thus I'd be surprised if > > sunxi-tools supported it. sunxi-bootinfo does not implement NAND, > > sunxi-nand-image-builder (which is not built by default) creates raw NAND > > images, but now word about flashing. > > > > I wonder why NAND is (probably) not supported by sunxi? Lack of > > documentation? > > Pure NAND is getting rarer these days, on modern boards we see mostly > eMMC now (maybe SPI NAND). So NAND is only a concern for older SoCs. > > There is (limited) NAND support for mainline U-Boot on the C.H.I.P. > boards[1], which use an A13 (derivative). But reliable operation is > only possible with SLC NAND, which means only on the Chip Pro board, > IIUC. Most boards will probably utilise MLC (or worse) NAND these days, > where effects like write and read disturb make operation more > complicated. Maxime has some stories to tell about this. > So it would be first good to know if you have SLC NAND or not. > > Because of this direct support for NAND in the tools is understandably > "limited" (as in: non-existent). Except for SPI NOR flash there is no > "direct" flashing support (for eMMC) in the tools anyway, it just relies > on U-Boot support. > How this works is that you use sunxi-fel to upload a (mainline) U-Boot > binary directly into DRAM, and launch that. Then you can use the full > functionality of U-Boot to load your image. Most popular for NAND > support seems to be U-Boot's Android Fastboot implementation over a USB > gadget device, so you can use the off-the-shelf fastboot tool on your > host computer to flash the NAND. Other possibilities would be to use > USB host support or TFTP to first load an image into DRAM, then use > U-Boot commands to write that into the NAND flash. > > To my knowledge NAND flash in U-Boot *only* works on the A13/R8/GR8 > chips with SLC NAND, and is only enabled and tested on the Chip boards. > Every other combination would require some work; much more work the > farther you move from there (other SoC, MLC, ...).
It works on the A33 as well (the Nintendo board has support for it). And I guess it works with virtually any SoC, the culprit really is MLC vs SLC, the NAND controller hasn't really changed. Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210728141644.xgcldm2vyjbembyw%40gilmour.
signature.asc
Description: PGP signature
