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?

Hi,Sorry for the delayed reply. I can't login using Firefox and I only have Chrome at one worksite.

It sounds like you've researched U-Boot well and know more about it than I do. U-Boot does have an internal script (that can be changed) which tells it where to look for the kernel and in what order. I remember that Igor changed a U-Boot so it looked for uEnv.cb2 if running on a CB2 and uEnv.ct if running on a CT. So lots can be done to U-Boot if you want to change it.

I don't think your statement about U-Boot with SPL is quite right for NAND. With NAND the SPL equivalent is boot0 and boot1 and these are hidden away in part of the NAND that is very hard to access. The modified disk driver I offered is patched so it can read/write this area but only before normal access is done. NAND has complications such as relocation and usage tables and also there is a scrambling key which affects reads and writes to the boot area.

If your CT is booting correctly I'd forget about boot0 and boot1 and just play with the relevant files in /dev/nand1. The relevant files there are u-boot.bin and uEnv.txt if you've got an old non-dts setup. Newer setups use boot.scr and a .dtb file. The boot.scr file specifies the load sequence so you should be able to change this file and get the CT to load the kernel from SDA (or whatever). The only boot.scr I have was for a CB2 loading a 3.16 kernel from MMC. If your U-Boot can access NAND or disk then you should be able to change boot.scr and get U-Boot to load a kernel from disk or NAND.

It loads the kernel at 44000000, the .dtb at 46000000, and then boots the kernel (at 44000000) which gets the .dtb address in memory from the last parameter. So the kernel starts and knows where to find the .dtb (environment) file. mmc 0:1 is SD card drive 0 partition 1 but I don't know what you'd put for NAND or disk here.

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?

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?

Hi,

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

My understanding of a NAND boot sequence is boot0, boot1, boot.axf. u-boot.bin, uImage.boot0 initialises the RAM and loads an runs boot1.boot1 reads the first NAND partition (vfat) and loads and runs boot.axf.boot.axf reads boot.ini and loads and runs u-boot.bin.u-boot.bin reads uEnv.txt and loads and starts the kernel (uImage).

I think u-boot.bin searches for a boot script in /boot or / and will use it if found. Otherwise it defaults to its internal script which tells it to load script.bin and then load and run the kernel.

I presume you have a Cubietruck. Can you connect a serial monitor to the debug port and see what happens if you try to boot with no SD-card present ? My CB1, CB2, and CTs all boot from NAND but I'm running a legacy 3.4.103 kernel. I did have the CB2 booting a 3.16 kernel but I gave up because it wouldn't support something (I forget what).

If your CT won't boot from NAND then watching the log from the debug port is the first step in solving the issues.

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?

Hi,

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

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.

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.

Hi,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.

Hi,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.

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.

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. Also the make complains that my gcc isn't new enough so I might have to try compiling on a newer system. This will take a while.

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 ?

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.

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:

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.

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.

Having recent SW running on it is only important in keeping it up to date.

Hi,

I'm getting the 4.7 kernel running (from SD card) but I can't get it to see the AP6210 or NAND. What I have noticed is that there is the CONFIG_MTD_NAND_ECC_SMC option in the compiler config that reverses the work byte order. If you're seeing garbage maybe changing this option might help.

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.