September 28, 2020, 02:59:34 am


Have you visited the Allwinner Chipset wiki? -

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - tilator

Quote from: phelum on April 20, 2018, 07:02:01 am
So I'd say you've probably got the best setup at the moment.

Best is a bit strong word, but it definitely fulfills my needs right now.
Quote from: phelum on April 12, 2018, 04:24:49 pm
Please check 'lsblk' in your 4.7 kernel and tell me what it detects.


I don't have it installed any more, but maybe you should use the same version I did. It's here:

It seems to be vestion 4.9 even though name would suggest 4.7.

In my present installation kernel version is 4.14.7-sunxi. Only U-Boot is on NAND. Kernel having initramfs and modules are all loaded from SATA. My goal was to get rid of SD-card and this does it.

However kernel version 4.9 did show NAND but the present 4.14.7-sunxi does not.

If you want the exact source code I used to make this U-Boot and 4.9 kernel, just give me some email address to send them. I have FTP server here, but it would be extremely slow.
Quote from: tilator on April 09, 2018, 05:43:19 am
Any suggestions what to do next to get it booting the whole way up?

OK. Needed second eyes again to make it work. My son has so much younger eyes ;)

I did not have .next file in /boot folder. It did try to boot old kernel. This prevented it coming up.

Now I have U-Boot and U-Boot environment in NAND, but everything else in SATA-disk. It boots without MMC-card as I wanted it to be.

Still there is not a way to use NAND as boot device for the whole system, but this should be possible by just flashing kernel in raw mode in NAND and loading it with UBI drivers from there. Then the rest of the userspace could be put in UBI.

B.T.W I did put SPL and U-boot in first erase block and environment in second just to be able to erase them separately.

The above attachment having U-Boot config has at least one error. Nand setting block size has to be added one more zero. Even with this corrected I did not manage it to work. There has to be something weird in scrambling bits.
This project is now in a situation, where U-Boot 2018.03 sits on NAND and everything else is on SATA-disk.

U-Boot loads and executes kernel, ramdisk and dtb from SATA, but kernel boot does hung like this:


resetting ...

U-Boot SPL 2018.03 (Apr 08 2018 - 00:01:35 +0300)
DRAM: 2048 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from NAND

U-Boot 2018.03 (Apr 08 2018 - 00:01:35 +0300) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Cubietech Cubietruck
I2C:   ready
DRAM:  2 GiB
NAND:  8192 MiB
Loading Environment from NAND... OK
Setting up a 1024x768 vga console (overscan 0x0)
In:    serial
Out:   vga
Err:   vga
Allwinner mUSB OTG (Peripheral)
SCSI:  Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   eth0: ethernet@01c50000, eth1: usb_ether
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
scanning bus for devices...
  Device 0: (0:0) Vendor: ATA Prod.: ST9320325AS Rev: 0001
            Type: Hard Disk
            Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
Found 1 device(s).

Device 0: (0:0) Vendor: ATA Prod.: ST9320325AS Rev: 0001
            Type: Hard Disk
            Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
... is now current device
Scanning scsi 0:1...
Found U-Boot script /boot/boot.scr
3708 bytes read in 49 ms (73.2 KiB/s)
## Executing script at 43100000
Boot script loaded from scsi
170 bytes read in 23 ms (6.8 KiB/s)
5824915 bytes read in 200 ms (27.8 MiB/s)
6909240 bytes read in 214 ms (30.8 MiB/s)
Found legacy kernel configuration
** File not found /boot/script.bin **
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    5824851 Bytes = 5.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 49a71000, end 49fff153 ... OK

Starting kernel ...


Any suggestions what to do next to get it booting the whole way up?
Quote from: phelum on April 04, 2018, 08:51:02 am
Thanks for the U-Boot link.  It sounds like new U-Boot does live in the low area of NAND.  Would it be acceptable to you if I get the new kernel running with an old U-Boot ?  I'll download Boris's kernel tomorrow and try to make one for testing.

You are welcome to do it.

