9 minutes ago, balbes150 said:

when updating, the uInitrd is not generated (it is completely absent). There may be an error in the kernel package.

Aha, O.K., this was fixed https://github.com/armbian/build/pull/2348 

 

Tnx.

11 минут назад, Igor сказал:

this was fixed

Do you already have a package with the fixed kernel ? If there is a package, I can check it (as a standalone deb package).

4 minutes ago, balbes150 said:

Do you already have a package with the fixed kernel ? If there is a package, I can check it (as a standalone deb package).

 

Images for C2 are broken - will be updated. You can test by building new image and update to beta. This should not fail.

7 минут назад, Igor сказал:

Images for C2 are broken - will be updated. You can test by building new image and update to beta. This should not fail.

In other words, is this a problem in the source image itself (the generation script does not have execution rights in it) ?

 

Is it possible for those who already use these images to write a simple command, what should  do before starting the update (add execution rights to the script) ?

8 minutes ago, balbes150 said:

Is it possible for those who already use these images to write a simple command, what should  do before starting the update (add execution rights to the script) ?

Probably this will do:

chmod -v +x /etc/kernel/postinst.d/initramfs-tools

I'll try to test this evening on my C2 too

Enviado desde mi moto g(6) plus mediante Tapatalk

1 час назад, Igor сказал:

Probably this will do:

Still as an option for such or similar cases. When installing updates, they are installed alphabetically (without dependencies). You can create hot-fix packages (with the name that will be installed first) and put them in repositories. When users run the update, the patch package will be launched first, and the subsequent installation of the remaining packages (which require a pre-patch on the production system) will run in the correct environment.

lose

 

|| exit

 

https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L559

I tested on my board, and no SD card corruption either, after installing the whole desktop packages

root@odroidc2:~# uname -r
5.9.8-meson64
root@odroidc2:~# dpkg -l|grep meson
ii  linux-dtb-current-meson64             20.11.0-trunk.31                     arm64        Linux DTB, version 5.9.8-meson64
ii  linux-image-current-meson64           20.11.0-trunk.31                     arm64        Linux kernel, version 5.9.8-meson64

@IgorYour C2 seems to have a similar problem to my Renegade: I can use mainline images, or old legacy images with no problem. But recent legacy images cause SD corruption in a matter of seconds. Still don't know the cause, and no other people seem to have the same problem.

 

I remember that @Da Xue commented about this problem that these TVbox SoC's have a SD card interface that is meant for storage, not for holding the OS, and hence they are not as reliable as EMMC.

Releasing 20.11 this week with those exceptions:

 

Images for sunxi kernels will be build from repository (5.8.y)

Any other hack?

Hi - Is following new in Tamandua ( and images that are built from scratch currently ) ?

Any flag to disable this so US would be default ( as it used to be ) and thus following won't be asked/ set?

 

New to Armbian? Documentation: https://docs.armbian.com Support: https://forum.armbian.com

New root password: ********
Repeat password: ********
Detected timezone: Europe/Bucharest (EET, +0300)
Generating locales: ro_RO.UTF-8
Adding console keyboard layout: ro

Creating a new user account. Press <Ctrl-C> to abort

 

3 hours ago, dolphs said:

Any flag to disable this

