Then you need to change to the stable FW directory in /etc/default/rpi-eeprom-update to stable and re-flash. They just promoted this to stable from beta and will be a while before it makes it to critical.
FIRMWARE_RELEASE_STATUS="stable"
Ahhh right, thank you. I guess I’m ok with the last update for now.
I’ve also updated to the stable brnach of rpi-eeprom-git.
First, reboot and nothing to say for now… I have to check if new options are available.
I don’t think you should worry a lot about this : the only python file is rpi-eerprom-config which only uses common modules (argparse,atexit,os,subprocess,struct,sys,tempfile,time) and the shebang is really safe (="#!/usr/bin/env python"). It should run on every python version.
I looked and they have not added the new things to the Doc yet. They also added something where one supposedly can point to an alternate config for a device under the sections to boot in from config.txt called try boot but I do not remember what the config line is to trigger it at the moment.
https://www.raspberrypi.org/documentation/configuration/config-txt/conditional.md
That’s the option I’ve heard and I’m looking for documentation.
I guess it’s related to this : linux/raspberrypi.c at 757666748ebf69dc161a262faa3717a14d68e5aa · raspberrypi/linux · GitHub
// ‘tryboot’: Sets a one-shot flag which is cleared upon reboot and
// causes the tryboot.txt to be loaded instead of config.txt
// by the bootloader and the start.elf firmware.
//
// This is intended to allow automatic fallback to a known
// good image if an OS/FW upgrade fails.
Looks like this is for trying out new kernels/dtbs. Have a tryboot.txt in /boot with a good boot pointing to different kernel /dtb name that is good named differently in /boot. I have no clue if it has been expanded or not from below:
Currently this just defines the ‘tryboot’ flag which causes
the firmware to load tryboot.txt instead config.txt. This
alternate configuration file can be used to specify the
path of an alternate firmware and kernels allowing a fallback
mechanism to be implemented for OS upgrades.
I did read a while back when this was proposed that it was an experiment meant for Disto dev’s to experiment with and depending on their feed back it could disappear.
At least for now, my rpis (unstable manjaro branch) seem to work with the new firmware. (1607685317)
1 Like
The update went smoothly, and now interactive editing of the config works.
$ EDITOR=nano sudo -E rpi-eeprom-config --edit
2 Likes
I saw a post today written over a week ago by a RPi github maintainer where cec was broke upstream and a PR was submitted by someone upstream and he stated it would not probably make it until kernel 5.11.
Long story short I tried to apply the 13 patches to our linux-rpi4-mainline 5.10.0 kernel in the unstable branch and it appears the RPi folks have applied the patches in their 5.10.0 tree.
If you want to test if cec works install the linux-rpi4-mainline 5.10.0 kernel in the unstable branch and test. In the PR notes it said the latest firmware needs to be also installed. When they use the term firmware it sometimes can be all over the map what they mean; depending on who is saying it:
Sometimes it is the /boot/.dtb which will get installed with the new kernel
Sometimes the /boot/.dat & /boot/.elf files which the latest are these in the unstable branch:
raspberrypi-bootloader 20201214-1
raspberrypi-bootloader-x 20201214-1
And as a last resort sometimes they may mean the eeprom needs to be flashed and right now the latest is in the unstable branch and the package is called rpi-eeprom-git 20201214-1. Of course this has to be flashed manually after installing. Also the FW DIR needs to be changed to stable in /etc/default/rpi-eeprom-update before flashing:
FIRMWARE_RELEASE_STATUS="stable"
I don’t know if it helps but since the last 5.10.1 I’ve seen 6 commits dealing with cec…
I noticed that the RPi people updated their 5.10.y tree to 5.10.1 two days ago. I would like to see what happens the first of next week with the RPi kernel before I build another kernel after upstream updates to 5.10.2 this evening.
Also I saw that they upgraded to 5.10.1 default with their firmware git (Our raspberrypi-bootloader packages) so their default kernel being of 5.10 flavor is around the corner.
I have pushed new raspberrypi-bootloader packages to the unstable branch. They have fixed the no booting issue with the pi 3 Model B boards.
raspberrypi-bootloader 20201218-1
raspberrypi-bootloader-x 20201218-1
They still have not fixed the issue of no network of any kind and no sound issue for the pi 3 Model B boards yet for kernel 5.10.0 so if you have that device you need to still stay away from the kernel 5.10.0.
Updated, all seems to be fine… except for my crashing wifi driver issue.
I pushed new linux-rpi4-mainline 5.10.1-1 and new raspberrypi-bootloader packages to the unstable branch when the mirrors sync:
linux-rpi4-mainline 5.10.1-1
linux-rpi4-mainline-headers 5.10.1-1
raspberrypi-bootloader 20201222-1
raspberrypi-bootloader-x 20201222-1
@gofree The CEC remote issue could partially be the fact that it was not enabled in the kernel. I noticed this today when making a new config for this kernel. So give it a shot and test. It is now enabled:
CONFIG_MEDIA_CEC_RC=y
wonder why kms not work(boot), but in PiOS work?
Note to pi3b users:
With the above last update the pi3b will boot with the latest 2 raspberrypi-bootloader files and also linux-rpi4-mainline 5.10.1-1 has been fixed and working:
linux-rpi4-mainline 5.10.1-1
linux-rpi4-mainline-headers 5.10.1-1
raspberrypi-bootloader 20201222-1
raspberrypi-bootloader-x 20201222-1
1 Like
Wow! If I had waited another day I would have saves myself some time. The RPi folks pushed another upgrade today.
I have pushed the new linux-mainline 5.10.2 and the latest 2 raspberrypi-bootloader packages to the unstable branch when the mirrors sync.
I have also tested these packages on the pi3 Model B here and they still did fine.
linux-rpi4-mainline 5.10.2-1
linux-rpi4-mainline-headers 5.10.2-1
raspberrypi-bootloader 20201223-1
raspberrypi-bootloader-x 20201223-1
1 Like
I did a fresh install of KDE Plasma today and then changed from fkms to the kms, rebooted and I had v3d. Simple as that. Performance was poor on a 4k monitor, so I upgraded to mainline (5.9.12) and performance was greatly improved. Quite usable with the newer kernel.
1 Like