Having recent SW running on it is only important in keeping it up to date.
Quote from: phelum on April 04, 2018, 08:19:51 am
Things seem to have changed.  I downloaded U-Boot and it's now 2018.05.  The Cubietruck_defconfig doesn't have any mention of NAND.  If I run make menuconfig I can set the NAND support options but it needs the page, block, and OOB sizes which I'll have to get.

If you patch it, you will have NAND chip metrics in Cubietruck_defconfig.

Quote from: phelum on April 04, 2018, 08:19:51 am
With your U-Boot and kernel writes problem (garbage) I remember I had to use different read/writes in my modified NAND driver to access the boot0/boot1 area.  It looks like U-Boot now lives in this area rather than the normal NAND blocks so maybe the reads/writes it uses aren't right for normal NAND (the area you can partition using nand-part) and this is why you're getting garbage with normal I/O from the kernel.

I presume you've partitioned and formatted your NAND.  Does it have a small (say 64MiB) first partition formated VFAT ?  If so can you mount it and see if u-boot.bin is there ?

We did not get far enough to make partitions. U-Boot SPL and U-Boot itself are read from bare NAND without any partitioning. U-Boot settings have one partition leaving start of the NAND untouched for those and U-Boot environment.

The U-boot can use NAND right, because environment can be saved and again read without any trouble.

To get the very same mainline U-Boot source it might be good idea to use this link:
The u-boot patch seems to have one setting what was not really tried.

Its the last line having "CONFIG_NAND_ECC_NONE=y" in it in Cubietruck_defconfig.

I suppose it should be removed first if you are going to try this.
Quote from: phelum on April 03, 2018, 04:17:12 pm
Wow, I'm impressed with how things have changed and what you've done.  What output do you get when you try to boot from NAND ?  I'm guessing that U-boot starts and tries to start the kernel.  One problem that I used to hit was that the MACHID wasn't passed to the kernel correctly and when the kernel started it noticed the mismatch and just stopped with no error message.

Also, where did you get your 4.9 kernel from ?  I might have to download a copy and try it here.

What we or mostly my son has done so far, is booting U-Boot from NAND without any USB-device or SD-card attached and then putting SD-card or USB-stick in loading kernel from there. Then booting kernel.

We did try flash NAND with user space having kernel and all then, but there are still some issues. So in fact we are still in situaton where U-Boot can definitely be booted from NAND and it works just fine with user space in USB or SD-card. We have not tried SATA yet, but I expect it work anyways and only the NAND is an issue.

NAND can be erased. It can be flashed, but after booting again it contains carbage. There has to be something odd. Writing NAND (through kernel MTD drivers) and then reading same NAND area using U-Boot driver to load user space is the issue. Kernel writing and U-Boot reading do not match.

Kernel source was cloned from bbrezillion gihub linux-sunxi having branch bb/4.7/ubi-mlc. It is 4.9 version even though branch is 4.7.

I suppose there must be something changed and old kernel NAND writing does not match new U-Boot reading. If we only got them to match each other, this would work just fine.

There are two attachments now. If you take 3/2018 mainline U-boot, patch it with what you can find in one of the attachments and then use u-boot.config as .config, you can have the very same U-Boot we have here.

Then you can take kernel source using link above, patch it with a file in attached kernel patch attachment and use config from the same zip, your kernel will be there too.

Just don't forget to use U-Boot ".img" file instead of ".bin" to flash. Mainline flashing instruction is otherwise just fine.
Quote from: phelum on April 03, 2018, 03:39:45 am
Quote from: tilator on April 02, 2018, 04:04:13 pm
I also would like it to boot (for emergency situations only) from NAND, but this seems to be tricky to do. U-boot and kernel both can access NAND, but they seem to do it somewhat differently. Both use mainline drivers.

Do you know if it has something to do with ECC or some NAND-related bit-manipulation?


When you say your new U-boot works well I assume you're booting from SD-card.  Is this correct ?

