Status of armhfp grubs2-efi on top of Uboot
by Mark Verlinde
Hi,
A while ago (around the freeze of FC29) grub2-efi on top of Uboot was proposed as the (potentially) default setup for armhfp too. Unfortunately (IMHO) it did not materialize and I'm searching for the game-breaker.
On buggzilla found a few hints, " we have at least a grub2 <-> kernel bug" (1) among them, they did not make the holdup clear to me.
My investigation so-far:
* It works pretty good with a close to upstream build grub, not with the default gub2 packages. Which makes me believe loading an arm32 kernel as an Portable Executable instead of grub's LoadImage() and StartImage() services may be a game-stopper. NOTE : I understand this is necessary for chain loading efi stubs for secure-boot. IMO this is not the pursued goal here.
* Since kernel patch "efi: libstub/arm: account for firmware reserved memory at the base of RAM" (2) it works on RPI's too (given a "custom" build grub2)
All feedback is appreciated,
grtz Mark
1) https://bugzilla.redhat.com/show_bug.cgi?id=1602948
2) https://patchwork.kernel.org/patch/11189097/
3 years, 1 month
CMA on raspberry pi 4
by Thomas H.P. Andersen
Hi,
I have looked into the CMA setting issue a bit. This is what I have found
so far.
The rpi4 needs CMA to be in ZONE_DMA (lower 1GB of memory) as this is the
only area that the peripherals on the rpi4 can address.
The DT sets the allowed range to allocate the CMA from (
arch/arm/boot/dts/bcm2711.dtsi#L869
<https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/bcm2711.d...>),
but it seems to not work here. What does work is instead to set the offset
manually. I replaced "cma=256MB" with "cma=256M@704M" and then it boots.
Note that it has to be 256M instead of 256MB.
Removing the cma option on the command line was known as a workaround.
Without that we would fall back to the build config of 64MB cma which was
located at offset 0x38000000. This left 64MB at the end of ZONE_DMA, and I
chose offset 704M so that those 64MB would still be free. Not sure if that
is needed or not. The crashkernel needs to be in ZONE_DMA as well but it
seems to be set to 0 size.
I have tested on 5.7 rc2 from rawhide.
This probably belongs in a bug report. What would be the correct place to
file that? From what I can tell upstream has been tested with cma settings
without problems (as long as the requested CMA size can fit in ZONE_DMA).
From that it seems like fedora-specific issue. Not sure though.
Cheers,
Thomas
3 years, 4 months
Pine64 Realtek Wifi
by brm
Hi all. OS is 5.7.8-200.fc32.aarch64 Fedora Server running headless on Pine64
sbc. The system works well. Currently eth0 is the main network device, but I
have another use for this cable and wish to implement the wifi. This is
proving problematic as it seems to use the rtl8723bs module. Despite a lot of
googling there is no sign of wlan0.
Here I load the realtek module.
r8723bs: module is from the staging directory, the quality is unknown, you
have been warned.
[34784.402732] RTL8723BS: module init start
[34784.406673] RTL8723BS: rtl8723bs
v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
[34784.413770] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40
[34784.420437] RTL8723BS: module init ret =0
If I go to /usr/lib/firmware/rtlwifi - these files are present.
│-rw-r--r-- 1 root root 20886 Jun 20 02:37 rtl8723bs_ap_wowlan.bin
│
│-rw-r--r-- 1 root root 9120 Jun 20 02:37 rtl8723bs_bt.bin
│
│-rw-r--r-- 1 root root 32108 Jun 20 02:37 rtl8723bs_nic.bin
│
│-rw-r--r-- 1 root root 26398 Jun 20 02:37 rtl8723bs_wowlan.bin
I am not sure how to use these. I was hoping that modprobe would activate the
device and wlan0 would appear. But this is not the case. Any ideas?
3 years, 4 months
arm-image-installer with a qemu disk image
by Sam Varshavchik
I'm trying to install an aarch64 guest VM on F32 x86-64 host.
I created a suitably large disk image, then proceeded to:
arm-image-installer \
--image=/home/mrsam/Downloads/Fedora-Workstation-32-1.6.aarch64.raw.xz \
--target=rpi3 \
--media=/var/lib/libvirt/images/Fedora-Workstation-32-1.6.aarch64.raw \
--selinux=ON --norootpass
This churned for a while, and finished with this:
= Proceed? yes
= Writing:
= /home/mrsam/Downloads/Fedora-Workstation-32-1.6.aarch64.raw.xz
= To: Fedora-Workstation-32-1.6.aarch64.raw ….
11661295616 bytes (12 GB, 11 GiB) copied, 210 s, 55.5 MB/s
0+1339534 records in
0+1339534 records out
11811160064 bytes (12 GB, 11 GiB) copied, 210.762 s, 56.0 MB/s
= Writing image complete!
Error: mount Fedora-Workstation-32-1.6.aarch64.raw2 /tmp/boot failed
I surmize that arm-image-installer expected a real /dev to write to,
instead of what is effectively a plain fie, so it failed to mount the disk
image. I suppose that what it needs to do is a loopback mount, instead. Is
there a way to do this?
I tried to create a VM with the raw image, as is. It booted for a while, but
left me at a login prompt, demanding the root password, and I could not
proceed any further.
3 years, 4 months
i2c-tools & serial port
by ng0177＠gmail.com
Dear All,
I need to update the firmware of a fan for the RPi4 and given the below
instructions in Raspbian. I also installed
sudo dnf -y install i2c-tools
sudo dnf -y install python3-i2c-tools
but the firmware update fails. I guess, it is because of the serial port
not being enabled. Any advice?
Thanks, Thomas
In order to use bootloader, user need to have activated and free Serial
Port on Raspberry Pi®. The below
procedure is showing how to make sure that Serial Port is free and
available for Bootloader process.
sudo raspi-config
Select -> Interfacing Options
1. IC Kernel ON
2. Serial option to enable UART
Then it will ask for login shell to be accessible over Serial, select No
shown as follows.
At the end, it will ask for enabling Hardware Serial port, select Yes,
Then, reboot the Raspberry Pi®!!
3 years, 4 months
