Migrating ZynthianOS to 64 bits

Software
24

Pi 3 & 64 bit seems a bit crappy.

1 Like
25

Getting
bcm2835-codec bcm2835-codec: bcm2835_codec_buf_prepare data will not fit into plane (1536 < 353280)

which kills the Pi HDMI graphics dead.
Can still log on from remote machine.
Anyone know how to restart a PI in this state without init 0’ing the poor beast?
It does seem to come back to life after a bit or not.

Getting to be irritating…

26

Is this problem on a Pi4 or Pi3? My Pi4 (8GB) has 64-bit and it runs fine.

Gonzo

27

Any updates on this? Has anyone tried an unofficial migration, at least?

28

Not yet from the “official side”.
We have been quite busy in other areas, but time is coming now … :nerd_face:

1 Like
29

I see that Debian 12 Bookworm is scheduled for release in June. Maybe we should skip Bullseye and move straight to Bookworm.

5 Likes
30

I read that Bookworm defaults to Pipewire, is Zynthian also transitioning to Pipewire?

31

Pipewire is not yet fully mature and doesn’t offer many benefits to the Zynthian. It is a great mechanism for coming desktop audio with the advantages that JACK provides but we only need the JACK functionality which is still better in JACK. We don’t need the desktop stuff not the video stuff and some of it may get on our way. I am keen to see pipewire mature but it would have to provide significant advantage and comparable or better performance as JACK to tempt us.

2 Likes
32

I might have some progress on that with Mobian, see this commit

There were also some unavailable packages at the time that I did the port. We shall see if there is a maintainer for them and maybe ask for a port to bookworm.

Find my comments about missing packages and whatnot with #PORT

1 Like
33

Raspberry Foundation has finally released Bookworm version so we can move to Bookworm. (Zynthian OS is based on Raspberry Pi OS .)

7 Likes
34

Finally I could finish the 64 bit port using latest distro.
I will take 3-4 weeks to have a test SD image.

Thanks!

8 Likes
35

Really looking forward to the 64 bit switch :muscle:

Thanks @jofemodo

2 Likes
36

Note that using pip for system packages isn’t allowed in Bookworm

2 Likes
37

Oh joy! Even more abstraction. :frowning_face:

1 Like
38

Is there a repository or some other mechanism where we can see what some of the changes are for 64 bit? It might be very helpful for our RISC-V port.

39

Hi @tunagenes!

There hasn’t been much progress on this but that is about to change… We create development branches in the GitHub zynthian reporistories for such development so the normal repos will hold the work. Just look out for suitably named branches. Of course they will sit on top of a different image which is yet to be built. (The previous 64-bit image was based on Bullseye (Debian 11) and we will be building on Bookworm (Debian 12).)

2 Likes
40

The only compelling reason to leave the Pi OS is if you want to leave the Pi platform sometime in the future, seems to me. If you want to one day be fully open source, that would be the only reason I could see that you’d want to move away. Other than, maybe some crazy powerful new platform arrives that is equally easy to code for, or you want to move to x86 architecture, which given the ascendancy of ARM more generally, doesn’t seem to make a lot of sense to do.

Good to hear you’re moving forward anyways. Maybe someday I can help with more than money. I do plan to buy one of every new hardware version, pretty much. :>

41

I have never gotten used to using venvs and lately they all seem to be outlawing this easy-but-not-advisable practice, it’s quite annoying.

42

It’s a bit of a faff, but as with most thigs that are considered best practice, it pays off in the long run. Especially if you’re like me and use a few different distros, python package naming isn’t consistant.

43

I don’t see supporting additional architectures as “leaving the Pi OS” - I seriously doubt that Zynthian would drop support for RPi in the foreseeable future.

But, I think Zynthian could be much more portable - to other architectures such as RISC-V, Intel, etc., as well as to other Arm chips-SBCs.

The motivations for a RISC-V port include:
The belief that openness of the architecture will allow experimentation with new ideas, such as FPGA assist, more easily.
The hope that faster and more core implementations of RISC-V at lower cost than Arm will someday be available.
And “belief” and “hope” are indeed speculative. Before the RPi5 we thought Arm and RISC-V were roughly equivalent in terms of available SBCs. Now RISC-V has got some catching up to do!

I agree with you re x86, although it wouldn’t be a bad thing, just not as interesting now, to me.