No. It does boot 03/2018 U-Boot from NAND without SD-card.

See this:;a=blob_plain;f=board/sunxi/README.nand;hb=HEAD

All you have to change is not flashing u-boot-dtb.bin but u-boot-dtb.img instead.

Do you know if kernel 4.9 should be compatible with this U-Boot version? It very much sounds like U-Boot and this kernel version use NAND different ways and they do not work together. Everything else seems to be OK.
Thank you for your knowledge.

What I and far more my son has done now, is compiling and installing 03.2018 version of U-Boot in it. It really replaces Allwinner boot0 and boot1. It seems to boot U-boot well and reliably.

It seems to be good choice in booting from NAND to SATA without SD-card. I'm sure it would as well boot from USB and of course SD-card too.

I also would like it to boot (for emergency situations only) from NAND, but this seems to be tricky to do. U-boot and kernel both can access NAND, but they seem to do it somewhat differently. Both use mainline drivers.

Do you know if it has something to do with ECC or some NAND-related bit-manipulation?
Quote from: phelum on March 24, 2018, 08:20:01 am

I think you'll need at least a small VFAT partition in NAND just to give you somewhere to put U-Boot.  boot1 finds U-Boot and runs it and this loads the kernel (e.g. uImage) which by default is in this partition.  It might be possible to put the kernel on SDA and change uEnv.txt to specify this if U-Boot is smart enough to access a volume (probably ext4) on disk.

If you just want to update U-Boot then you'll find it in /dev/mmcblk0p1 and it's called u-boot.bin.  The entry in uEnv.txt to specify a different kernel is kernel=........ but I don't know how you'd specify a kernel on sda1 (something like /dev/sda1/boot/mykernel but that's not right).  Maybe ask on the Armbian forum if you get no answers here.


2017.11 U-Boot seems to identify HDD as expected.

Would it be just possible to load kernel and what ever more needed from HDD with ext4load command?

Best solution would be if U-Boot environment was on NAND and U-Boot would load kernel and everything from HDD if it was present. SD-card would be used if it was found (before HDD in boot order) and booting everything from NAND if there were not HDD and not SD-card.

I suppose this can be done if the U-Boot is new enough. This 2017.11 at least seems to support both HDD and SD-card. I'm not sure if it can boot from NAND without compiling it again with NAND-support.

This U-Boot was from an Armbian image.

B.T.W. This suggests there should be U-Boot with SPL also put on NAND:

Might this just depend on if there is an U-Boot supporting both SATA and NAND?
Quote from: phelum on March 24, 2018, 06:13:29 am
I think the U-Boot with SPL you've found is for SD cards rather than NAND.

I would like to update u-boot in NAND. So - do you think I should use one without SPL? Should it be flashed to the very beginning of the flash if I do not have drivers for boot/boot1 access installed?

I would like to have only u-boot and environment on NAND and everything else on SATA.

Does this:

"linux-sunxi u-boot is fully SPL enabled which means it supports booting directly on the bare metal with no help from the Allwinner bootloaders. U-Boot SPL fully replaces Allwinner boot0 & boot1."

from here:

mean, u-boot can be flashed directly on nand and Allwinner boot0 and boo1 can be forgotten?
I suppose Xenial is not fully supported yet, but changing source and updating Apt (sudo apt-get update) will give access to it.

Full upgrade will lead to non-working system, but if you are lucky you can install individual packages successfully. Bad luck will end up installing everything again from beginning. So - some kind of backup before this might be a good idea.
Cubieboard v3 Images (Cubietruck) / Old images?
January 05, 2018, 07:49:37 am

I'm testing Cubietruck an I have binary images for flashing directly on MTD. However the downloadable images do not bring MTD any more up in /dev. Some of them give NAND but not MTD.

I suppose writing NAND and MTD is quite different.

My question is does anybody know where is at least one old enough SD-card image which would give support directly on MTD? Or is there any other easy way to do this? I did try to load MTD modules included in some Debian image, but it did not do the trick.