Jump to content

Upgrade Error with Armbian 5.00 on Cubieboard2 running from NAND


EtlARM

Recommended Posts

When doing apt-upgrade to get the latest linux-jessie-root-cubieboard2, it fails with this error message:

# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  linux-jessie-root-cubieboard2
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
3 not fully installed or removed.
Need to get 0 B/1.810 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
(Reading database ... 51863 files and directories currently installed.)
Preparing to unpack .../linux-jessie-root-cubieboard2_5.00_armhf.deb ...
Unpacking linux-jessie-root-cubieboard2 (5.00) over (4.81) ...
dpkg: error processing archive /var/cache/apt/archives/linux-jessie-root-cubieboard2_5.00_armhf.deb (--unpack):
 unable to make backup link of `./boot/bin/cubieboard.bin' before installing new version: Operation not permitted
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for systemd (215-17+deb8u3) ...
Errors were encountered while processing:
 /var/cache/apt/archives/linux-jessie-root-cubieboard2_5.00_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


When /boot is on NAND it is not possible to link files there, maybe that is the problem?

Link to comment
Share on other sites

Same error with `linux-jessie-root-cubietruck`.

Manually workaround works like a charm. BUT THE SYSTEM DEAD AFTER REBOOT!!!!

# cd /tmp
# apt-get download linux-jessie-root-cubietruck
# dpkg -r linux-jessie-root-cubietruck
# dpkg -i linux-jessie-root-cubietruck_5.00_armhf.deb
# rm linux-jessie-root-cubietruck_5.00_armhf.deb
Link to comment
Share on other sites

"Good" to hear other have the same problem... after the workaround went fine on my CubieBoard2 I bricked my production system CubieTruck the same way, you described. The workaround trick went fine on the CubieTruck. But after reboot the system does not start anymore:

  •  red power LED near power jack is lit
  •  network LEDs show some activity
  •  SATA disk stays off
  •  front LEDs stay off
  •  VGA has no signal
  •  no other reaction observable

 

I had similar NAND boot problems in the past, so I assumed it is the same case again. The last time it was sufficient to leave the board unpowered for some hours (discharging battery a bit), but this time nothing helped. So I migrated my complete system back to SDCARD, and it is working like before.

 

After thinking a night about the problem, it might be sufficient to manually update all kernel files on NAND1. I did not test that.

Do you have a serial cable to watch the boot output? (I don't have one.)

Link to comment
Share on other sites

Temporally workaround if you can't boot from NAND.

 

1. Boot from SD card

2. Edit boot.cmd and change root=/dev/nand2 + recompile

3. Reboot with SD card inserted

Link to comment
Share on other sites

I made a test on a Cubietruck NAND install which had some old build and upgrade was done successfully with this workaround:

 

dpkg -r linux-jessie-root-cubietruck

 

and install

 

apt-get install linux-jessie-root-cubietruck


Your NAND1 must be mounted under /boot otherwise upgrade can't be done properly. In another words - if you were changing core system settings, upgrading might not work.

Link to comment
Share on other sites

I did not change system settings, except minor modifications to script.bin (VGA mode and LEDs).

NAND1 was mounted as /boot (and NAND2 as /).

 

Probably it was bad luck or a weak power supply (I doubt that, as I also have the battery connected).

But as I migrated to SD card anyway, I will stay there for the near future.

 

Maybe I will find some time during the next days to compare the kernel files from NAND1 and SD card.

But as this is my "production" system, I would like to avoid additional down time.

Link to comment
Share on other sites

If your system don't (NAND) boot than I would need to see serial console boot log otherwise we are guessing. Even with log sometimes we don't see a problem.

 

I'll fix this problem that workaround won't be needed and do few more tests too see if I could crash the system.

Link to comment
Share on other sites

get something based on ftdi devices they are know to work across all platform windows/linux/osx but make sure you get a genuine device since ftdi are again abusing, at least on windows operating systems, that updates system and bricks non genuine ftdi chips

 

ebay has hundreds of listings for ft232 starting at around $2.2 only problem it could take a while to arrive. Based on where you live check out sparkfun or adafruit or pololu - they are US based and they will sell you a genuine part but it will cost like 5-6x or more than the ebay listings if you are EU based check olimex or exp-tech.de 

Link to comment
Share on other sites

After Upgrade "armbian ...| bash" my system banana pro was broken as well. rootfs are in SATA disk. 

 

My questions:

 

Which is the official installation procedure of the *.deb packages (kernel, boot, firmware, dtbs, etc) that were compiled with the ./compile.sh script? I could not find anything.

 

And which one *deb files are mandatory in top of the prebuilt release? For example, when I compiled the 3.10.96 for odroidxu4 on the top of a prebuilt 3.10.94 I didn't know certanly which of them were necessary and which not. For example the *.deb of DTBs was giving error because the original file could not be copied, but it looks like that it works nice now.

 

Thanks in advance

Link to comment
Share on other sites

"Upgrade script" was created mainly for older distributions that didn't have Armbian apt repository set up. For more or less fresh versions upgrade should be done with apt (apt-get update && apt-get upgrade).

Sometimes though you may need to additionally tweak something manually here or there (like modifying u-boot script or installing fake-hwclock package).

 

For installing self-compiled stuff - kernel and DTB (if kernel requires it) should be installed always in pair; updating headers and firmware may be necessary if you use them (i.e. self-compiled drivers of Wi-Fi modules that require firmware). Updating u-boot is generally not needed unless there were device-specific fixes made for it.

 

DTB deb package may give error with FAT /boot partition (i.e. with rootfs on NAND or devices with older u-boot), deleting old package and removing files in /boot manually should solve this issue.

Link to comment
Share on other sites

"Upgrade script" was created mainly for older distributions that didn't have Armbian apt repository set up. For more or less fresh versions upgrade should be done with apt (apt-get update && apt-get upgrade).

Sometimes though you may need to additionally tweak something manually here or there (like modifying u-boot script or installing fake-hwclock package).

 

For installing self-compiled stuff - kernel and DTB (if kernel requires it) should be installed always in pair; updating headers and firmware may be necessary if you use them (i.e. self-compiled drivers of Wi-Fi modules that require firmware). Updating u-boot is generally not needed unless there were device-specific fixes made for it.

 

DTB deb package may give error with FAT /boot partition (i.e. with rootfs on NAND or devices with older u-boot), deleting old package and removing files in /boot manually should solve this issue.

 

I was sure, that you will answer, thank you. I try to revert to old kernels to get the banana pro working again (but not right now).

 

Yes, I realized about the armbian repository using  the usual apt-get upgrade in new armbian builts. The point is that I'm using the Debian testing packages and therefore I have #commented the armbian repository list, therefore not getting these automatically. Probably there is another smarter solution to cohexist both of them, but I'm not aware and because it is so easy to compile own kernels now, due to your efforts on compile script, I don't care anymore that I have #commented armbian repository. However will be nice if some aditional infos could be pushed on the docus, focushing on people that is installing kernel on top of igors prebuilt images and how to revert to old kernels. I see that this was commented sometimes here or there in the Forum.

 

Yes, indeed, you are totally right mentioning the /boot problem.

Link to comment
Share on other sites

The point is that I'm using the Debian testing packages and therefore I have #commented the armbian repository list, therefore not getting these automatically. Probably there is another smarter solution to cohexist both of them, but I'm not aware and because it is so easy to compile own kernels now, due to your efforts on compile script, I don't care anymore that I have #commented armbian repository. However will be nice if some aditional infos could be pushed on the docus, focushing on people that is installing kernel on top of igors prebuilt images and how to revert to old kernels. I see that this was commented sometimes here or there in the Forum.

I'm using Debian testing too with commented Armbian repository, but it should work with jessie-specific config since both jessie and stretch are systemd-based.

➜  ~  % cat /etc/apt/sources.list.d/armbian.list
deb http://apt.armbian.com jessie main

Downgrading kernel, u-boot and other packages should be possible by manually downloading and installing packages from apt repository, or by specifying package version for apt-get manually (apt-get install <package>=<version>)

You can check available versions using i.e.

apt-cache madison linux-image-next-sunxi

 

 

linux-image-next-sunxi |       5.00 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |       4.81 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |       4.70 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.6 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.5 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.4 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.3 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.2 | http://apt.armbian.com jessie/main armhf Packages

 

 

 

BTW, if you are experiencing SATA issues on Banana Pro, please check this topic, it might be u-boot related and may be already fixed in new u-boot release.

Link to comment
Share on other sites

I'm using Debian testing too with commented Armbian repository, but it should work with jessie-specific config since both jessie and stretch are systemd-based.

➜  ~  % cat /etc/apt/sources.list.d/armbian.list
deb http://apt.armbian.com jessie main

Downgrading kernel, u-boot and other packages should be possible by manually downloading and installing packages from apt repository, or by specifying package version for apt-get manually (apt-get install <package>=<version>)

Youcan check available versions using i.e.

apt-cache madison linux-image-next-sunxi

 

 

linux-image-next-sunxi |       5.00 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |       4.81 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |       4.70 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.6 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.5 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.4 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.3 | http://apt.armbian.com jessie/main armhf Packages
linux-image-next-sunxi |        4.2 | http://apt.armbian.com jessie/main armhf Packages

 

 

 

BTW, if you are experiencing SATA issues on Banana Pro, please check this topic, it might be u-boot related and may be already fixed in new u-boot release.

thanks!!! very interesting both tips and where the armbian repository is placed on.

 

 

Link to comment
Share on other sites

As an alternative, if you want/need a PL2303 based converter that's also operable on latest windows system I could recommend this here:

http://www.amazon.de/PL2303TA-RS232-Konverter-Serial-Cable/dp/B00T60QTUK/ref=sr_1_19?ie=UTF8&qid=1455911912&sr=8-19&keywords=pl2303

 

This has a PL2303TA chip inside, means it will work with Win 8 and 10 out of the box (i. e. with the drivers that come with windows). It is 3.3V (but has no 5V switch), so it can operate savely on a cubie or raspberry. The cable coloring the supplier states in the link is correct (at least for mine it was). The only disadvantage is that it's beeing shipped directly from China, so it may be you'll have to wait 1 or even 2 months for delivery (depends on how fast it will pass the toll).

 

BTW: Good to hear in time that enforcing an update might brick the installation, I was already tempted to do it, too. So I will wait for what Igor's research will yield. I'm also using my cubie as a production system (Backup, Owncloud, AP), so of course I'm not keen on bricking it! ;-)

 

This is a bit OT, I know, nevertheless: Syncthing plus dirvish plus samba (with RO shares) make up an open-source-only, fully automated, versatile and almost maintenance-free backup system, where even unexperienced (Windows-only) users can access their backups themselves and without the risk of any ransomware gaining write access to the backups. This is highly recommended!

 

HTH

 

Don

Link to comment
Share on other sites

Hi,

 

I ran into the same problem "unable to make backup link of `./boot/bin/cubieboard.bin' before installing new version: Operation not permitted" when doing a regular apt-get update/upgrade. After reading this thread and getting aware it may cause problems when booting from NAND I did not install Igor's workaround. Nevertheless I had to realize my Cubie is bricked after a reboot. :o

