NitinValeo wrote: ↑Mon Jan 28, 2019 6:52 amWhich Raspberry Pi board support ARM v8A (AArch64) Architecture, is there any board with core as ARM A53 and AArch64 support.
Yes. I like it too.
The problem with having Raspbian go to 64 bit is that it would mean that either the RPF would have to support two versions (which would be expensive), or it would break compatibility older Pi and the current Pi0/Pi0W.NitinValeo wrote: ↑Tue Jan 29, 2019 7:41 amAccording to the link below from ARM, it says "The only real drawback is the current user space of Raspbian is AArch32 and not AArch64."
https://community.arm.com/tools/b/blog/ ... 1546423942
Raspbian doesn't support AArch64, can we get support to install AArch64 kernel in the raspberry pi board?
NitinValeo wrote: ↑Tue Jan 29, 2019 7:41 amAccording to the link below from ARM, it says "The only real drawback is the current user space of Raspbian is AArch32 and not AArch64."
https://community.arm.com/tools/b/blog/ ... 1546423942
Raspbian doesn't support AArch64, can we get support to install AArch64 kernel in the raspberry pi board?
sakaki wrote: ↑Tue Jan 29, 2019 1:07 am...
Installing a 64-bit Kernel
...
To get it, open a terminal on your RPi3, and issue (as the regular pi user):(You can find the most up-to-date kernel package wget string here (it is automatically updated each week by the buildbot); but the above version should work fine.)Code: Select all
pi@raspberrypi: ~ $ wget -c https://github.com/sakaki-/bcmrpi3-kernel-bis/releases/download/4.14.93.20190115/bcmrpi3-kernel-bis-4.14.93.20190115.tar.xz
Now, 'hold' the existing 32-bit raspberrypi-kernel package, to prevent its files being modified during future "apt-get upgrade" runs (which could overwrite the dtbs we're about to install):Now store off the existing device-tree blobs:Code: Select all
pi@raspberrypi:~ $ sudo apt-mark hold raspberrypi-kernel
There is no need to back up the 32-bit kernel itself, nor its modules, as the names of these will not clash with their 64-bit counterparts.Code: Select all
pi@raspberrypi:~ $ sudo mkdir -pv /boot/r32-dtbs pi@raspberrypi:~ $ sudo mv -v /boot/*.dtb /boot/r32-dtbs/
With that done, you can safely deploy the 64-bit kernel! This simply requires an untar:Note that this won't 'clobber' any existing files (other than the DTBs, which we just backed up) - it writes:Code: Select all
pi@raspberrypi: ~ $ sudo tar --exclude='COPYING.linux' \ -xJf bcmrpi3-kernel-bis-4.14.93.20190115.tar.xz -C / pi@raspberrypi: ~ $ sync
Other than the DTBs, none of these will be present in the baseline 32-bit Raspbian image you have just installed.
- a bootable 64-bit kernel to /boot/kernel8.img;
- the kernel's config to /boot/config;
- the kernel's to symbol table to /boot/System.map;
- a set of DTBs to /boot/<devname>.dtb; and
- a matching module set into /lib/modules/<kernel release name>.
Lastly, make a backup of the new device tree blobs too, for ease of rollback later:That's it! You now have a 64-bit kernel (and corresponding module set) installed, and your RPi3 will automatically try to use in preference to the (Raspbian-supplied) 32-bit kernel, where present.Code: Select all
pi@raspberrypi:~ $ sudo mkdir -pv /boot/r64-dtbs pi@raspberrypi:~ $ sudo cp -v /boot/*.dtb /boot/r64-dtbs/
So next, reboot your RPi3. With luck, you should find it now starts up into the 64-bit kernel, and then continues into (32-bit userland, vanilla) Raspbian, just as before!
You may see the message "dmi: Firmware registration failed." displayed during early boot. This may safely be ignored.
Open a terminal, and check all is well:Verify that your WiFi, Bluetooth etc. all work as before (they should do); try opening the bundled (32-bit) Chromium web browser and so forth.Code: Select all
pi@raspberrypi:~ $ uname -a pi@raspberrypi:~ $ file $(which ls) pi@raspberrypi:~ $ lsmod
Here's a screenshot of an RPi3 B+ at this stage in the process (your lsmod output etc. may vary slightly):
Notice how the kernel ("uname -a") is aarch64, the vc4 driver module is loaded, and the userland (as shown, for example, by the "file $(which ls)" command) is aarch32.
...
Running ARM32 programs against an ARM64 kernel is possible. However, you may want to use a chroot to install and run these programs under.
Code: Select all
wget http://cdimage.ubuntu.com/ubuntu-base/bionic/daily/current/bionic-base-armhf.tar.gz
mkdir ubuntu_chroot
tar -C ubuntu_chroot -xvzf bionic-base-armhf.tar.gz
sudo mount -o bind /proc ubuntu_chroot/proc
sudo mount -o bind /dev ubuntu_chroot/dev
sudo mount -o bind /dev/pts ubuntu_chroot/dev/pts
sudo mount -o bind /sys ubuntu_chroot/system
sudo cp /etc/resolv.conf ubuntu_chroot/etc/resolv.conf
sudo chroot ubuntu_chroot
Code: Select all
export DISPLAY=:0.0
Code: Select all
xhost +
Code: Select all
sudo apt install libreoffice
Code: Select all
sudo mount -o bind /proc ubuntu_chroot/proc
sudo mount -o bind /dev ubuntu_chroot/dev
sudo mount -o bind /dev/pts ubuntu_chroot/dev/pts
sudo mount -o bind /sys ubuntu_chroot/sys
sudo chroot ubuntu_chroot
Ouch, mouse, keyboard going to be an issue or is it just highspeed USB?One big but - Usb support on 64 bit kernels is iffy. Aiui the usb controller isn't the best and needs very fast interrupt handling. On 32bit this has been implemented using a fiq (arm's fast interrupt handler), but this has been deprecated in aarch64 linux.
I tried a uvc webcam yesterday. It works fine on 32 bit, but drops frames galore on 64, with anything above vga dropping >90% of frames.
When did that happen? Between 4.14 and 4.19?fiq (arm's fast interrupt handler), but this has been deprecated in aarch64 linux.
Mouse and keyboard have been fine in my testing, only high speed stuff. I haven't heard of other significant complaints other than https://github.com/raspberrypi/linux/issues/2817 where USB sound cards also misbehaved (the initially reported wifi dongle is not supportable in either 32 or 64 bit on the Pi due to too many endpoints).Gavinmc42 wrote: ↑Fri Feb 01, 2019 8:07 amOuch, mouse, keyboard going to be an issue or is it just highspeed USB?One big but - Usb support on 64 bit kernels is iffy. Aiui the usb controller isn't the best and needs very fast interrupt handling. On 32bit this has been implemented using a fiq (arm's fast interrupt handler), but this has been deprecated in aarch64 linux.
I tried a uvc webcam yesterday. It works fine on 32 bit, but drops frames galore on 64, with anything above vga dropping >90% of frames.
Ethernet too?
Anyway, it sounds like it is getting closer.
Between ARMv7 and aarch64.Gavinmc42 wrote:When did that happen? Between 4.14 and 4.19?fiq (arm's fast interrupt handler), but this has been deprecated in aarch64 linux.
What were they thinking?
Not sure if my PS2 Eyecams are fast enough to break it, lets find out![]()
I have not tried any eyecams in any aarch64 yet.
This sounds like pretty big news.6by9 wrote: ↑Fri Feb 01, 2019 7:49 am64 bit kernel under a 32 bit raspbian is working fine for me, and I'm in the process of fixing up the bits of the kernel that don't work. All the Mmal and IL apps I've tried still work with that, as the buffers passed from the 32bit app still map correctly onto the Gpu versions of those structures. The 32 bit mmal/IL framework stuff in userspace make the correct mappings for transferring data.
...
Codec support is now available on 4.19 via v4l2 as well as mmal/IL, and that does support both 32 and 64 bit apps (once I've merged the last couple of patches). Gstreamer and ffmpeg both work fine with it.
As I understand it the FIQ stuff was specific to the default dwc_otg driver. Could this mean that in aarch64 mode dtoverlay=dwc2 performs just as well or perhaps better in comparison?One big but - Usb support on 64 bit kernels is iffy. Aiui the usb controller isn't the best and needs very fast interrupt handling. On 32bit this has been implemented using a fiq (arm's fast interrupt handler), but this has been deprecated in aarch64 linux.
NB I'm on Raspbian Buster (a test image), and I'm using Full KMS.jdonald wrote: ↑Tue Feb 05, 2019 2:31 amThis sounds like pretty big news.6by9 wrote: ↑Fri Feb 01, 2019 7:49 am64 bit kernel under a 32 bit raspbian is working fine for me, and I'm in the process of fixing up the bits of the kernel that don't work. All the Mmal and IL apps I've tried still work with that, as the buffers passed from the 32bit app still map correctly onto the Gpu versions of those structures. The 32 bit mmal/IL framework stuff in userspace make the correct mappings for transferring data.
...
Codec support is now available on 4.19 via v4l2 as well as mmal/IL, and that does support both 32 and 64 bit apps (once I've merged the last couple of patches). Gstreamer and ffmpeg both work fine with it.
omxplayer -no-osd and vlc --vout=mmal_vout are working with accelerated video too? chromium-browser can play YouTube videos without spewing MMAL errors?
Possible but I suspect unlikely. I'm more than happy to be proven wrong should someone else test it.jdonald wrote:As I understand it the FIQ stuff was specific to the default dwc_otg driver. Could this mean that in aarch64 mode dtoverlay=dwc2 performs just as well or perhaps better in comparison?One big but - Usb support on 64 bit kernels is iffy. Aiui the usb controller isn't the best and needs very fast interrupt handling. On 32bit this has been implemented using a fiq (arm's fast interrupt handler), but this has been deprecated in aarch64 linux.