From: Maxime Ripard <maxime@cerno.tech>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Petr Vorel <petr.vorel@gmail.com>,
Christopher Obbard <chris@64studio.com>,
linux-sunxi@lists.linux.dev,
mailing list linux-sunxi <linux-sunxi@googlegroups.com>
Subject: Re: [linux-sunxi] Re: Mainlining Linux Sunxi SoC AW USB
Date: Wed, 28 Jul 2021 16:16:44 +0200 [thread overview]
Message-ID: <20210728141644.xgcldm2vyjbembyw@gilmour> (raw)
In-Reply-To: <20210724180432.4423b9e3@slackpad.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 4789 bytes --]
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.vorel@gmail.com> wrote:
>
> Hi Petr,
>
> > [ Dropping Greg and linux-usb@vger.kernel.org ]
> > > Peter,
> >
> > > On Sat, 24 Jul 2021 at 15:22, Petr Vorel <petr.vorel@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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2021-07-28 14:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-24 9:54 Mainlining Linux Sunxi SoC AW USB Petr Vorel
2021-07-24 10:29 ` Greg KH
2021-07-24 13:41 ` Petr Vorel
2021-07-24 14:17 ` Greg KH
2021-07-24 14:22 ` Petr Vorel
2021-07-24 14:45 ` [linux-sunxi] " Christopher Obbard
2021-07-24 16:27 ` Petr Vorel
2021-07-24 17:04 ` Andre Przywara
2021-07-25 23:31 ` Petr Vorel
2021-07-28 14:16 ` Maxime Ripard [this message]
2021-07-24 14:54 ` Jernej Škrabec
2021-07-24 16:46 ` Petr Vorel
2021-07-24 14:49 ` Felipe Balbi
2021-07-24 16:34 ` Petr Vorel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210728141644.xgcldm2vyjbembyw@gilmour \
--to=maxime@cerno.tech \
--cc=andre.przywara@arm.com \
--cc=chris@64studio.com \
--cc=linux-sunxi@googlegroups.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=petr.vorel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.