Tested Armbian_20.05.0-rc.149_Nanopim1_focal_current_5.4.43.img and I even tried hooking up video to see what was going on and nothing. Image doesn't expand on SD. I know this isn't supported, but would be nice to have focal on my old M1s. Also, I've tried the 5/24 image and the same issue.

Good timing. I am about to rebuild all images in a few hours. Let me try to fix it. Also having Nanopi M1 somewhere around ...

Thanks man, trying to get use out of these old boards! I also noticed Odroid C1 (same focal image) was segmentation faulting. Looks like that got cleaned up with Armbian_20.05.0-trunk.148_Odroidc1_focal_legacy_5.4.43.img. SD performance was really bad, so trying new SD with it, although that's nothing new with C1.

Nanopi M1 is fixed. It wasn't booting for me too ... boots now.

 

1 hour ago, sgjava said:

Odroid C1

Seems pretty stable for me, but it's picky on SD card since ever. That part is not going to change ... we are still on a prehistoric u-boot.

  ___      _           _     _    ____ _ 
 / _ \  __| |_ __ ___ (_) __| |  / ___/ |
| | | |/ _` | '__/ _ \| |/ _` | | |   | |
| |_| | (_| | | | (_) | | (_| | | |___| |
 \___/ \__,_|_|  \___/|_|\__,_|  \____|_|
                                         
Welcome to Armbian Bionic with Linux 5.4.43-meson

No end-user support: untested automated build

System load:   0.98 1.00 1.00   Up time:       1 day 11:04
Memory usage:  8 % of 994MB     IP:            10.0.30.198
CPU temp:      55°C             
Usage of /:    18% of 15G 

 

Thanks for getting M1 to booting! I have two of these I need to use for Zabbix Server and a web server. Yes, the C1 is picky about SD, I found a SD now that is 3x faster than the last one (thanks for all the great work):

sudo hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   972 MB in  2.00 seconds = 485.89 MB/sec
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
 Timing buffered disk reads:  44 MB in  3.04 seconds =  14.45 MB/sec

 

@Igor I'm seeing same issue with Armbian_20.05.1_Nanopim1_focal_current_5.4.43.img. I tried a few different SD cards to make sure it wasn't that. Below is an image of the board I'm using:

 

This is something on the build process side ... good that I just recreated 500+ images and I don't know which are corrupted and which not.

mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3789 bytes read in 3 ms (1.2 MiB/s)
## Executing script at 43100000
U-boot loaded from SD
Boot script loaded from mmc
152 bytes read in 3 ms (48.8 KiB/s)
13650311 bytes read in 660 ms (19.7 MiB/s)
7236248 bytes read in 350 ms (19.7 MiB/s)
Found mainline kernel configuration
29433 bytes read in 7 ms (4 MiB/s)
4185 bytes read in 6 ms (680.7 KiB/s)
Applying kernel provided DT fixup script (sun8i-h3-fixup.scr)
## Executing script at 44000000
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    13650247 Bytes = 13 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...

 

 

All other images works, amazing. 

 

- Stretch works

- Buster works

- Bullseye works

- Bionic works

- Focal has corrupted ramdisk

 

I really really need some manual check on other Focal images ... thanks.

Yes, I just tried Armbian_20.05.1_Nanopim1_bionic_current_5.4.43.img and it works. The Odroid C1, Odroid C2, Odroid XU4 and Nano Pi Neo Plus2 focal images work. I tested these against my Java Periphery library. but before I noticed the M1 image was hosed.  When did this corruption start? Seems like around the 5/24 image time frame.

5 minutes ago, sgjava said:

The Odroid C1, Odroid C2, Odroid XU4 and Nano Pi Neo Plus2 focal images work.

I assume 20.05.1 ? That's good, but it doesn't tell me anything about ... why

 

4 minutes ago, sgjava said:

When did this corruption start? Seems like around the 5/24 image time frame.

Don't know where is this related to ... 

@Igor Does this happen if you build manually? If not, then I will try to build locally. I should learn how to do this any ways.

1 minute ago, sgjava said:

Does this happen if you build manually?

Successful test from before was made manually and on another host.

OK, I'll try M1 focal manually.

@Igor Armbian_20.05.1_Nanopiduo_focal_current_5.4.43.img same issue as M1 image.

2 hours ago, sgjava said:

Armbian_20.05.1_Nanopiduo_focal_current_5.4.43.img same issue as M1 image.

It seems only armhf is affected. I boot a few 64bit and they all work ... 

@Igor I built Armbian_20.08.0-trunk_Nanopiduo_focal_current_5.4.43_minimal.img local and it boots fine. I will try Armbian_20.08.0-trunk_Nanopim1_focal_current_5.4.43_minimal.img later tonight. At least I have a work around. Sorry I cannot be more help for the automated issue.

On 5/31/2020 at 10:51 PM, sgjava said:

@Igor I built Armbian_20.08.0-trunk_Nanopiduo_focal_current_5.4.43_minimal.img local and it boots fine. I will try Armbian_20.08.0-trunk_Nanopim1_focal_current_5.4.43_minimal.img later tonight. At least I have a work around. Sorry I cannot be more help for the automated issue.

It seems that (faster loading) lz4 compression does not play well. Several days several people throw away and on the end its one liner 

https://github.com/armbian/build/commit/436a5681b517f0fec96175713f583ccf1cb7272d

@Igor I hate when that happens. I've been stuck on something for days and weeks sometimes and it's something crazy like that. Happens to every dev.

@Igor I can verify M1 image now works, thanks!