I guess this is due to some other updates apt-get spilled on the NAND during the update that triggered the error. Igor, is there any news why this break NAND booting and how to overcome this? If this is of any help I attach the console output of my cubie here. Maybe this eases determining the reason why things broke:

 

HELLO! BOOT0 is starting!
boot0 version : 2.0.0â–’
read dram para.
dram driver version: 1.15
dram size =2048MB
0xffffffff
super_standby_flag = 0
Succeed in opening nand flash.
block from 2 to 6
deal block 2
Succeed in reading Boot1 file head.
The size of Boot1 is 0x00068000.
The file stored in 0x00000000 of block 2 is perfect.
Check is correct.
Ready to disable icache.
Succeed in loading Boot1.
Jump to Boot1.
[       0.148] boot1 version : 2.0.0
[       0.148] script installed early ok
[       0.149] pmu type = 3
[       0.254] bat vol = 4504 mv
[       0.268] axi:ahb:apb=4:2:2
[       0.268] set dcdc2=1450mv, clock=912M successed
[       0.270] key
[       0.283] no key found
[       0.283] flash init start
[       0.283] NB1 : enter NFB_Init
[       0.286] NB1 : enter phy init
[       0.289] [NAND] nand driver(B) version: 0x0x00000002, 0x0x00000012, data: 0x20130627
[       0.298] get the good blk ratio from hwscan : 944
[       0.302] NB1 : nand phy init ok
[       3.177] _RepairLogBlkTbl start
[       3.180] Log Block Index 0x00000000, LogicBlockNum: 0x0000032a, LogBlockType: 0x00000000
[       3.183] log0: 0x000000a2, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.189] datablock: 0x000000b3, lastusedpage: 0x00000010
[       3.198] Log Block Index 0x00000001, LogicBlockNum: 0x00000346, LogBlockType: 0x00000000
[       3.204] log0: 0x0000019b, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.210] datablock: 0x00000232, lastusedpage: 0x00000002
[       3.218] Log Block Index 0x00000002, LogicBlockNum: 0x0000020c, LogBlockType: 0x00000000
[       3.224] log0: 0x0000023b, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.231] datablock: 0x000000a8, lastusedpage: 0x00000006
[       3.239] Log Block Index 0x00000003, LogicBlockNum: 0x00000108, LogBlockType: 0x00000000
[       3.245] log0: 0x00000388, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.251] datablock: 0x00000141, lastusedpage: 0x00000012
[       3.260] Log Block Index 0x00000004, LogicBlockNum: 0x00000318, LogBlockType: 0x00000000
[       3.265] log0: 0x0000013c, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.272] datablock: 0x0000042c, lastusedpage: 0x00000002
[       3.280] Log Block Index 0x00000005, LogicBlockNum: 0x0000007d, LogBlockType: 0x00000000
[       3.286] log0: 0x00000110, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.293] datablock: 0x0000047f, lastusedpage: 0x00000006
[       3.300] Log Block Index 0x00000006, LogicBlockNum: 0x00000308, LogBlockType: 0x00000000
[       3.307] log0: 0x000004b9, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.313] datablock: 0x000001a0, lastusedpage: 0x000001a4
[       3.321] Log Block Index 0x00000007, LogicBlockNum: 0x0000030c, LogBlockType: 0x00000000
[       3.327] log0: 0x000001bf, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.334] datablock: 0x0000051b, lastusedpage: 0x00000188
[       3.342] Log Block Index 0x00000008, LogicBlockNum: 0x0000007e, LogBlockType: 0x00000000
[       3.348] log0: 0x0000052b, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.354] datablock: 0x000000e9, lastusedpage: 0x00000008
[       3.362] Log Block Index 0x00000009, LogicBlockNum: 0x00000327, LogBlockType: 0x00000000
[       3.369] log0: 0x0000005f, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.375] datablock: 0x0000056a, lastusedpage: 0x000000b2
[       3.383] Log Block Index 0x0000000a, LogicBlockNum: 0x00000208, LogBlockType: 0x00000000
[       3.389] log0: 0x000001aa, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.396] datablock: 0x00000570, lastusedpage: 0x00000068
[       3.404] Log Block Index 0x0000000b, LogicBlockNum: 0x00000328, LogBlockType: 0x00000000
[       3.410] log0: 0x0000051f, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.416] datablock: 0x000005c7, lastusedpage: 0x0000009e
[       3.425] Log Block Index 0x0000000c, LogicBlockNum: 0x0000010b, LogBlockType: 0x00000000
[       3.430] log0: 0x0000049f, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.437] datablock: 0x000005fd, lastusedpage: 0x00000008
[       3.445] Log Block Index 0x0000000d, LogicBlockNum: 0x0000007c, LogBlockType: 0x00000000
[       3.451] log0: 0x0000068c, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.458] datablock: 0x00000657, lastusedpage: 0x000000f2
[       3.466] Log Block Index 0x0000000e, LogicBlockNum: 0x0000007b, LogBlockType: 0x00000000
[       3.472] log0: 0x0000069c, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.478] datablock: 0x00000683, lastusedpage: 0x000000d8
[       3.486] Log Block Index 0x0000000f, LogicBlockNum: 0x00000008, LogBlockType: 0x00000000
[       3.492] log0: 0x00000703, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.499] datablock: 0x000007f4, lastusedpage: 0x00000028
[       3.507] Log Block Index 0x00000000, LogicBlockNum: 0x0000007e, LogBlockType: 0x00000000
[       3.513] log0: 0x000000ef, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.519] datablock: 0x000002b8, lastusedpage: 0x00000002
[       3.527] Log Block Index 0x00000001, LogicBlockNum: 0x00000052, LogBlockType: 0x00000000
[       3.534] log0: 0x000002bc, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.540] datablock: 0x0000022e, lastusedpage: 0x000000ea
[       3.548] Log Block Index 0x00000002, LogicBlockNum: 0x000000c9, LogBlockType: 0x00000000
[       3.554] log0: 0x00000233, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.561] datablock: 0x000002ca, lastusedpage: 0x00000078
[       3.569] Log Block Index 0x00000003, LogicBlockNum: 0x00000162, LogBlockType: 0x00000000
[       3.575] log0: 0x000002fa, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.581] datablock: 0x0000004e, lastusedpage: 0x0000004a
[       3.590] Log Block Index 0x00000004, LogicBlockNum: 0x00000083, LogBlockType: 0x00000000
[       3.595] log0: 0x00000109, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.602] datablock: 0x00000314, lastusedpage: 0x00000002
[       3.610] Log Block Index 0x00000005, LogicBlockNum: 0x00000063, LogBlockType: 0x00000000
[       3.616] log0: 0x000002db, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.623] datablock: 0x000003d2, lastusedpage: 0x00000004
[       3.631] Log Block Index 0x00000006, LogicBlockNum: 0x00000056, LogBlockType: 0x00000000
[       3.637] log0: 0x000003ea, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.643] datablock: 0x0000026c, lastusedpage: 0x00000016
[       3.651] Log Block Index 0x00000007, LogicBlockNum: 0x00000152, LogBlockType: 0x00000000
[       3.657] log0: 0x00000259, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.664] datablock: 0x000003fc, lastusedpage: 0x0000003a
[       3.672] Log Block Index 0x00000008, LogicBlockNum: 0x00000062, LogBlockType: 0x00000000
[       3.678] log0: 0x00000428, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.684] datablock: 0x0000021a, lastusedpage: 0x00000002
[       3.693] Log Block Index 0x00000009, LogicBlockNum: 0x00000156, LogBlockType: 0x00000000
[       3.699] log0: 0x00000406, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.705] datablock: 0x00000495, lastusedpage: 0x00000008
[       3.713] Log Block Index 0x0000000a, LogicBlockNum: 0x00000103, LogBlockType: 0x00000000
[       3.719] log0: 0x000003cc, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.726] datablock: 0x00000499, lastusedpage: 0x000001a2
[       3.733] Log Block Index 0x0000000b, LogicBlockNum: 0x000000ce, LogBlockType: 0x00000000
[       3.740] log0: 0x000004cd, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.746] datablock: 0x00000159, lastusedpage: 0x00000176
[       3.754] Log Block Index 0x0000000c, LogicBlockNum: 0x00000252, LogBlockType: 0x00000000
[       3.760] log0: 0x00000359, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.767] datablock: 0x00000653, lastusedpage: 0x0000000a
[       3.775] Log Block Index 0x0000000d, LogicBlockNum: 0x00000074, LogBlockType: 0x00000000
[       3.781] log0: 0x00000161, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.788] datablock: 0x00000679, lastusedpage: 0x00000002
[       3.796] Log Block Index 0x0000000e, LogicBlockNum: 0x00000076, LogBlockType: 0x00000000
[       3.802] log0: 0x000006a3, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.808] datablock: 0x0000045e, lastusedpage: 0x00000002
[       3.816] Log Block Index 0x0000000f, LogicBlockNum: 0x00000081, LogBlockType: 0x00000000
[       3.822] log0: 0x000007be, Log1: 0x0000ffff, WriteIndex: 0x00000000
[       3.829] datablock: 0x000004c5, lastusedpage: 0x0000000c
[       3.834] _RepairLogBlkTbl end
[       3.851] NB1 : init ok
[       3.851] flash init finish
[       3.852] fs init ok
[       3.854] fattype FAT16
[       3.856] fs mount ok
[       3.859] nand good_block_ratio=944
[       3.862] storage_type=0
[       3.873] 0
[       3.874] set pc
[       3.874] usbdc_vol = 4000, usbdc_cur = 0
[       3.875] usbpc_vol = 4200, usbpc_cur = 0
[       3.880] init to usb pc
[       3.883] set pc
[       3.898] can't find c:\drv_de.drv
[       3.898] ERR: wBoot_driver_install display driver failed
[       3.902] key value = 0
[       3.905] recovery key high 40, low 4
[       3.909] show pic finish
[       3.911] load kernel start
[       3.933] load kernel successed
[       3.933] start address = 0x4a000000
[       3.934] ERR: display driver not open yet
[       3.939] ERR: display driver not open yet
[       3.943] power exit detect