Not sure if there is some flag you can set in /boot/armbian_first_run.txt (let's wait for some of the boot experts to answer).

 

In the meantime, a quick workaround is simply starting the board with no Internet connection, and it will skip the locale auto-detecting.

4 hours ago, dolphs said:

Any flag to disable this so US would be default

US remains default for root, user is getting locales settings and keyboard is added, not replaced. We can add to the user creation part ... "Do you want to set XX language for user Joe?"

Looks like updating " /etc/default/keyboard " would be sufficient then to roll things back : " sed -i 's/us,ro/us/g' /etc/default/keyboard ".

I'd propose to have this manually controlled ( thru personal settings in armbian-config ) and leave "us" default.

 

cat /etc/default/locale # looks fine default

#  File generated by update-locale
LC_MESSAGES=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LANG=en_US.UTF-8
 

 

Does anyone have Rock64 available to perform a small check on the ability to start the system ?

16 minutes ago, balbes150 said:

Does anyone have Rock64 available to perform a small check on the ability to start the system ?

Yes I have a rock64 v2

4 минуты назад, lanefu сказал:

Yes I have a rock64 v2

You can check the General launch of one of the desktop images from this link to Rock64 and (if possible) show the output of the UART log ? I am interested in two options for starting-do not change anything after recording and the second, change the dtb to rock64.

 

https://users.armbian.com/balbes150/firefly_station_m1/ArmbianTV/

Perhaps this is already known and fixed, then delete this message. I tried the latest oficial image of Focal desktop 20.11 for RockPi 4B on my RockPi 4B and I didn't have the analog sound working. Replacing the "asound.state" file with the link solved the problem.

 

https://yadi.sk/d/oTvekr3h1e3kjw

 

By the way, I found an interesting nuance. I tried the latest version of the Firefly Station P1 20201129 image

 

https://yadi.sk/d/49cyK_iRLTrA8A?w=1

 

and it runs from the SD card without any problems. I have a u-boot in SPI, and running the official version from the SD card does not work (not the correct launch of u-boot from the SD card , perhaps due to the interaction of u-boot on the SD card and the existing u-boot in SPI). But the P1 version works fine from the SD card regardless of whether there is a u-boot in SPI. It would be interesting to check the launch on other RockPI 4A\B\C to check the operation of analog audio and u-boot. If anyone has the opportunity to check, I would appreciate the results.

 

 

34 minutes ago, balbes150 said:

RockPi 4B and I didn't have the analog sound working

That's true. It needs some alsamixer tinkering to get the sound working without the file you provided.

 

37 minutes ago, balbes150 said:

I have a u-boot in SPI, and running the official version from the SD card does not work

Do I get it right that you are talking about ROCK Pi 4B running official Armbian image (for ROCK Pi 4B) with Radxa's u-boot in SPI?

 

It does not work. It is the incompatibility between v2017.09 u-boot based on Rockchip blobs (Radxa SPI) and v2020.07 u-boot (TPL/SPL/proper) with FIT packaging for BL31 blob (Armbian ROCK Pi 4A/B/C)

I recommend writing Armbian mainline u-boot to SPI which is compatible with Radxa's OS images.

One needs to enable spi-jedec-nor overlay and use nand-sata-install or armbian-config to write u-boot to SPI.

I will document the procedure in the download page.

19 часов назад, piter75 сказал:

That's true. It needs some alsamixer tinkering to get the sound working without the file you provided.

Before that, do users have to sit without working analog audio ?

 

19 часов назад, piter75 сказал:

Do I get it right that you are talking about ROCK Pi 4B running official Armbian image (for ROCK Pi 4B) with Radxa's u-boot in SPI?

Yes

 

Скрытый текст

 

U-Boot 2017.09-00010-g18c70dba63-dirty (Mar 06 2020 - 19:14:22 +0300)

Model: Radxa ROCK Pi 4
PreSerial: 2
DRAM:  2 GiB
Relocation Offset is: 7dbd2000
Sysmem: init
I2c speed: 400000Hz
PMIC:  RK808
vdd_center 900000 uV
vdd_cpu_l 900000 uV
vdd-log init 950000 uV
MMC:   dwmmc@fe320000: 1, sdhci@fe330000: 0
Using default environment

Model: Radxa ROCK Pi 4
dcache off

 

 

19 часов назад, piter75 сказал:

It does not work. It is the incompatibility between v2017.09 u-boot based on Rockchip blobs (Radxa SPI) and v2020.07 u-boot (TPL/SPL/proper) with FIT packaging for BL31 blob (Armbian ROCK Pi 4A/B/C)

Works. This is the system startup log from the SD card.

Скрытый текст

 

U-Boot 2020.07-armbian (Nov 29 2020 - 18:58:55 +0300)

SoC: Rockchip rk3399
Reset cause: POR
Model: Firefly ROC-RK3399-PC Mezzanine Board
DRAM:  2 GiB
PMIC:  RK808
MMC:   mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPI Flash... unrecognized JEDEC id bytes: 0b, 40, 16
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

In:    serial
Out:   vidconsole
Err:   vidconsole
Model: Firefly ROC-RK3399-PC Mezzanine Board
Net:   eth0: ethernet@fe300000
Hit any key to stop autoboot:  0
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3c0000: USB EHCI 1.00
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 1 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
3185 bytes read in 7 ms (444.3 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
250 bytes read in 5 ms (48.8 KiB/s)
15756439 bytes read in 669 ms (22.5 MiB/s)
27574784 bytes read in 1168 ms (22.5 MiB/s)
74642 bytes read in 13 ms (5.5 MiB/s)
2698 bytes read in 10 ms (262.7 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    15756375 Bytes = 15 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to 79015000, end 79f1bc57 ... OK
   Loading Device Tree to 0000000078f9a000, end 0000000079014fff ... OK

Starting kernel ...

 

 

 

19 часов назад, piter75 сказал:

I recommend writing Armbian mainline u-boot to SPI which is compatible with Radxa's OS images.

Why should I change the working version in SPI (which suits me and has all the functionality I need , including full launch from USB media)? I am happy with the existing full working version, which works perfectly with the current u-boot in SPI (including analog sound on my RockPi 4B).

@Igor The Rockpi-4b legacy image that I download from the webpage causes a kernel panic on boot, while the one I build from trunk does not. I am using a v1.3 (with no SPI), it looks like @piter75 pushed some fix in the last minute to avoid this issue. Is it possible that the download images were built before this commit?

8 minutes ago, JMCC said:

Is it possible that the download images were built before this commit?

 

Can't really be sure without deep investigation, which is more work than if I just push out images update for rockpi* 

1 minute ago, Igor said:

just push out images update for rockpi

Sure

 

23 hours ago, piter75 said:

That's true. It needs some alsamixer tinkering to get the sound working without the file you provided.

Yesterday test was with local minimal build (which does not have alsa-utils installed) and hence the audio enablement script you provided did not work on boot.

Retested with official image (Armbian_20.11_Rockpi-4b_buster_current_5.9.10.img.xz) and analog sound works out of the box.

 

1 hour ago, balbes150 said:

Why should I change the working version in SPI (which suits me and has all the functionality I need , including full launch from USB media)?

To make some NVMe drives working which are known for not working with official SPI.

 

But... I do see your point.

I will try to make the mainline SPI / NVMe combo available without breaking compatibility with existing installations of Radxa SPI.