Hallo aus Down Under!
We are migrating one of our industrial processes to a kunbus device.
Our database for the industrial process is mongoDB. We require the 64 bit version of mongoDB. (The 32bit version has a database limit size of 2Gb)
We are testing with a Core 3 (not the Core 3 +) and a Connect + device (Article No.: 100304 (32 GB version)).
When I typed 'cat /proc/cpuinfo’ on the core 3 it returns the wrong CPU:
"BCM2835 (The data sheet says a Core 3 should have a BCM2837"
And on the Connect + it also returns the wrong CPU:
"BCM2835 (The data sheet says the Connect 3+ should have a Broadcom BCM2837B0 quad-core ARM Cortex A53, A quick google told me the BCM2837B0 is a ARM64 processor.)"
Questions:
1. Why does the CPU information display wrong model numbers in the terminal? Should I assume the + devices have the ARM64 bit processor (BCM2837B0)?
2. Is the Core 3 + and Connect + capable of running 64 bit programs? Do you know if this is possible with the revpi stretch image?
Tschüss,
Chris
Kunbus devices shows wrong CPU hardware, 64-bit capability
-
ChrisDeveloper
- Posts: 27
- Joined: 03 Mar 2020, 00:58
Re: Kunbus devices shows wrong CPU hardware, 64-bit capability
Hi Chris, have a look here, it is a known bug:
https://revolution.kunbus.de/forum/view ... info#p6168
https://revolution.kunbus.de/forum/view ... info#p6168
-
ChrisDeveloper
- Posts: 27
- Joined: 03 Mar 2020, 00:58
Re: Kunbus devices shows wrong CPU hardware, 64-bit capability
Hi Drik,
Is it possible to run ARM64 programs on the the KunBus Connect + devices?
Kind Regards,
Chris
Is it possible to run ARM64 programs on the the KunBus Connect + devices?
Kind Regards,
Chris
Re: Kunbus devices shows wrong CPU hardware, 64-bit capability
Dear Chris,
the "Hardware" in /proc/cpuinfo is BCM2835 regardless of the ARM CPU on the SoC, so it's somewhat misleading. You need to look at the "model name" instead, which will be "ARMv6 compatible processor rev 7 (v6l)" on a Compute Module 1 (BCM2835 = BCM2708) and "ARMv7 Processor rev 4 (v7l)" on a Compute Module 3/3+(BCM2837/BCM2837B0 = BCM2710). I might be mistaken but I think the "model name" is identical on the CM3 and CM3+. A proper differentiation between the two is possible via the machine model reported at the top of "dmesg", e.g. "OF: fdt:Machine model: Raspberry Pi Compute Module 3 Rev 1.0" on a CM3.
Both the CM3 and the CM3+ sport 64-bit capable ARM CPUs. The CM3+ runs cooler and has a larger eMMC.
Our RevPi stretch image is derived from the Raspberry Pi Foundation's Raspbian and the Foundation's policy is to ship only a one-size-fits-all image which covers the CM1 and PiZero on the lowest end, up to the 4B+ on the highest end. To achieve that, they run a 32-bit kernel with a 32-bit userland on a 64-bit CPU (if a BCM2837/BCM2837B0 or BCM2711 is used). Of course a 64-bit kernel and userland would be preferable because one has more registers, NEON extensions, proper ASLR and so on.
If you overwrite the pre-installed Raspbian on the eMMC with a 64-bit image, e.g. Ubuntu, you'll be able to use the CPU's 64-bit capabilities. Note that if you want to use the RTC, crypto chip, LEDs and PiBridge/ConBridge, you'll need to copy the devicetree overlay for the specific RevPi product you're using from our kernel deb-package to /boot/overlays on your 64-bit machine and you'll have to amend /boot/config.txt to load that devicetree overlay. To access PiBridge modules you'll also have to compile our out-of-tree piControl module (which is on GitHub) against the 64-bit kernel you're using. I've covered this in slightly more detail here.
We've decided to stick with Raspbian because that's what most people are used to if they're familiar with the Raspberry Pi. We're thinking about using a 64-bit kernel on the CM3/CM3+ in the long run, but there's quite a bit of work to do to achieve that: E.g., we currently use an optimized driver for the USB host controller which was developed by the Foundation and which takes advantage of the ARM CPU's FIQ fast interrupt. The Foundation never bothered porting that feature to 64-bit, so we'll have to do it ourselves.
Does this answer your questions? Let us know if not. Thanks!
the "Hardware" in /proc/cpuinfo is BCM2835 regardless of the ARM CPU on the SoC, so it's somewhat misleading. You need to look at the "model name" instead, which will be "ARMv6 compatible processor rev 7 (v6l)" on a Compute Module 1 (BCM2835 = BCM2708) and "ARMv7 Processor rev 4 (v7l)" on a Compute Module 3/3+(BCM2837/BCM2837B0 = BCM2710). I might be mistaken but I think the "model name" is identical on the CM3 and CM3+. A proper differentiation between the two is possible via the machine model reported at the top of "dmesg", e.g. "OF: fdt:Machine model: Raspberry Pi Compute Module 3 Rev 1.0" on a CM3.
Both the CM3 and the CM3+ sport 64-bit capable ARM CPUs. The CM3+ runs cooler and has a larger eMMC.
Our RevPi stretch image is derived from the Raspberry Pi Foundation's Raspbian and the Foundation's policy is to ship only a one-size-fits-all image which covers the CM1 and PiZero on the lowest end, up to the 4B+ on the highest end. To achieve that, they run a 32-bit kernel with a 32-bit userland on a 64-bit CPU (if a BCM2837/BCM2837B0 or BCM2711 is used). Of course a 64-bit kernel and userland would be preferable because one has more registers, NEON extensions, proper ASLR and so on.
If you overwrite the pre-installed Raspbian on the eMMC with a 64-bit image, e.g. Ubuntu, you'll be able to use the CPU's 64-bit capabilities. Note that if you want to use the RTC, crypto chip, LEDs and PiBridge/ConBridge, you'll need to copy the devicetree overlay for the specific RevPi product you're using from our kernel deb-package to /boot/overlays on your 64-bit machine and you'll have to amend /boot/config.txt to load that devicetree overlay. To access PiBridge modules you'll also have to compile our out-of-tree piControl module (which is on GitHub) against the 64-bit kernel you're using. I've covered this in slightly more detail here.
We've decided to stick with Raspbian because that's what most people are used to if they're familiar with the Raspberry Pi. We're thinking about using a 64-bit kernel on the CM3/CM3+ in the long run, but there's quite a bit of work to do to achieve that: E.g., we currently use an optimized driver for the USB host controller which was developed by the Foundation and which takes advantage of the ARM CPU's FIQ fast interrupt. The Foundation never bothered porting that feature to 64-bit, so we'll have to do it ourselves.
Does this answer your questions? Let us know if not. Thanks!
