On Wed, 1 Jun 2016 14:54:24 +0200 Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> On Wed, 1 Jun 2016 14:41:36 +0300 > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > > > On Mon, 30 May 2016 19:02:13 +0200 > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > > > > > On Mon, 30 May 2016 19:46:17 +0300 > > > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > > > > > > > On Mon, 30 May 2016 17:24:16 +0200 > > > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > > > > > > > > > Hi Hans, > > > > > > > > > > On Mon, 30 May 2016 17:12:53 +0200 > > > > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > > > > > > > > > > > Generating raw NAND images is particularly useful for boot0 images > > > > > > creation since the mainline driver is not supporting the funky > > > > > > layout > > > > > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > > > > > > > > > This tools also allows one to generate raw images for 'normal' > > > > > > partitions > > > > > > so that they can be flashed before soldering on the NAND on the > > > > > > board > > > > > > (using a regular NAND programmer). > > > > > > > > > > > > The tool takes care of generating ECC bytes and randomizing data as > > > > > > expected by the NAND controller, and re-arranging the ECC/data > > > > > > sections > > > > > > correctly. > > > > > > > > > > Don't know how you want to proceed regarding NAND SPL image creation > > > > > in > > > > > u-boot. We could either copy the sunxi-nand-image-builder sources in > > > > > u-boot or provide a macro to pass the sunxi-tools binaries path > > > > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > > > > > installed on his build platform. > > > > > > > > > > Note that we'll need extra padding/concatenation steps to build an SPL > > > > > image suitable for MLC NANDs. > > > > > > > > Hi, > > > > > > > > I guess, it is not a big secret that I'm also working on the SPI flash > > > > boot support at the moment. And some information about the progress is > > > > available here: > > > > > > > > https://linux-sunxi.org/Bootable_SPI_flash > > > > > > > > IMHO one of the most important requirements is to ensure that the device > > > > can be always unbricked by the end users in a very simple way. That's > > > > why I have added the SPI flash programming feature to the sunxi-fel > > > > tool and it is available in a wip branch since about a week ago: > > > > > > > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip > > > > > > > > There is still some work left to do. For example, just having SPI > > > > flash read/write functionality (which already works btw) is not > > > > good enough because it is not sufficiently foolproof. There will > > > > be a dedicated high level "spiflash-program" commmand to flash > > > > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. > > > > We had discussed this a bit on the IRC earlier: > > > > > > > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; > > > > > > > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin > > > > image to automatically add some redundancy (two copies of the SPL): > > > > > > > > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations > > > > And also pass some information about the SPI flash type via the SPL > > > > header (for example, the single/dual SPI mode, the maximum SPI clock > > > > speed, etc.). So that the SPL can use this information directly > > > > without any need to have extra code bloat responsible for doing > > > > runtime discovery of all these parameters. > > > > > > > > But the most important foolproof feature would be of course a warning > > > > "You are trying to flash a firmware for an incompatible board, are > > > > you really sure?" :-) Later we can also have digital signatures > > > > verification built into the sunxi-fel, and other nice things. > > > > > > > > > > > > Boris, I think that your NAND use case is not very much different in > > > > principle. You can't expect the users to desolder the NAND chip and > > > > use an external NAND programmer tool when they need to unbrick their > > > > device, right? > > > > > > > > > > That's absolutely not the goal of this tool. It's just here to generate > > > raw NAND images. > > > > Ultimately we want to have a complete solution. So that the NAND flash > > can be programmed both at the production line and by the end users of > > the devices. How many more tools do we need to achieve this goal? > > Not sure what you mean by that. So you want a single sunxi-fel tool > able that would be able to do everything from flash media detection to > image preparation and flashing. A single tool or a set of tools, it does not matter. But in my opinion it has to be a complete package, which is sufficient to prepare a bootable NAND image. Also with a little bit of documentation about its usage. You have contributed a nice tool. But it only does a *part* of the job. If I understand it correctly, there are still some important pieces missing. Basically it look like we need to: 1) Get U-Boot sources 2) Do some manipulations (which are not documented yet) 3) Run the sunxi-nand-image-builder tool and then use the resulting output with a standalone NAND flash programmer at the factory to prepare NAND chips before soldering them on the PCB. I'm obviously very curious about the step 2. > That's a nice objective, but let's stay realist, this tool does not > exist yet, and I think you underestimate the amount of work needed to > correctly implement NAND flash detection. In other words, you have no plans to implement anything else beyond this basic sunxi-nand-image-builder tool? Fair enough. I just wanted to confirm your plans. > If we really are ready to do that at some point, then we'll still be > able to expose the nand-image-builder functionalities as a lib and link > the sunxi-fel tool with it. Yes, there is no need to worry about it prematurely. And it's a pretty simple thing anyway. > > > Now, if there's a way to export NAND memory organization through the > > > SPL header, that's even better, > > > > Currently the U-Boot build system produces the u-boot-sunxi-with-spl.bin > > file. This file consists of the SPL part in the beginning and the main > > U-Boot binary (in a legacy format now, but maybe moving to FIT later). > > > > The SPL part has the 64 byte header in the beginning (the size can be > > increased if necessary): > > > > > > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-sunxi/spl.h > > > > This SPL header can be interpreted as a blank form, which can be > > populated with the useful information by the other tools. What we > > have right now is that: > > * The boot ROM writes the type of the boot device at the offset 0x28 > > * The sunxi-fel tool writes the "fel_script_address" field when > > doing FEL boot over USB OTG and also overrides the header magic > > to indicate that we are booting from FEL. > > > > Nothing prevents the SPI flash or NAND flash image builders from using > > some parts of the SPL header too. The SPL header also has the format > > version field to ensure compatibility between future versions of U-Boot > > and future versions of external tools. > > Yep. I could store the NAND type in there and avoid the auto-detection > phase, or we could even store the u-boot and redundant u-boot offsets. The main question is still the same. Would you be willing to actually do this or not (some time in the future)? > > > > > but you'll still need this tool to generate the image, > > > > That's exactly what I'm saying. We have the "u-boot-sunxi-with-spl.bin" > > file as the input data. And modifying the SPL header or replicating > > some critical parts/adding ECC for redundancy purposes is the > > transformation that has to be done by the external tool. > > Well, actually it would be way simpler to just manipulate > u-boot-dtb.bin and sunxi-spl.bin instead of the concatenated version, > but I guess I can do the reverse transformation. Yes, it is easier for you when implementing the tool. But at the same time it is harder and more error prone for the users, who suddenly needs to deal with multiple files and pay attention not to mix them up. For example, dealing with a bunch of separate files and using a special U-Boot configuration used to be required for doing FEL boot. But not anymore. Because we did care about the convenience of the end users. > > BTW, your current tool is pretty much "dumb" and is not aware of the > > "u-boot-sunxi-with-spl.bin" data format. Presumably we still need some > > additional tools to go from "u-boot-sunxi-with-spl.bin" to something > > that can be programmed into NAND? > > Of course it doesn't know anything about the u-boot-sunxi-with-spl.bin > format, and that's actually good thing in my opinion. Everyone is surely entitled to have an opinion. > Designing something simple that is able to do a single piece of the > work and then having a higher-level tool (like the sunxi-fel flasher), > making use of several simple/dumb tools to do a achieve a more complex > thing is more future-proof in my opinion. Where are these extra tools? > > > and I think we should keep them separate. > > > > Not necessarily. It can be an image builder, or it can be a direct > > flash programmer (via FEL) which generates the image on the fly. The > > core functionality can be always implemented as a library and shared > > between the image builder and the flash programmer. > > As suggested above, we can do that. But let's wait until we really have > the sunxi-fel flasher ready for NAND devices before moving in this > direction. It is completely orthogonal. Instead of using the sunxi-fel flasher, you could generate and send the resulting NAND image to the factory. Again, what I'm saying is that sunxi-nand-image-builder alone is not enough. > > > > > The example I was giving was for people wanting to optimize their > > > production phase by pre-flashing the NANDs before soldering them. > > > > That's surely a valid use case. Please note that I did not raise any > > objections in the first place. > > > > > Of course you'll be able to re-flash an existing system, > > > > Naturally, this is the most interesting feature for the end users. > > I hope that you have something planned. > > It's already doable. Maybe not as user-friendly as you expect it to be, > but users can load and SPL and uboot binaries over FEL and then from > the SPL and UBI images from there (that's what we're using for the > CHIP). Are you exposing NAND via DFU in U-Boot? I have already experimented with DFU for uploading data into RAM and booting the system faster over FEL: http://git.denx.de/?p=u-boot.git;a=commit;h=2a909c5f7a4e645260e5d01313e15371a8c55eba This is beneficial for speed, but increases the number of moving parts and also requires USB OTG to be enabled in the board defconfig, which was not the case for many sunxi boards in the past. So the good old FEL data transfers are still the recommended method. I'm happy to hear that you already have a solution. Again, documenting the whole process would be very much welcome. People might want to try it already ;-) > > For example, if I understand it correctly, these are the best available > > instructions for the current NAND support code in U-Boot: > > > > http://lists.denx.de/pipermail/u-boot/2015-May/214959.html > > > > As you can see, the end users really have to jump through so many > > hops that it requires a huge investment of their time. > > Yes. As I said it's not user friendly yet, and sorry, but I don't have > time to work on the advanced solution you're describing. Other > contributors can do it though. > > > > > > but in this case, except for the boot0 partition, you won't need a raw > > > image, > > > because you're flashing the NAND with the sunxi NAND controller, and > > > it's able to generate the ECC bytes and scramble data appropriately. > > > > Can the NAND controller temporarily disable these features and still use > > the generated raw image for some sort of dumb flashing? > > Yes, that's actually how we flash the SPL/boot0 image: u-boot and Linux > provide raw access modes, and the sunxi NAND driver supports them. This is good to know. Definitely makes the job a lot easier. > > If yes, then this can reduce the software complexity via sharing the > > code between the factory flashing use case and the normal flashing > > done by the end users for upgrades/unbricking. > > Probably. > > > > > > I'll have a look at what you're currently working on, but I think this > > > patch is orthogonal to your sunxi-fel flasher. > > > > I strongly suspect that NAND flashing can be also done directly from the > > sunxi-fel tool. So that the sunxi-fel tool only talks to the boot ROM > > and has no other dependencies (neither the U-Boot bootloader nor the > > Linux kernel is really necessary). > > > > As already said above, I think you underestimate the amount of work to > achieve that. Yes it's doable, but I definitely won't be the one > investigating this option, Thanks for your opinion. Maybe I'll try to come up with my own estimate later. However I'm primarily interested in manipulating SPI flash and eMMC boot partitions at the moment, so NAND will have to wait. > cause I think it's not really useful. We > already have all the code we need in u-boot (that's not exactly true, > but should be in a few weeks) and Linux (this one is true), to detect > and flash NAND devices. What's the point in adding yet another baremetal > programmer that we likely do what u-boot and Linux do. The point is in having simplicity, reliability and full control. We can probe, read and write the SPI flash (hooked to SPI0 port C pins) on a wide range of Allwinner devices (anything with the A10/A13/A20/H3/A64 SoC so far). This way we can check if the SPI flash is available on-board, backup the data from it, maybe read the board id (the device tree name) from the existing firmware: http://lists.denx.de/pipermail/u-boot/2016-June/256723.html When flashing, we can protect the user from doing something stupid, such as picking a firmware image for a wrong device. Also as a nice bonus, keeping things simple allows us to get the job done much faster. There has been roughly one month since people showed interest in booting from SPI flash on Allwinner hardware (this includes the time spent on waiting for the SPI flash module to be actually delivered from ebay): https://marc.info/?l=linaro-cross-distro&m=146244888910381&w=3 And now we are mostly done with it. I still need to submit the final patches to sunxi-tools, but everything already works nicely. The read/write support directly in the sunxi-fel tool provides a nice safety net for the users. It is important to ensure that the devices are really *easily* unbrickable. And for comparison, if you rely on the DFU implementation in U-Boot, then you currently need a U-Boot binary which is compiled specifically for your board. This leads to a chicken/egg problem. You can't do the board identification automatically and need to hope that the user makes the right choice. If the users need to go through a complicated ritual to get their device unbricked, then you are definitely going to hear horror stories from the people who fail to do it right. -- Regards, Sierž -- 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. For more options, visit https://groups.google.com/d/optout.