U-Boot 2011.09-rc1-00000-gf75abad-dirty (Oct 21 2013 - 18:44:22) Allwinner Technology

CPU:   SUNXI Family
Board: A20-Cubietruck
DRAM:  2 GiB
NAND:  NB1 : enter NFB_Init
[NAND] nand driver(B) version: 0x2, 0x12, data: 20130526
[NAND] set nand_good_block_ratio 944
NB1 : nand phy init ok
NB1 : init ok
2816 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
--------fastboot partitions--------
-total partitions:2-
-name-        -start-       -size-
bootloader  : 10000         10000
rootfs      : 20000         560000
-----------------------------------
no misc partition is found
Hit any key to stop autoboot:  0
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
reading /uEnv.txt

293 bytes read
## Warning: defaulting to text format
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
reading /script.bin

46360 bytes read
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
reading uImage

** Unable to read "uImage" from nand 0:0 **
sun7i#
 

 

Remarkable things in the output:

  • Dunno what this "_RepairLogBlkTbl start" ... "_RepairLogBlkTbl end" section should tell me. It is being output at every boot try, maybe this is normal.
  • There's a really strange line at 3.898:
    "can't find c:\drv_de.drv
    ERR: wBoot_driver_install display driver failed"
    WTF is it searching for a DOS path???
  • Then there's a complaint about a missing misc partition and several entries complaining about mount failures for an unrecognized filesystem type.
  • Then it finally fails to read the uImage and of course and this brings the boot process to a halt.
  • The Cubie is still alive however, I end up on a promt with limited functionality, a "?" gives a list of commands but this seems to be all very low level (no ls but fatls, ext2ls, etc. with strange syntax, e.g. "usage: fatls <interface> <dev[:part]> [directory]").

