Igor Posted November 19, 2020 Posted November 19, 2020 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.
balbes150 Posted November 19, 2020 Posted November 19, 2020 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).
Igor Posted November 19, 2020 Posted November 19, 2020 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.
balbes150 Posted November 19, 2020 Posted November 19, 2020 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) ?
Igor Posted November 19, 2020 Posted November 19, 2020 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
JMCC Posted November 19, 2020 Posted November 19, 2020 I'll try to test this evening on my C2 tooEnviado desde mi moto g(6) plus mediante Tapatalk
balbes150 Posted November 19, 2020 Posted November 19, 2020 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.
balbes150 Posted November 19, 2020 Posted November 19, 2020 lose || exit https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L559
JMCC Posted November 19, 2020 Posted November 19, 2020 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.
Igor Posted November 23, 2020 Posted November 23, 2020 Releasing 20.11 this week with those exceptions: Images for sunxi kernels will be build from repository (5.8.y) Any other hack?
dolphs Posted November 25, 2020 Posted November 25, 2020 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
JMCC Posted November 25, 2020 Posted November 25, 2020 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.
Igor Posted November 25, 2020 Posted November 25, 2020 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?"
dolphs Posted November 25, 2020 Posted November 25, 2020 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
balbes150 Posted November 28, 2020 Posted November 28, 2020 Does anyone have Rock64 available to perform a small check on the ability to start the system ?
lanefu Posted November 28, 2020 Posted November 28, 2020 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
balbes150 Posted November 28, 2020 Posted November 28, 2020 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/
balbes150 Posted November 29, 2020 Posted November 29, 2020 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.
piter75 Posted November 29, 2020 Posted November 29, 2020 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.
balbes150 Posted November 30, 2020 Posted November 30, 2020 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).
JMCC Posted November 30, 2020 Posted November 30, 2020 @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?
Igor Posted November 30, 2020 Posted November 30, 2020 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*
JMCC Posted November 30, 2020 Posted November 30, 2020 1 minute ago, Igor said: just push out images update for rockpi Sure
piter75 Posted November 30, 2020 Posted November 30, 2020 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.
Recommended Posts