jdonald
Posts: 266
Joined: Fri Nov 03, 2017 4:36 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 04, 2019 7:56 pm

sakaki wrote:
Mon Feb 04, 2019 12:34 pm
how does the 32-bit shell user even get to the point of trying to invoke a 64-bit app in the first place (in order for the binfmt handler to then pick it up)? Would you propose they be navigating inside the /var/lib/machines/debian-stretch-64 folder?
This wouldn't happen much with the existing image, but it would be a more natural use case after you implement:
sakaki wrote:
Sat Feb 02, 2019 3:52 pm
I'm also going to make the whole of /home bind-mounted into the container.
Could you share some links to the Wine/QEMU guides you mentioned, so I can get a better idea?
I last saw a manual binfmt in this post. On inspection it might only be making wine:i386 behave properly and not actually make Windows executables launch directly as I hoped, although I believe such should be entirely possible to implement. A non-QEMU example: The wine-binfmt package, available on x86 systems, is closer to what I'd imagine for automatically relaunching an application. A non-Wine example: In the raspbian-multiarch repo I manually copy in a binfmt for emulation if installed on a Pi 2.
[*]Applications in the 64-bit guest need a little manipulation to be launched via the host GUI.
Understood that this is nontrivial and can be saved for a future release. Thanks for considering!
(Of course, if the PATH were augmented as per point 1 then maybe this could all happen automagically via binfmt_misc, provided no absolute paths are in the guest's destkop files of course).
That could work sometimes, but would result in strange behavior if someone installs both the 32-bit and 64-bit version of an application. For a system like this that's actually a normal use case when troubleshooting or benchmarking 64-bit applications.

A daemon that watches the guest folder and creates shadow copies on the host sounds reasonable to me.

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 04, 2019 10:23 pm

jdonald wrote:
Mon Feb 04, 2019 7:56 pm
A daemon that watches the guest folder and creates shadow copies on the host sounds reasonable to me.
Yes, agreed, this seems like the most feasible way forward. I'm going to try to implement some version of this for the next release.

Thanks again for taking the time to provide feedback (as this is another idea that wouldn't have occurred to me without your input)!

Best,

sakaki

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 04, 2019 11:21 pm

6by9 wrote:
Mon Feb 04, 2019 1:26 pm
AFAICT The USB issues will be present on ALL 64 bit kernels - it's not something that only affects 4.19. If someone would confirm that then it would be a useful data point.

I'm just creating the PRs to enable all the extra modules for camera drivers etc in bcmrpi3-defconfig.
Looking at your bcmrpi3-kernel-bis diffs, it is curious that CONFIG_IPVLAN is missing from bcmrpi3_defconfig when it's in the 32bit configs, so I'll tuck that one in as well.
I will double check - USB perf seemed markedly worse to me on my 4.19 working copy of gentoo-on-rpi3-64bit wrt 4.14-based 1.3.1 image, but I will go back and look at this properly now given your comments; might have been some userspace issue.

Good catch on CONFIG_IPVLAN btw; it appears to be dependent upon CONFIG_NET_L3_MASTER_DEV, which in turn is set to n by default under bcmrpi3_defconfig for arm64.

Best,
sakaki

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 05, 2019 11:59 am

sakaki wrote:
Mon Feb 04, 2019 11:21 pm
6by9 wrote:
Mon Feb 04, 2019 1:26 pm
AFAICT The USB issues will be present on ALL 64 bit kernels - it's not something that only affects 4.19. If someone would confirm that then it would be a useful data point.

I'm just creating the PRs to enable all the extra modules for camera drivers etc in bcmrpi3-defconfig.
Looking at your bcmrpi3-kernel-bis diffs, it is curious that CONFIG_IPVLAN is missing from bcmrpi3_defconfig when it's in the 32bit configs, so I'll tuck that one in as well.
I will double check - USB perf seemed markedly worse to me on my 4.19 working copy of gentoo-on-rpi3-64bit wrt 4.14-based 1.3.1 image, but I will go back and look at this properly now given your comments; might have been some userspace issue.
That would be useful to know.
Are you using the downstream dwc_otg driver, or the upstream dwc2 one?
sakaki wrote:Good catch on CONFIG_IPVLAN btw; it appears to be dependent upon CONFIG_NET_L3_MASTER_DEV, which in turn is set to n by default under bcmrpi3_defconfig for arm64.
Difference between 4.14 and 4.19.

Code: Select all

  │ Symbol: IPVLAN [=n]                                                                                                                                                         │  
  │ Type  : tristate                                                                                                                                                            │  
  │ Prompt: IP-VLAN support                                                                                                                                                     │  
  │   Location:                                                                                                                                                                 │  
  │     -> Device Drivers                                                                                                                                                       │  
  │       -> Network device support (NETDEVICES [=y])                                                                                                                           │  
  │ (1)     -> Network core driver support (NET_CORE [=y])                                                                                                                      │  
  │   Defined at drivers/net/Kconfig:149                                                                                                                                        │  
  │   Depends on: NETDEVICES [=y] && NET_CORE [=y] && INET [=y] && (IPV6 [=m] || !IPV6 [=m]) && NETFILTER [=y]                                                                  │  
  │   Selects: NET_L3_MASTER_DEV [=n]                                                                                                                                           │  
So on 4.19 it will select NET_L3_MASTER_DEV automatically, it's not dependent on it. Thank 218798f "ipvlan: selects master_l3 device instead of depending on it"

Sorry, I'm only worrying about 4.19 now. Others can fix up 4.14 if they are that fussed about it.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Wed Feb 06, 2019 12:29 pm

6by9 wrote:
Tue Feb 05, 2019 11:59 am
sakaki wrote:
Mon Feb 04, 2019 11:21 pm
6by9 wrote:
Mon Feb 04, 2019 1:26 pm
AFAICT The USB issues will be present on ALL 64 bit kernels - it's not something that only affects 4.19. If someone would confirm that then it would be a useful data point.

I'm just creating the PRs to enable all the extra modules for camera drivers etc in bcmrpi3-defconfig.
Looking at your bcmrpi3-kernel-bis diffs, it is curious that CONFIG_IPVLAN is missing from bcmrpi3_defconfig when it's in the 32bit configs, so I'll tuck that one in as well.
I will double check - USB perf seemed markedly worse to me on my 4.19 working copy of gentoo-on-rpi3-64bit wrt 4.14-based 1.3.1 image, but I will go back and look at this properly now given your comments; might have been some userspace issue.
That would be useful to know.
Are you using the downstream dwc_otg driver, or the upstream dwc2 one?
So I've tried your Gentoo image - my Logitech C270 webcam is just as bad there as it is with 4.19.
The logging with the latest v4l-ctl is a little more useful in that it tells you when frames are dropped based on missed sequence numbers. It rebuilds quite easily from source ("git clone git.linuxtv.org/v4l-utils.git", "cd v4l-utils", "./bootstrap.sh", "./configure", "make -j2")

Pushing my 4.19.19-v8 build onto that image and running Full KMS it boots fine.
Same sort of performance with the webcam, so I don't think there is a regression there.
My main test is "v4l2-ctl -v width=320,height=240,pixelformat=YUYV", "v4l2-ctl --stream-mmap=3 --stream-count=1000 --stream-to=/dev/null" and observe the variability in the number of < symbols (one for each frame received, new line every second).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Wed Feb 06, 2019 2:25 pm

6by9,

many thanks for checking that - I've been tied up with various day-job stuff the last couple of days ><, but will have a proper look at this over the weekend. From what you've written, most likely a userspace issue that was causing the USB performance differences I had observed on my working copy version of the Gentoo image.

Best, sakaki

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sun Feb 10, 2019 7:07 pm

Hello,

I've just released v1.1.0 of the bootable image on GitHub, here.

As before, you can burn the image (~925MiB compressed) to a microSD card (>=8GB), then boot your RPi3 from it directly (the root partition will be automatically resized to fill the card on first boot, per the standard Raspbian flow). Full instructions for download and use are provided on the project's GitHub page.

With this version of the image, it's now really easy to try out 64-bit applications from the Debian Stretch repository, while remaining in a familiar 32-bit (userland) Raspbian environment!

For example, say you wanted to try out the 64-bit Chromium web browser. Begin by downloading and booting the image onto a spare microSD card, following the instructions on the project's GitHub page.

After two minutes or so (subsequent boots are much faster), you should be presented with the usual Raspbian first-time setup wizard:
Image

Follow this through as you would for a standard Raspbian startup, making sure to setup networking when prompted, and to reboot when prompted, once the software update step has been completed.

When your RPi3 comes back up, select System Tools -> Terminal (64-bit), and a container shell terminal should open. There's nothing to configure or set up; it's ready for use immediately!
Image

Issue sudo apt-get update in this 64-bit container shell, followed by sudo apt-get install -y chromium, exactly as you would if using a 32-bit terminal:
Image

Once the install completes, a menu item for your new package will automatically appear in the host desktop (new v1.1.0 image feature ^-^):
Image

Just click on that menu item, and your 64-bit Chromium browser will open!
Image

And that's it! Programs you install this way have full access to your home directory, and can play video and audio on the host desktop. You can, of course, still install and use 32-bit apps from the standard Raspbian repository, just as you would before (use a regular, 32-bit terminal window when installing these, of course!)

64-bit integration with less of the headache ^-^

Further details of how all this works under the covers may be found on the project's GitHub page, and in my detailed tutorial, here.

Changes in this Release

Following suggestions from jdonald and others, this version features the following changes:
  • Kernel upgraded to 4.14.97-v8-0448a1dbea0f-bis+. The bcm2835-unicam module has been included (but not loaded by default at boot).
  • Added a systemd path unit and triggered script (/usr/local/bin/reflect-apps), to watch for changes to /usr/share/applications within the container. When triggered, copies all .desktop files across to the host, prefixing their names to ensure they are unique, and also modifying their Exec= stanzas (with ds64-runner or ds64-shell -c, as appropriate) to allow direct invocation from a 32-bit context. Desktop files without Type=Application are ignored, and any prior desktop files at the target location in the host, which have NoDisplay=true set, will not be overwritten. Also copies contents of /usr/share/{icons,pixmaps} from the guest into the host (to /usr/share/gdm/{icons,pixmaps}), so (most) referenced icons will resolve, and reloads the (host's) main menu, so these changes are picked up. 32-bit and 64-bit variants of the same package may co-exist; their menu items will not clash. Launching of terminal-based applications (such as htop) is also (automatically) supported.
    The net effect of this script is that when a new 64-bit application is apt-get installed in the guest, a menu entry to launch it (so it can play audio, display on the desktop etc.) should 'auto-magically' get added to the 32-bit Raspbian host's main menu, complete with icon. Such items will also be automatically removed should the package subsequently be uninstalled. Please note that the script will wait for all apt-get, apt and dpkg processes to complete before making modifications.
    Here's an example of installing 64-bit abiword, and then running it via the auto-created menu entry:
    Image
  • Added a systemd path unit and triggered script (/usr/local/bin/reflect-passwd), to watch for changes to /etc/{passwd,shadow,group,gshadow) within the host. When triggered, reflects user data (including hashed passwords) in the 1000 <= uid < 1100 range into the container, ensuring that the primary group is also present. Removes clashing users or groups from the guest, and ensures that reflected users are members of groups cited in $USE_GROUP (see the script for details), iff such groups are present on the guest.
    The net effect of this script is that if you change password or username, or create a new (regular) user on the host, it should 'auto-magically' be carried over into the guest as well. No equivalent propagation of changes from guest to host is provided.
  • Made all members of the sudo group (in both host and guest) eligible for password-free invocation of all commands (not just the pi user).
  • All of /home is now mapped into the container, not just /home/pi.
  • Migrated 64-bit utility .desktop files from pi's ~/.local/share/applications directory, to /usr/local/share/applications, as they may now be used by other regular users, not just pi.
  • Removed hardcoded 1000 uid and gid from /usr/local/bin/ds64-run and /usr/local/sbin/ds64-shell (the pi user is no longer 'special'; now any regular user you create can access the container, and launch apps from it).
  • Allowed passing of parameters to ds64-shell (so it can be used to e.g. launch terminal-based 64-bit apps from the guest, such as htop etc.)
  • Various other minor clean-ups.
I think these changes make the image considerably more user-friendly. If you get a chance to try it out, please let me know what you think!

Best,

sakaki

PS: if anyone out there would be interested in maintaining this image going forward, and possibly packaging the various components within it as debs, and/or adapting it to host other 'containerized' 64-bit distros (Arch, etc.) please let me know in this thread! Debian's not really my thing ><

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5758
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 11, 2019 8:08 am

Very clever set of updates. Happy to package things up for you if you point to the list of files which needs to be installed and where they're hosted.

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 11, 2019 7:59 pm

ShiftPlusOne wrote:
Mon Feb 11, 2019 8:08 am
Very clever set of updates. Happy to package things up for you if you point to the list of files which needs to be installed and where they're hosted.

Wow, thanks ShiftPlusOne!

Well, as to packaging, as I see it there are perhaps three broad options.

The first would be to slurp everything (kernel, container userland and host userland deltas) into a single "mega-deb" that would, if installed on a baseline ("with desktop") Raspbian system, turn it into the above image, essentially. Easiest to do, but probably not ideal from a maintenance point of view going forward.

The second would be to go full "constructivist", aiming for a package or set of packages that could trigger the necessary debootstrap, possibly even a from-source 64-bit kernel build, against some form of meta-config. Nice but too much work and a bit "false generality" at this stage imho. So...

The third option, which is probably the one to go for, would be to split things out into maybe three packages:
  1. A 64-bit binary kernel package. This would switch out the current raspberrypi-kernel presumably. I have an autobuild for the (aarch64) kernel used on the image (and also on my Gentoo one) here on Github (the builds are based upon bcmrpi3_defconfig, but with some tweaks applied; incidentally there is also anther autobuild project here, which provides a pure-vanilla bcmrpi3_defconfig build). The weekly releases are simply tarballs from which the kernel8.img, dtbs, config, System.map and module set may easily be extracted (details on the bcmrpi3-kernel-bis page). I guess in time (given e.g. 6by9's work) you may wish to have an official or semi-official 64-bit kernel package available, so splitting this out as a subunit would seem to make sense.
  2. The Debian Stretch 64-bit guest "container" package. All the "container-side" (aarch64) userland files. As a design goal, this is only very lightly modified from the output of the base debootstrap (but with a few additional packages, including firefox-esr, zenity, systemd-container, pulseaudio; I cover the process involved in my write-up here). I've uploaded the contents of the v1.1.0 image's container root filesystem here, this should be unpacked to /var/lib/machines/debian-stretch-64 (so that e.g. /var/lib/machines/debian-stretch-64/etc is a valid path).
  3. The host "container support" package. All the non-vanilla host-side userland parts (aarch32); could possibly be factored further, but for now the following should work. Pretty much everything required here is available on the project's GitHub, so will be collected in the standard GitHub source release tarball (e.g. here for the v1.1.0 image). The contents of that tarball should be deployed as follows (top level directory stripped for convenience):
    • config/debian-stretch-64.nspawn -> /etc/systemd/nspawn/debian-stretch-64.nspawn
    • etc-systemd-system/{reflect-apps.path,reflect-apps.service,reflect-passwd.path,reflect-passwd.service} -> /etc/systemd/system/ (or /usr/lib/systemd/system/ or wherever Debian policy dictates for these); note the .service files will have to have their ExecStart lines modified on install; they currently use /usr/local/bin rather than /usr/bin (see below)
    • usr-local-bin/{bthelper,ds64-run,ds64-runner,ds64-running,ds64-shell,ds64-start,ds64-stop,reflect-apps,reflect-passwd} -> /usr/bin/ (note that there is also one missing override required for bthelper that needs to be installed; please see comment here for details)
    • usr-local-share-applications/{ds64-runner.desktop,ds64-shell.desktop,ds64-start.desktop,ds64-stop.desktop,list-machines.desktop,xeyes-64.desktop}->/usr/share/applications/ (no need for the firefox-64.desktop file, as one will be auto-created by reflect-apps on startup)
    • usr-local-share-pixmaps/{ds64-runner.png,ds64-shell.png,ds64-start.png,ds64-stop.png,list,list-machines.png,xeyes.png}->/usr/share/pixmaps/ or maybe to /usr/share/icons/hicolor/32x32/apps/ depending on policy
    This third package should probably have deps on the binary kernel package and the guest container package; this (i.e, the container support package) is the one people will directly install. Should also have dep on the regular systemd-container, pulseaudio and zenity packages.
    Post install should enable and start machines.target and [email protected] Should also enable and start reflect-apps.path and reflect-passwd.path. Ensure pulseaudio is enabled and started too (if its package doesn't already do that; can't remember offhand).
Probably something I've missed but is that enough to get you started? Thanks again for offering to do this, much appreciated ^-^

Best, sakaki

Edit: small clarification
Last edited by sakaki on Mon Feb 11, 2019 11:31 pm, edited 1 time in total.

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5758
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 11, 2019 8:11 pm

Thanks, that's plenty to go on. But it may take a while, since it's not something I can spend work time on.

If the third option works for you, that's the one I'll go for.

LTolledo
Posts: 1644
Joined: Sat Mar 17, 2018 7:29 am

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 11, 2019 10:13 pm

Hi there!

Am very interested in this. Looks very promising!!

Will give it a try on my RPi3B first. Then might deploy it on my other desktop Raspbians (other RPi3B and RPi3B+)......

Hopefully a USB bootable version will be available in the future....
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 11, 2019 10:35 pm

LTolledo wrote: Hopefully a USB bootable version will be available in the future....
As the host OS is (essentially vanilla) Raspbian, I believe it should boot as-is if you simply write the image to USB rather than microSD, and then boot with this USB (and no card in the microSD slot) (on an RPi3B+ that is; on an RPi3B you'd have to set the one-time-programmable fuse first). But I haven't tried USB booting this image myself yet...
Best, sakaki

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 11, 2019 10:40 pm

ShiftPlusOne wrote:
Mon Feb 11, 2019 8:11 pm
Thanks, that's plenty to go on. But it may take a while, since it's not something I can spend work time on.

If the third option works for you, that's the one I'll go for.
Completely appreciate the "work time" point - something that comes up a fair bit for me as well ^-^ There's absolutely no rush, just as and when you get a chance!

Really appreciate you taking the time to contribute on this. I'm sure you'll make a much better job of it than I would!

Thanks again,
sakaki

User avatar
Gavinmc42
Posts: 3412
Joined: Wed Aug 28, 2013 3:31 am

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Feb 11, 2019 11:38 pm

Got my new Pi Desktop box but no mSATA drive yet.
https://au.element14.com/element14/pi-d ... ESKTOP-MAY

So I am using this on a 32GB Lexar micro USB stick, did not even bother with uSD.
Working fine with two Chromium browsers and a Firefox one now.
Still need to install the Pi Desktop software, which might break it ;)
Need that for the RTC and power on/off code.
I only got it yesterday but this dual OS img was the first one I tested.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 10:36 am

6by9,

sorry for the delay in getting back to you on the USB issue, have been busy with the v1.1.0 raspbian-nspawn-64 image and also trying to get properly to the bottom of the apparent regression I'd experienced on Gentoo. Turns out it was a userland thing - on that particular image I had quite a few of the core system libraries built debug (oops!), some with quite chatty logging, as I'd been trying to chase down an ffmpeg issue ahead of the next release of gentoo-on-rpi3-64bit. But then I'd the context switched, put it aside, and returned to it without checking my build setup. Using production build settings with the ffmpeg frame capture pipeline (or the tip build of v4l-ctl as you suggest, which cuts out a lot of unnecessary code prior to measurement), there is no noticeable 4.14 -> 4.19 regression on this metric.

So apologies for the misleading report, bit of a schoolgirl error / facepalm on my belhalf tbh ><

Best,

sakaki

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 10:47 am

sakaki wrote:
Tue Feb 12, 2019 10:36 am
6by9,

sorry for the delay in getting back to you on the USB issue, have been busy with the v1.1.0 raspbian-nspawn-64 image and also trying to get properly to the bottom of the apparent regression I'd experienced on Gentoo. Turns out it was a userland thing - on that particular image I had quite a few of the core system libraries built debug (oops!), some with quite chatty logging, as I'd been trying to chase down an ffmpeg issue ahead of the next release of gentoo-on-rpi3-64bit. But then I'd the context switched, put it aside, and returned to it without checking my build setup. Using production build settings with the ffmpeg frame capture pipeline (or the tip build of v4l-ctl as you suggest, which cuts out a lot of unnecessary code prior to measurement), there is no noticeable 4.14 -> 4.19 regression on this metric.

So apologies for the misleading report, bit of a schoolgirl error / facepalm on my belhalf tbh ><

Best,

sakaki
That's good news. I wasn't seeing any significant difference so was a little confused that you were.
I think we may be getting close to the point where 4.19 becomes the standard kernel :o
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LTolledo
Posts: 1644
Joined: Sat Mar 17, 2018 7:29 am

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 12:13 pm

Tried flashing the image using etcher but I got this error

did I miss something?
BalenaError.jpg
BalenaError.jpg (59.64 KiB) Viewed 1921 times
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

LTolledo
Posts: 1644
Joined: Sat Mar 17, 2018 7:29 am

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 1:28 pm

Yikes! Fatal mistake! wrong file downloaded that's why I got the error . Sorry if I made you anxious. ごめんなさい!

Anyway I got it running now on a USB native boot RPI3B (Raspberry Pi 3 model B) with the OTP bit already set beforehand.

Now if only I can port my installed apps (including their configurations and addons) from my previous raspbian to this I would feel much better.
I want to move over to this later on.....(hope sooner the better)

sasakiさんのアバターはあずまんが大王のささきですよね。
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 4:09 pm

If you are booting with a 64 bit kernel, does this break the python libraries? Or is it just the upstream 64 bit kernel that breaks them?

Reference: https://wiki.debian.org/RaspberryPi3/#GPIO

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 5:16 pm

feelslikeautumn wrote:
Tue Feb 12, 2019 4:09 pm
If you are booting with a 64 bit kernel, does this break the python libraries? Or is it just the upstream 64 bit kernel that breaks them?

Reference: https://wiki.debian.org/RaspberryPi3/#GPIO
If these libs rely on /proc/cpuinfo rather than checking the device tree, they'll not work under a 64-bit kernel (even the RPi one, and even in a 32-bit Raspbian userland). I ran into a similar thing (not python-based) with wiringpi for gentoo-on-rpi3-64bit, and had to put in a somewhat hacky fix in for it.

But, it is easy to workaround this issue in a reasonably generic way, just bind mount a faux variant over /proc/cpuinfo; this is usually enough to fake most things into working ^-^. YMMV.

On your host (Raspbian) OS:

Code: Select all

[email protected]:~ $ cat <<EOF | sudo tee /root/fake-cpuinfo
processor	: 0
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 1
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 2
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 3
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

Hardware	: BCM2709
Revision	: a02082
Serial		: 0000000000000000
EOF
Adapt as appropriate for your board. Then:

Code: Select all

[email protected]:~ $ sudo mount -v --bind /root/fake-cpuinfo /proc/cpuinfo
mount: /root/fake-cpuinfo bound on /proc/cpuinfo.
[email protected]:~ $ # run your python stuff
[email protected]:~ $ sudo umount -v /proc/cpuinfo
umount: /proc/cpuinfo (...) unmounted
A similar thing can be done inside the guest (64-bit) OS if required.

Credit: idea came from here.

hth, sakaki

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 6:20 pm

Good stuff - thanks. What about the pin numbers? Are they offset like the Debian wiki says?

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 6:33 pm

LTolledo wrote:
Tue Feb 12, 2019 1:28 pm
Yikes! Fatal mistake! wrong file downloaded that's why I got the error . Sorry if I made you anxious. ごめんなさい!

Anyway I got it running now on a USB native boot RPI3B (Raspberry Pi 3 model B) with the OTP bit already set beforehand.

Now if only I can port my installed apps (including their configurations and addons) from my previous raspbian to this I would feel much better.
I want to move over to this later on.....(hope sooner the better)

sasakiさんのアバターはあずまんが大王のささきですよね。
Glad it is now working for you!
[OT]はい、そうです。 私はその女性に少し似ているんですから ...^-^...[/OT]

User avatar
sakaki
Posts: 249
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 6:51 pm

feelslikeautumn wrote:
Tue Feb 12, 2019 6:20 pm
Good stuff - thanks. What about the pin numbers? Are they offset like the Debian wiki says?
No, iirc, under the RPF 64-bit kernel (which this image uses) they aren't offset. But cat /sys/kernel/debug/gpio to check - I may be wrong about that.
hth,
sakaki

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5758
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 7:50 pm

This approach got me thinking that some of the mechanisms you've come up with could also be used to run eltech's version of wine with qemu-user-static and an i386 container. Then you could integrate windows applications relatively seamlessly as well. But I don't know if there's much interest in that. Throwing it out there as an idea, in case anybody wants to do it.

LTolledo
Posts: 1644
Joined: Sat Mar 17, 2018 7:29 am

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 12, 2019 9:38 pm

Ok so I got it up and running, and after installing my favorite apps (took fairly long time), below is is the screen capture of the desktop.

also installed 64bit Kodi, however it does not seem to run. have installed the 32bit version as "backup".
Also installed 32bit programs just to be sure.
Hope to see Kodi 64bit running in in the future too (no rush though)

any other 64bit apps/program suggestions welcome. I'd like to try those as well.

(accessed and posted on this forum using the 64bit chromium on RPi3B)
Attachments
screencap.png
screencap.png (133.27 KiB) Viewed 1788 times
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

Return to “General discussion”