I managed to do a "fatls nand 0:0", this gives me

 

   118912   boot.axf
      106   boot.ini
            linux/
      512   magic.bin
      293   uenv.txt
    46360   script.bin
  2006492   system.map-3.4.110-sun7i
  5608120   vmlinuz-3.4.110-sun7i
            bin/
    96449   config-3.4.110-sun7i

8 file(s), 2 dir(s)
 

As you can easily see there ain't no such thing as a "uImage" (while the other files needed are there). So now the questions are:

  • How come something has killed uImage?
  • How can I bring it back there? I dont want to reinstall the Cubie, it's a lot of work and I made a lot of settings specific to my needs.
  • How to avoid this will happen again?

So, does this help fixing the problem? Hopefully there will be a quick solution...

 

Regards

 

Don

Link to comment
Share on other sites

Bootloader which we use for NAND boot process is as is. Currently the only one which allows us boot this way and it was designed for Android. That's the reason of strange messages during boot.

 

What you need to do is - boot from SD card and convert vmlinuz-3.4.110-sun7i to uImage. (they are on /dev/nand1) The reason why this was not done during the upgrade is that your NAND probably run out of space. Some our old nand installations had to small boot partition so make sure that you have enough free space to issue this command. In case you don't, do it elsewhere and remove vmlinuz file before moving uImage there:

mkimage -A arm -O linux -T kernel -C none -a "0x40008000" -e "0x40008000" -n "Linux kernel" -d vmlinuz-3.4.110-sun7i uImage 
Link to comment
Share on other sites

Hello,

 

yep, that did the trick, Cubie is alive again: :thumbup:

 

Image Name:   Linux kernel
Created:      Sun Feb 28 22:49:04 2016
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    5608120 Bytes = 5476.68 kB = 5.35 MB
Load Address: 40008000
Entry Point:  40008000

 

Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
reading uImage

5608184 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5608120 Bytes = 5.3 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
Using machid 0x10bb from environment

Starting kernel ...

 

Strange however that nand1 does have sufficient space:

 

~$ df

Filesystem     1K-blocks    Used Available Use% Mounted on
...

/dev/nand1         32686    8852     23834  28% /boot

 

I was able to create the image directly where it belongs and I didn't have to delete vmlinuz. Thus insufficient space couldn't be the reason uImage did get lost. Guess I'll never find out...

 

Anyway, thanks a lot Igor, you saved my day!

 

So, amhairghin and EtlARM, maybe this is also the problem of your bricked systems?

 

BR

 

Don

Link to comment
Share on other sites

So, amhairghin and EtlARM, maybe this is also the problem of your bricked systems?

 

Yes, it is very likely the same or similar problem. On my NAND1 I found only a zImage identical to the vmlinuz file but not an uImage.

When creating an uImage it is binary different than the zImage. (Expected behavior, as uImage can be a zImage with additional header.)

 

I will do more tests (e.g. booting) when I find some spare time and the serial cable has arrived...

Link to comment
Share on other sites

Yep, serial console cable is indeed helpful, if not indispensable. Without it I wouldn't have been able to quickly analyse the problem, as Igor's image is completely headless. You don't even get a text console output if you plug in a monitor and keyboard. So until the cubie has completed booting and you can ssh the box you're nailed down to the serial.

 

One additional fact I forgot to mention:

After I was able to reanimate my Cubie I dared to install Igor's workaround, provoking re-bricking it:

 

 

dpkg -r linux-jessie-root-cubietruck

apt-get install linux-jessie-root-cubietruck

 

Guess what, this did install without a hitch. To be safe I also did a reboot and it came up alive again without a problem.

 

So I guess the following:

I did a regular apg-get update/upgrade at that time. This installed some updates but failed to install linux-jessie-root-cubietruck. It was one of those other updates that seemingly installed correctly but bricked the Cubie, not linux-jessie-root-cubietruck. I didn't realize at that time because I didn't reboot - why should I, it's not a Windows machine ;-)

I learned that days later when I shut down the Cubie for some hardware changes and it wouldn't come up again.

 

So, as linux-jessie-root-cubietruck isn't the culprit this easily explains why Igor did not succeed reproducing the failure when testing this. The interesting remnant would be to find out which update bricked the Cubie. Unfortunately I don't know if I could backtrack which updates were installed in conjunction with linux-jessie-root-cubietruck, so this leaves plenty of room for speculations.

 

BR

 

Don

Link to comment
Share on other sites

 

I definitely second that. I've bought plenty of the CP2102 USB-to-UART adapters (more than 10); all of them works well.

Just one thing: I change the resistors connected to the LEDs with 2K7 resistors, so that they don't blind me.

 

Bonus advantage of the CP2102 module: SiLabs actually made a driver for PowerPC based Macintosh (which is my primary computer) - many of the others don't want to support anything but Windows. In addition,

Prolific requires you to pay a mountain of money, if you want to change the VID/PID of PL2303, which was why I moved to CP2102.

Link to comment
Share on other sites

For me, after every update I must do:

mkimage -A arm -O linux -T kernel -C none -a "0x40008000" -e "0x40008000" -n "Linux kernel" -d zImage uImage 

The system never builds uImage and I not have disk space problems.

Link to comment
Share on other sites

I'm not sure if this is the exact same issue, but I had a similar error message with my most recent apt-get upgrade. As can be seen, the issue here was that dpkg tried to make a backup of a directory to a location that was not empty:

# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  linux-firmware-image-sun7i linux-headers-sun7i linux-image-sun7i linux-jessie-root-cubietruck
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.4 MB of archives.
After this operation, 12.3 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://apt.armbian.com/ jessie/main linux-firmware-image-sun7i armhf 5.15 [285 kB]
Get:2 http://apt.armbian.com/ jessie/main linux-headers-sun7i armhf 5.15 [5,786 kB]
Get:3 http://apt.armbian.com/ jessie/main linux-image-sun7i armhf 5.15 [14.0 MB]
Get:4 http://apt.armbian.com/ jessie/main linux-jessie-root-cubietruck armhf 5.15 [372 kB]                            
Fetched 20.4 MB in 11s (1,778 kB/s)                                                                                   
(Reading database ... 61165 files and directories currently installed.)
Preparing to unpack .../linux-firmware-image-sun7i_5.15_armhf.deb ...
Unpacking linux-firmware-image-sun7i (5.15) over (5.11) ...
Preparing to unpack .../linux-headers-sun7i_5.15_armhf.deb ...
Unpacking linux-headers-sun7i (5.15) over (5.11) ...
Preparing to unpack .../linux-image-sun7i_5.15_armhf.deb ...
Unpacking linux-image-sun7i (5.15) over (5.11) ...
Preparing to unpack .../linux-jessie-root-cubietruck_5.15_armhf.deb ...
mv: cannot move ‘/boot/bin’ to ‘/boot/bin.old/bin’: Directory not empty
Unpacking linux-jessie-root-cubietruck (5.15) over (5.11) ...
dpkg: error processing archive /var/cache/apt/archives/linux-jessie-root-cubietruck_5.15_armhf.deb (--unpack):
 unable to make backup link of `./boot/bin/bananapi.bin' before installing new version: Operation not permitted
Processing triggers for systemd (215-17+deb8u4) ...
Errors were encountered while processing:
 /var/cache/apt/archives/linux-jessie-root-cubietruck_5.15_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

A close look at /boot/bin.old revealed that inside /boot/bin.old was another bin folder:

root@xxxxxx:/boot/bin.old# ls -la
total 984
drwxr-xr-x 3 root root  4096 May 27 18:12 .
drwxr-xr-x 5 root root 16384 Jul  1 09:10 ..
-rwxr-xr-x 1 root root 45936 Feb 11 23:48 aw-som-a20.bin
-rwxr-xr-x 1 root root 50560 Feb 11 23:48 bananapi.bin
-rwxr-xr-x 1 root root 50624 Feb 11 23:48 bananapilcd7.bin
-rwxr-xr-x 1 root root 50656 Feb 11 23:48 bananapipro.bin
-rwxr-xr-x 1 root root 50500 Feb 11 23:48 bananapiprolcd7.bin
drwxr-xr-x 2 root root  4096 May  6 10:37 bin
-rwxr-xr-x 1 root root 46308 Feb 11 23:48 cubieboard2.bin
-rwxr-xr-x 1 root root 46248 Feb 11 23:48 cubieboard2dual.bin
-rwxr-xr-x 1 root root 43716 Feb 11 23:48 cubieboard.bin
-rwxr-xr-x 1 root root 46404 Feb 11 23:48 cubietruck.bin
-rwxr-xr-x 1 root root 51012 Feb 11 23:48 lamobo-r1.bin
-rwxr-xr-x 1 root root 53480 Feb 11 23:48 lime2.bin
-rwxr-xr-x 1 root root 43508 Feb 11 23:48 lime-a10.bin
-rwxr-xr-x 1 root root 52616 Feb 11 23:48 lime.bin
-rwxr-xr-x 1 root root 52252 Feb 11 23:48 micro.bin
-rwxr-xr-x 1 root root 29804 Feb 11 23:48 olinux-som-a13.bin
-rwxr-xr-x 1 root root 35888 Feb 11 23:48 orangepi2.bin
-rwxr-xr-x 1 root root 50972 Feb 11 23:48 orangepi.bin
-rwxr-xr-x 1 root root 35996 Feb 11 23:48 orangepione.bin
-rwxr-xr-x 1 root root 36000 Feb 11 23:48 orangepipc.bin
-rwxr-xr-x 1 root root 36768 Feb 11 23:48 orangepiplus.bin
-rwxr-xr-x 1 root root 49300 Feb 11 23:48 pcduino3nano.bin
-rwxr-xr-x 1 root root  4229 Jan  2 13:53 upgrade.log

I suspect that this issue may be caused by multiple updates due to some error in the update scripts. The first time, the old /boot/bin directory is renamed to /boot/bin.old. The second time, the directory /boot/bin.old already exists and the /boot/bin directory is moved into that directory. The third time: we already have /boot/bin.old/bin and a move of /boot/bin to /boot/bin.old/bin causes this failure.

 

I've solved this by moving bin.old and the bin folder inside it to another name and running apt-get upgrade again:

# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  linux-jessie-root-cubietruck
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
3 not fully installed or removed.
Need to get 0 B/372 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 61134 files and directories currently installed.)
Preparing to unpack .../linux-jessie-root-cubietruck_5.15_armhf.deb ...
Unpacking linux-jessie-root-cubietruck (5.15) over (5.11) ...
Processing triggers for systemd (215-17+deb8u4) ...
Setting up linux-firmware-image-sun7i (5.15) ...
Setting up linux-headers-sun7i (5.15) ...
Compiling headers - please wait ...
Setting up linux-image-sun7i (5.15) ...
Image Name:   Linux kernel
Created:      Fri Jul  1 09:30:02 2016
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    5606240 Bytes = 5474.84 kB = 5.35 MB
Load Address: 40008000
Entry Point:  40008000
Setting up linux-jessie-root-cubietruck (5.15) ...

As can be seen, the uImage is created as well. I still have to reboot the system, but I guess that it will work normally.

 

Please confirm if other have seen this as well, I can create a small bug report if this is indeed a mistake in the upgrade scripts...

 

Edit: reboot works normally, boot from nand...

Link to comment
Share on other sites

For me not work.

 

My update.

$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  linux-firmware-image-sun7i linux-headers-sun7i linux-image-sun7i linux-jessie-root-cubietruck
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.4 MB of archives.
After this operation, 12.3 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://apt.armbian.com/ jessie/main linux-firmware-image-sun7i armhf 5.15 [285 kB]
Get:2 http://apt.armbian.com/ jessie/main linux-headers-sun7i armhf 5.15 [5,786 kB]
Get:3 http://apt.armbian.com/ jessie/main linux-image-sun7i armhf 5.15 [14.0 MB]
Get:4 http://apt.armbian.com/ jessie/main linux-jessie-root-cubietruck armhf 5.15 [372 kB]
Fetched 20.4 MB in 5s (3,561 kB/s)                
(Reading database ... 52931 files and directories currently installed.)
Preparing to unpack .../linux-firmware-image-sun7i_5.15_armhf.deb ...
Unpacking linux-firmware-image-sun7i (5.15) over (5.11) ...
Preparing to unpack .../linux-headers-sun7i_5.15_armhf.deb ...
Unpacking linux-headers-sun7i (5.15) over (5.11) ...
Preparing to unpack .../linux-image-sun7i_5.15_armhf.deb ...
Unpacking linux-image-sun7i (5.15) over (5.11) ...
Preparing to unpack .../linux-jessie-root-cubietruck_5.15_armhf.deb ...
Unpacking linux-jessie-root-cubietruck (5.15) over (5.11) ...
Processing triggers for systemd (215-17+deb8u4) ...
Setting up linux-firmware-image-sun7i (5.15) ...
Setting up linux-headers-sun7i (5.15) ...
Compiling headers - please wait ...
Setting up linux-image-sun7i (5.15) ...
Setting up linux-jessie-root-cubietruck (5.15) ...

The update not make the magic line:

mkimage -A arm -O linux -T kernel -C none -a "0x40008000" -e "0x40008000" -n "Linux kernel" -d zImage uImage

:(

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines