https://forum.manjaro.org/t/manjaro-arm-19-02-released/75594

[stuartiannaylor]

Such an architecture could certainly be built in theory, but it would require substantially more instructions for every address calculation. Worse, for a modern pipelined CPU those instructions have tight dependencies on each other.

Given how cheap transistors are nowadays it makes little sense to widen the virtual addresses to 64 bits without also widening the data path to 64 bits.

The main distro's seem to be dropping 32bit and it sort of looked like you answered that yourself and even if there is a fix (I wasn't aware of https://lwn.net/Articles/776435/)

The only remaining problem, of course, is that user space is still using 32-bit times, so things will still explode on schedule in 2038. Fixing that problem is not something that the kernel can do on its own, but it can provide the infrastructure to make the transition possible. In particular, for all of the _time32() calls described above, the patch set also exposes the 64-bit versions with _time64() suffixes. So, once this patch is applied, both the (broken) 32-bit and (fixed) 64-bit interfaces are available in 32-bit systems.

There is no magic fix as binaries have to be patched and my hunch is that not many are going to bother, Raspbian might , but looking like they will be a minority.
Starting August 1, 2019 all android apps will need to support 64-bit architectures, IoS it was February 1, 2015.
Ubuntu 32bit support is till 2023, with other distro's following suit.
Electron the framework behind one of the Pi's most popular projects MagicMirror in version 4 the current stable has dropped 32 bit already.


I am neither for or against but yeah its looking like 32bit has bit the dust and I am expecting probably raspberry will do the same. Its likely that 64 bit raspbian will happen sooner or later. Not because its better, faster or something 32bit can not do just that it would seem generally it would leave them in a position of ever increasing upstream conversion work.
I am expecting like most others they are going to say sod it, lets just go 64bit like everybody else.

I would wager a sherbet that maybe rasperry pi4 time we might see a 64 bit distro arrive and eventually 32bit will be demoted as the alternative download to eventually not be supported.
So its 2 sherbets if raspbian32 doesn't exist in a decade but don't know if I will be around then to collect.

[hippy]

Umm why are you quoting something I quoted and debunked as if I said it?

Apologies for that and now corrected. Things got messed up in replying through losing a /quote, then completely screwed-up during a re-edit.

[jamesh]

Such an architecture could certainly be built in theory, but it would require substantially more instructions for every address calculation. Worse, for a modern pipelined CPU those instructions have tight dependencies on each other.

Given how cheap transistors are nowadays it makes little sense to widen the virtual addresses to 64 bits without also widening the data path to 64 bits.

The main distro's seem to be dropping 32bit and it sort of looked like you answered that yourself and even if there is a fix (I wasn't aware of https://lwn.net/Articles/776435/)

The only remaining problem, of course, is that user space is still using 32-bit times, so things will still explode on schedule in 2038. Fixing that problem is not something that the kernel can do on its own, but it can provide the infrastructure to make the transition possible. In particular, for all of the _time32() calls described above, the patch set also exposes the 64-bit versions with _time64() suffixes. So, once this patch is applied, both the (broken) 32-bit and (fixed) 64-bit interfaces are available in 32-bit systems.

There is no magic fix as binaries have to be patched and my hunch is that not many are going to bother, Raspbian might , but looking like they will be a minority.
Starting August 1, 2019 all android apps will need to support 64-bit architectures, IoS it was February 1, 2015.
Ubuntu 32bit support is till 2023, with other distro's following suit.

I am neither for or against but yeah its looking like 32bit has bit the dust and I am expecting probably raspberry will do the same. Its likely that 64 bit raspbian will happen sooner or later. Not because its better, faster or something 32bit can not do just that it would seem generally it would leave them in a position of ever increasing upstream conversion work.
I am expecting like most others they are going to say sod it, lets just go 64bit like everybody else.

I would wager a sherbet that maybe rasperry pi4 time we might see a 64 bit distro arrive and eventually 32bit will be demoted as the alternative download to eventually not be supported.
So its 2 sherbets if raspbian32 doesn't exist in a decade but don't know if I will be around then to collect.

Whilst we still sell 32bit only devices, we will support 32bit devices.

One major problem with going to a 64bit kernel is a technical issue with the interface to the VC4, which is 32bit. There's a load of work and therefor testing needed to fix that interface, especially when passing memory pointers around.

[hippy]

Starting August 1, 2019 all android apps will need to support 64-bit architectures

That's not strictly true. Only apps published on Google Play will need to support 64-bit.

Apps available through other sources can continue to be 32-bit, do not have to support 64-bit. This is similar to Google deciding that, since November 2018, all apps on Google Play must support Oreo / Android 8.0. That does not preclude developing and distributing apps which do not.

Android apps written in Java, or are created by tools which produce Java, should already be 64-bit compatible. The issue will however affect those using native libraries.

[stuartiannaylor]

Starting August 1, 2019 all android apps will need to support 64-bit architectures

That's not strictly true. Only apps published on Google Play will need to support 64-bit.

Apps available through other sources can continue to be 32-bit, do not have to support 64-bit. This is similar to Google deciding that, since November 2018, all apps on Google Play must support Oreo / Android 8.0. That does not preclude developing and distributing apps which do not.

Android apps written in Java, or are created by tools which produce Java, should already be 64-bit compatible. The issue will however affect those using native libraries.

https://developer.android.com/distribut ... lop/64-bit is basically what they are saying and the reason why is they are going to stop 32bit support.

[hippy]

https://developer.android.com/distribut ... lop/64-bit is basically what they are saying and the reason why is they are going to stop 32bit support.

That's just part of the story and Google Play focused.

Google "ends support for 32-bit apps in 2021", but again that is mostly Play Store related.

However there will be exceptions for Wear OS, Android TV, and 32-bit apps which target earlier Android versions.

[stuartiannaylor]

Such an architecture could certainly be built in theory, but it would require substantially more instructions for every address calculation. Worse, for a modern pipelined CPU those instructions have tight dependencies on each other.

Given how cheap transistors are nowadays it makes little sense to widen the virtual addresses to 64 bits without also widening the data path to 64 bits.

The main distro's seem to be dropping 32bit and it sort of looked like you answered that yourself and even if there is a fix (I wasn't aware of https://lwn.net/Articles/776435/)

The only remaining problem, of course, is that user space is still using 32-bit times, so things will still explode on schedule in 2038. Fixing that problem is not something that the kernel can do on its own, but it can provide the infrastructure to make the transition possible. In particular, for all of the _time32() calls described above, the patch set also exposes the 64-bit versions with _time64() suffixes. So, once this patch is applied, both the (broken) 32-bit and (fixed) 64-bit interfaces are available in 32-bit systems.

There is no magic fix as binaries have to be patched and my hunch is that not many are going to bother, Raspbian might , but looking like they will be a minority.
Starting August 1, 2019 all android apps will need to support 64-bit architectures, IoS it was February 1, 2015.
Ubuntu 32bit support is till 2023, with other distro's following suit.

I am neither for or against but yeah its looking like 32bit has bit the dust and I am expecting probably raspberry will do the same. Its likely that 64 bit raspbian will happen sooner or later. Not because its better, faster or something 32bit can not do just that it would seem generally it would leave them in a position of ever increasing upstream conversion work.
I am expecting like most others they are going to say sod it, lets just go 64bit like everybody else.

I would wager a sherbet that maybe rasperry pi4 time we might see a 64 bit distro arrive and eventually 32bit will be demoted as the alternative download to eventually not be supported.
So its 2 sherbets if raspbian32 doesn't exist in a decade but don't know if I will be around then to collect.

Whilst we still sell 32bit only devices, we will support 32bit devices.

One major problem with going to a 64bit kernel is a technical issue with the interface to the VC4, which is 32bit. There's a load of work and therefor testing needed to fix that interface, especially when passing memory pointers around.

Who knows
Plus you are presuming you will have buyers to sell 32bit devices to.

[code_exec]

Starting August 1, 2019 all android apps will need to support 64-bit architectures

That's not strictly true. Only apps published on Google Play will need to support 64-bit.

Apps available through other sources can continue to be 32-bit, do not have to support 64-bit. This is similar to Google deciding that, since November 2018, all apps on Google Play must support Oreo / Android 8.0. That does not preclude developing and distributing apps which do not.

Android apps written in Java, or are created by tools which produce Java, should already be 64-bit compatible. The issue will however affect those using native libraries.

https://developer.android.com/distribut ... lop/64-bit is basically what they are saying and the reason why is they are going to stop 32bit support.

Google aren't completely stopping support for 32-bit. They are requiring all apps starting August 2019 as well as updates to existing apps to have a 64-bit (arm64-v8a) version which will be installed on 64-bit devices if available. Developers can continue producing a 32-bit (armeabi-v7a) version of their app as well which can be installed on 32-bit devices and 64-bit devices running a 32-bit ROM. In August 2021, 32-bit only apps will not show up in the search results on a 64-bit device and the only way to install them is to sideload them. Some future Android devices may drop 32-bit support altogether, so that won't work either.

I remember when Apple did something very similar to this. On iOS 9, they started warning people who opened 32-bit apps on 64-bit devices that the apps may slow down their device. In iOS 10, they warned users again when opening 32-bit apps on their 64-bit devices, saying that these apps would no longer work in iOS 11. In iOS 11, if a user attempted to open a 32-bit app, they would be told that the app is incompatible with iOS 11 and needs to be updated. New 32-bit only apps can't be uploaded to the App Store either, as well as 32-bit only updates. 64-bit devices also don't see 32-bit only apps in the search results anymore. Apple gave app developers TWO YEARS to support 64-bit devices. Not all app developers were active at all or actively updating their older 32-bit apps, but it gave those who were plenty of time to support 64-bit devices.

[stuartiannaylor]

That's not strictly true. Only apps published on Google Play will need to support 64-bit.

Apps available through other sources can continue to be 32-bit, do not have to support 64-bit. This is similar to Google deciding that, since November 2018, all apps on Google Play must support Oreo / Android 8.0. That does not preclude developing and distributing apps which do not.

Android apps written in Java, or are created by tools which produce Java, should already be 64-bit compatible. The issue will however affect those using native libraries.

https://developer.android.com/distribut ... lop/64-bit is basically what they are saying and the reason why is they are going to stop 32bit support.

Google aren't completely stopping support for 32-bit. They are requiring all apps starting August 2019 as well as updates to existing apps to have a 64-bit (arm64-v8a) version which will be installed on 64-bit devices if available. Developers can continue producing a 32-bit (armeabi-v7a) version of their app as well which can be installed on 32-bit devices and 64-bit devices running a 32-bit ROM. In August 2021, 32-bit only apps will not show up in the search results on a 64-bit device and the only way to install them is to sideload them. Some future Android devices may drop 32-bit support altogether, so that won't work either.

I remember when Apple did something very similar to this. On iOS 9, they started warning people who opened 32-bit apps on 64-bit devices that the apps may slow down their device. In iOS 10, they warned users again when opening 32-bit apps on their 64-bit devices, saying that these apps would no longer work in iOS 11. In iOS 11, if a user attempted to open a 32-bit app, they would be told that the app is incompatible with iOS 11 and needs to be updated. New 32-bit only apps can't be uploaded to the App Store either, as well as 32-bit only updates. 64-bit devices also don't see 32-bit only apps in the search results anymore. Apple gave app developers TWO YEARS to support 64-bit devices. Not all app developers were active at all or actively updating their older 32-bit apps, but it gave those who were plenty of time to support 64-bit devices.

It was only posted just to show the exact strong wording and manner that Google are pushing 64bit. That isn't the point as its not about google alone as the consensus about 64bit is rather deafening at the moment.
The biggest effect for Arm is Android and IoS and without doubt 64bit is being actively pushed and the latest Cortex-A76 is the first Arm 64-bit-only CPU core (in kernel mode).
This doesn't mean its imminent unless your a top end mobile but generally hugely important key figures have zero roadmap for 32bit.
The 32bit scene is going to be an absolute minefield of cul-de-sacs where hugely important applications no longer have 32 bit development or support from Chromium to NodeJS then the huge array that now implement a default 64bit as they transition to do the same.
Its not about any singular company or OS its volume and across the board from MacOS to Windows 32bit is being depreciated.
Because of the volume I would hazard a guess from around the Ubuntu time of 2023 the dropout of 32bit will be quite heavy and 32bit will become a specialist niche area for embedded software and devices and far from mainstream any more.

That is when the 32bit Raspberry stops being a Raspberry its no-longer a cheap device that is a direct hop into mainstream computing as it becomes very like the devices available that prompted the creation of raspberry, of a niche market not suitable for general education.

Yes there will be exceptions and continuation but the raspberry eco-sphere as we know it of supporting and running all main-stream is likely come to an end.
A absolutely massive array of backport needs will need to be supported by Raspberry, who are still trying to complete 10 year old VC4 32bit Mesa and OpenGL support.
Its likely that from silicon, apps to OS that 32bit is eventually a cul-de-sac, that is looking sooner than later apart from specialist niche markets.
To continue as a 32bit device only with no 64bit roadmap would likely mean abandoning the very educational rationales of instant and cheap mainstream access.

[rpdom]

Whilst we still sell 32bit only devices, we will support 32bit devices.

Plus you are presuming you will have buyers to sell 32bit devices to.

There seem to be no shortage of buyers for the Pi Zero(W/WH), the Pi 1B+ and the CM(1).

[stuartiannaylor]

Whilst we still sell 32bit only devices, we will support 32bit devices.

Plus you are presuming you will have buyers to sell 32bit devices to.

There seem to be no shortage of buyers for the Pi Zero(W/WH), the Pi 1B+ and the CM(1).

That is because the pi zero is currently part of a continuous roadmap, that is clearly going to end and from anywhere from 5 years to a decade maybe comeback and say how many sales there are then.
If you are looking at the huge effort that a 64 bit transition would need you have to look far further than just now.
If you don't look ahead you could end up with a monumental workload with little time left to complete.

As for Pi 1B+ and CM(1) sales what proportion of sales do they now represent for pi, technology is always a rolling road and any ideas that can be frozen are highly likely dangerous ones.

[jamesh]

The main distro's seem to be dropping 32bit and it sort of looked like you answered that yourself and even if there is a fix (I wasn't aware of https://lwn.net/Articles/776435/)



There is no magic fix as binaries have to be patched and my hunch is that not many are going to bother, Raspbian might , but looking like they will be a minority.
Starting August 1, 2019 all android apps will need to support 64-bit architectures, IoS it was February 1, 2015.
Ubuntu 32bit support is till 2023, with other distro's following suit.

I am neither for or against but yeah its looking like 32bit has bit the dust and I am expecting probably raspberry will do the same. Its likely that 64 bit raspbian will happen sooner or later. Not because its better, faster or something 32bit can not do just that it would seem generally it would leave them in a position of ever increasing upstream conversion work.
I am expecting like most others they are going to say sod it, lets just go 64bit like everybody else.

I would wager a sherbet that maybe rasperry pi4 time we might see a 64 bit distro arrive and eventually 32bit will be demoted as the alternative download to eventually not be supported.
So its 2 sherbets if raspbian32 doesn't exist in a decade but don't know if I will be around then to collect.

Whilst we still sell 32bit only devices, we will support 32bit devices.

One major problem with going to a 64bit kernel is a technical issue with the interface to the VC4, which is 32bit. There's a load of work and therefor testing needed to fix that interface, especially when passing memory pointers around.

Who knows
Plus you are presuming you will have buyers to sell 32bit devices to.

I know.

The Pi1 (still manufactured and sold), the CM1, and the Zero range all use 32bit ARM cores. We are commited to supplying the Pi1 until early 2020's IIRC. As for the Zero, we need the low end cores to keep the price down. We sell a LOT of Zero's. There is a huge market for cheap low power small but full featured devices. IoT devices for example are 16 or 32 bit. Lots of life left in 32 bit.

[stuartiannaylor]

Whilst we still sell 32bit only devices, we will support 32bit devices.

One major problem with going to a 64bit kernel is a technical issue with the interface to the VC4, which is 32bit. There's a load of work and therefor testing needed to fix that interface, especially when passing memory pointers around.

Who knows
Plus you are presuming you will have buyers to sell 32bit devices to.

I know.

The Pi1 (still manufactured and sold), the CM1, and the Zero range all use 32bit ARM cores. We are commited to supplying the Pi1 until early 2020's IIRC. As for the Zero, we need the low end cores to keep the price down. We sell a LOT of Zero's. There is a huge market for cheap low power small but full featured devices. IoT devices for example are 16 or 32 bit. Lots of life left in 32 bit.

Early 2020's exactly what I am talking about but that is now and those low end cores are due to the max space available for ram & core on a single 40nm piece of silicon.
The Zero is a great piece of kit but already starting to hit problems with Armv6 cul-de-sacs but the $5-10 overcomes that. I have 2 zero and a z-w on my desk.
I am eagerly awaiting what might happen in the future with 22nm as a pi-zero-2 oh yeah that would be mighty and after that there isn't a single product that has to remain 32bit apart from the problems with VC4.
It will be interesting to know how many Cm1 you sell in 5 years time when the CM3A+ (Is that the new one) is available pin compatible and practically the same cost.
The very idea you can freeze a product range in time based on current sales for a Raspberry fan is a scary one.
Early 2020's is only 5 years and why a guesstimate of approx 2 years for a alternative 64bit repo that hopefully will of garnered some momentum by early 2020's is in someway not reasonable is a strange and perplexing response.

[jamesh]

Who knows
Plus you are presuming you will have buyers to sell 32bit devices to.

I know.

The Pi1 (still manufactured and sold), the CM1, and the Zero range all use 32bit ARM cores. We are commited to supplying the Pi1 until early 2020's IIRC. As for the Zero, we need the low end cores to keep the price down. We sell a LOT of Zero's. There is a huge market for cheap low power small but full featured devices. IoT devices for example are 16 or 32 bit. Lots of life left in 32 bit.

Early 2020's exactly what I am talking about but that is now and those low end cores are due to the max space available for ram & core on a single 40nm piece of silicon.
The Zero is a great piece of kit but already starting to hit problems with Armv6 cul-de-sacs but the $5-10 overcomes that. I have 2 zero and a z-w on my desk.
I am eagerly awaiting what might happen in the future with 22nm as a pi-zero-2 oh yeah that would be mighty and after that there isn't a single product that has to remain 32bit apart from the problems with VC4.
It will be interesting to know how many Cm1 you sell in 5 years time when the CM3A+ (Is that the new one) is available pin compatible and practically the same cost.
The very idea you can freeze a product range in time based on current sales for a Raspberry fan is a scary one.

Not quite sure what you are getting at with that last sentence.

Note that the SoC on the Zero is cheap. Really cheap. Any newer part will be more expensive. It's always a tradeoff. When people stop buying Zero's we know the tradeoff point has changed.

Also, the Zero SoC is quite low power compared with the new SoC's.

What cul-de-sacs are you finding with the Zero? Given it costs about $10, are those cul-de-sacs simply "it doesn't do all that I want", which is a strange argument, because of the low cost. If you want more you have to pay more. There are actual limits to how cheaply to can make somthing with a particular feature set.

We recommend that people wanting the CM range use the CM3 for new products, as you say, very little need to remain with the CM1 when the CM3 is available. However, some people still buy them as they may be in approved devices and they don't want to re-approve, or the power requriements of the CM3 are too onerous.

And don't forget the installed base. We've always maintained backwards compatibility to ensure customers don't feel left out (Android phone anyone?). With many millions of 32bit devices out there, should we just abandon them, stop providing updates etc?

[stuartiannaylor]

I know.

The Pi1 (still manufactured and sold), the CM1, and the Zero range all use 32bit ARM cores. We are commited to supplying the Pi1 until early 2020's IIRC. As for the Zero, we need the low end cores to keep the price down. We sell a LOT of Zero's. There is a huge market for cheap low power small but full featured devices. IoT devices for example are 16 or 32 bit. Lots of life left in 32 bit.

Early 2020's exactly what I am talking about but that is now and those low end cores are due to the max space available for ram & core on a single 40nm piece of silicon.
The Zero is a great piece of kit but already starting to hit problems with Armv6 cul-de-sacs but the $5-10 overcomes that. I have 2 zero and a z-w on my desk.
I am eagerly awaiting what might happen in the future with 22nm as a pi-zero-2 oh yeah that would be mighty and after that there isn't a single product that has to remain 32bit apart from the problems with VC4.
It will be interesting to know how many Cm1 you sell in 5 years time when the CM3A+ (Is that the new one) is available pin compatible and practically the same cost.
The very idea you can freeze a product range in time based on current sales for a Raspberry fan is a scary one.

Not quite sure what you are getting at with that last sentence.

Note that the SoC on the Zero is cheap. Really cheap. Any newer part will be more expensive. It's always a tradeoff. When people stop buying Zero's we know the tradeoff point has changed.

Also, the Zero SoC is quite low power compared with the new SoC's.

What cul-de-sacs are you finding with the Zero? Given it costs about $10, are those cul-de-sacs simply "it doesn't do all that I want", which is a strange argument, because of the low cost. If you want more you have to pay more. There are actual limits to how cheaply to can make somthing with a particular feature set.

We recommend that people wanting the CM range use the CM3 for new products, as you say, very little need to remain with the CM1 when the CM3 is available. However, some people still buy them as they may be in approved devices and they don't want to re-approve, or the power requriements of the CM3 are too onerous.

And don't forget the installed base. We've always maintained backwards compatibility to ensure customers don't feel left out (Android phone anyone?). With many millions of 32bit devices out there, should we just abandon them, stop providing updates etc?

Its just strange you are at the same time arguing backward compatibility whilst negating forward compatibility when no-one has suggested anything that will have an effect on the backward compatibility.
No-one is being left out apart from those with an eye to forward compatibility and that as said even for a raspberry fan is potentially a scary one.
Does Raspberry provide support for NodeJS and electron on armv6 and will they as the answer is no.
That at the moment is the only one I can think of but slowly it will become more of an issue with more apps and frameworks.
Support to early 2020's is likely a good choice as around that period support is going to get tough because of work load.
All I am am asking is around that time some sort of partial and usable 64bit repo is in place and to get there its likely a start maybe needed in a year or two.
Why that has any influence on continuing 32bit support bemuses me and why and future compatibility seems to be answered as it is, seems worrying.
Raspberry do sell 64bit product they just don't have a 64bit OS in fact most of what Raspberry sell is 64bit running 32bit modes.

[jamesh]

Early 2020's exactly what I am talking about but that is now and those low end cores are due to the max space available for ram & core on a single 40nm piece of silicon.
The Zero is a great piece of kit but already starting to hit problems with Armv6 cul-de-sacs but the $5-10 overcomes that. I have 2 zero and a z-w on my desk.
I am eagerly awaiting what might happen in the future with 22nm as a pi-zero-2 oh yeah that would be mighty and after that there isn't a single product that has to remain 32bit apart from the problems with VC4.
It will be interesting to know how many Cm1 you sell in 5 years time when the CM3A+ (Is that the new one) is available pin compatible and practically the same cost.
The very idea you can freeze a product range in time based on current sales for a Raspberry fan is a scary one.

Not quite sure what you are getting at with that last sentence.

Note that the SoC on the Zero is cheap. Really cheap. Any newer part will be more expensive. It's always a tradeoff. When people stop buying Zero's we know the tradeoff point has changed.

Also, the Zero SoC is quite low power compared with the new SoC's.

What cul-de-sacs are you finding with the Zero? Given it costs about $10, are those cul-de-sacs simply "it doesn't do all that I want", which is a strange argument, because of the low cost. If you want more you have to pay more. There are actual limits to how cheaply to can make somthing with a particular feature set.

We recommend that people wanting the CM range use the CM3 for new products, as you say, very little need to remain with the CM1 when the CM3 is available. However, some people still buy them as they may be in approved devices and they don't want to re-approve, or the power requriements of the CM3 are too onerous.

And don't forget the installed base. We've always maintained backwards compatibility to ensure customers don't feel left out (Android phone anyone?). With many millions of 32bit devices out there, should we just abandon them, stop providing updates etc?

Its just strange you are at the same time arguing backward compatibility whilst negating forward compatibility when no-one has suggested anything that will have an effect on the backward compatibility.
No-one is being left out apart from those with an eye to forward compatibility and that as said even for a raspberry fan is potentially a scary one.
Does Raspberry provide support for NodeJS and electron on armv6 and will they as the answer is no.
That at the moment is the only one I can think of but slowly it will become more of an issue with more apps and frameworks.
Support to early 2020's is likely a good choice as around that period support is going to get tough because of work load.
All I am am asking is around that time some sort of partial and usable 64bit repo is in place and to get there its likely a start maybe needed in a year or two.
Why that has any influence on continuing 32bit support bemuses me and why and future compatibility seems to be answered as it is, seems worrying.
Raspberry do sell 64bit product they just don't have a 64bit OS in fact most of what Raspberry sell is 64bit running 32bit modes.

It's a manpower issue, supporting two difference architectures requires more staff than we have. It's one of the main reason we haven't already done an official 64bit system. We'll probably need some sort of hybrid (64 kernel, 32 userland) to reduce the support burden.

[stuartiannaylor]

Not quite sure what you are getting at with that last sentence.

Note that the SoC on the Zero is cheap. Really cheap. Any newer part will be more expensive. It's always a tradeoff. When people stop buying Zero's we know the tradeoff point has changed.

Also, the Zero SoC is quite low power compared with the new SoC's.

What cul-de-sacs are you finding with the Zero? Given it costs about $10, are those cul-de-sacs simply "it doesn't do all that I want", which is a strange argument, because of the low cost. If you want more you have to pay more. There are actual limits to how cheaply to can make somthing with a particular feature set.

We recommend that people wanting the CM range use the CM3 for new products, as you say, very little need to remain with the CM1 when the CM3 is available. However, some people still buy them as they may be in approved devices and they don't want to re-approve, or the power requriements of the CM3 are too onerous.

And don't forget the installed base. We've always maintained backwards compatibility to ensure customers don't feel left out (Android phone anyone?). With many millions of 32bit devices out there, should we just abandon them, stop providing updates etc?

Its just strange you are at the same time arguing backward compatibility whilst negating forward compatibility when no-one has suggested anything that will have an effect on the backward compatibility.
No-one is being left out apart from those with an eye to forward compatibility and that as said even for a raspberry fan is potentially a scary one.
Does Raspberry provide support for NodeJS and electron on armv6 and will they as the answer is no.
That at the moment is the only one I can think of but slowly it will become more of an issue with more apps and frameworks.
Support to early 2020's is likely a good choice as around that period support is going to get tough because of work load.
All I am am asking is around that time some sort of partial and usable 64bit repo is in place and to get there its likely a start maybe needed in a year or two.
Why that has any influence on continuing 32bit support bemuses me and why and future compatibility seems to be answered as it is, seems worrying.
Raspberry do sell 64bit product they just don't have a 64bit OS in fact most of what Raspberry sell is 64bit running 32bit modes.

It's a manpower issue, supporting two difference architectures requires more staff than we have. It's one of the main reason we haven't already done an official 64bit system. We'll probably need some sort of hybrid (64 kernel, 32 userland) to reduce the support burden.

I am thinking you don't really have to release a 'official' 64bit system that a community repo and image of 'testing/unstable' that doesn't have Raspberry support but does have raspberry involvement.
I don't think or am I suggesting that you need to release an official 64bit system in the next year or 2. I do think its highly advisable to start sooner than later with a official 'unoffficial' 64bit testing version that is in the same raspberry namespace.
Hopefully in approx 5 years early 2020's it will be starting to gain some traction and looking like it could move from testing to release whilst much of the work has been community with some great input from Rasberry when they could.
Probably the VC4 work will be the very last but headless will be the first part of the transition.
It just needs Raspberry to put there name to it to centre focus but actually doesn't require much more.
Raspberry just needs an initial repo under the raspberry namespace so all commits become part of that namespace and its likely it would gain momentum fast with little raspberry input.
Why that is not being done is actually worrying me, why Raspberry seems to think the only 64bit alternative needs to be a complete and finished solution and provided overnight is a complete confusion to me?
https://github.com/CodeExecution/Debian64Pi don't make work for yourselves but create the space for the community. All you have to do is own the namespace.

[hippy]

What cul-de-sacs are you finding with the Zero?

Given the reference was to ARMv6 cul-de-sacs I would presume it was mainly the inability to run anything which requires ARMv7 to run and the problems which arise when there are no alternative ARMv6 solutions.

I don't think that's going to be a problem for a lot of people who choose a Zero, but when software one needs for a general purpose computer stops being available for the Zero it ceases being a viable general purpose computer.

A user who wants a general purpose computer has no choice but to buy a more expensive Pi which does support what a general purpose computer needs. The Pi range loses the low-cost general purpose computer it once had.

Given it costs about $10, are those cul-de-sacs simply "it doesn't do all that I want", which is a strange argument, because of the low cost. If you want more you have to pay more. There are actual limits to how cheaply to can make somthing with a particular feature set.

I think that's really the point being made. If the world goes ARMv7-only; the Zero is effectively dead in the water. But that can be overcome by moving to a Pi which supports ARMv7.

Likewise, as the world goes 64-bit only, drops support for ARMv7; 32-bit and ARMv7 Pi's will also effectively be dead in the water. But that can be overcome by moving to a Pi which supports 64-bit.

While the Foundation will do all it can to keep software running on its existing 32-bit systems even where developers have dropped support for that, it will become increasingly difficult to do so, a move to 64-bit will effectively be forced upon them.

The question posed is; where and what is the Pi 64-bit roadmap to facilitate that ?

I don't personally expect to get an answer to that because, like everything else, Foundation plans are not revealed in advance.

[Gavinmc42]

Zero's work extremely well if you use baremetal or tiny headless Linux OS's.
For the price and support nothing else comes close.

Big bloated Desktop Linux is NOT compulsory, the limitations allows for exploring other options.
It is a 32bit 1GHz CPU with 512MB of Ram, why does it need to run Chromium or Youtube?
The B+ gets you a network version. Zero+ =- a wifi version.

Why do these have to be general purpose computers?
Why not use them as specific purpose computers?

[stuartiannaylor]

Zero's work extremely well if you use baremetal or tiny headless Linux OS's.
For the price and support nothing else comes close.

Big bloated Desktop Linux is NOT compulsory, the limitations allows for exploring other options.
It is a 32bit 1GHz CPU with 512MB of Ram, why does it need to run Chromium or Youtube?
The B+ gets you a network version. Zero+ =- a wifi version.

Why do these have to be general purpose computers?
Why not use them as specific purpose computers?

But its not about now or a singular product, its about the huge workload that is created by not simply having a roadmap with community based testing / unstable repos with Raspberry ownership of an amazing namespace by harnessing community commits.
It has nothing to do with Chromium or Youtube its a wide linux ecosphere of application and framework that irrespective of kernel seem generally to be adopting 32bit depreciation and the eventual huge workload backporting will take.
What the question is why when apart from the singular product of the zero when all others are 64bit is there not a community 64bit unstable repo in the Raspberry namespace to focus and centralise community that is likely to massively reduce foundation workload.
Its not about forcing 32bit obsolescence or saying 32bit needs to end or shouting we need Raspberry engineers working now, we need official working 64bit now.
64bit is a death and taxes question and something all really would like to escape but the reality is its something we just do our best to mitigate.
If you look at the architecture of Buster the next release of Debian https://release.debian.org/buster/arch_qualify.html when it comes to mitigation things would seem to be strangely late that with armhf are starting to garner red and yellow.
The answers we get seem strange as by not having testing/unstable repos its Raspberry who are missing community contribution and enforcing workload for themselves.

I have no awareness of Foundation operation and have no idea what "I don't personally expect to get an answer to that because, like everything else, Foundation plans are not revealed in advance."
Slightly bewildered as feel like I am in some strange Chuck Palahniuk forum where the first rule of foundation is we don't do workload mitigation.

I don't actually think the Foundation doesn't have a 64bit unstable repo because it would be akin to publishing a roadmap but I am really struggling to workout why an unstable 64bit repo is not already under the raspberry namespace.
The amount of workload that could be contained there is huge its the unstable repo that is suggest a a central point for community action and really useful that way as it can contain difference and allow larger scale mock based on community feedback with much more freedom.
It has no effect on existing 32bit doesn't even have to be indicative of raspberry but it is likely to be a central source that collates early problems on raspberry with its parallel OS Debian generally being the source of the base.
Testing repo then you get more dictate on what is raspberry and maybe some more involvement but its not actually necessary until a imminent release.
I just can not work out why Raspberry are dragging their feet on this one as it ain't roadmap disclosure are that would be batshit crazy when most of the roadmap is already out and the dictate of Debian.
Also seems crazy when they own such a value namespace to close off avenues of what is likely huge amounts of free commits.

Confused.com as it isn't about workload or roadmap but why not I am struggle to even get an angle on the situation... ???!! :/

[Gavinmc42]

but I am really struggling to workout why an unstable 64bit repo is not already under the raspberry namespace.

You need to read more posts, there is a 64bit Raspbian Debian for Pi's.
It is being worked on, but it is not stable enough yet?
About mid year it has been suggested for release.

There are quite a few 64bit Linux OS's now.
I recommend Gentoo64 at the moment or Sakaki's dual 32/64bit Raspbian.

RPF people have already said 64bit Pi's will be supported by 64bit OS's one day.
The main issue seems to be VC4 32bit memory pointers and Arm 64bit pointers or words to that effect
If you just want Chromium and Firefox - Gentoo64, if you need camera interface it is not yet working?
.Anyone is free to figure that out and help them and us all out.
But only RPF have access to the VC4 source code.

Since the 64bit release is probably going to be based on the 4.19+ kernel you could help by finding and stomping bugs.

[hippy]

I have no awareness of Foundation operation and have no idea what "I don't personally expect to get an answer to that because, like everything else, Foundation plans are not revealed in advance."

That was just my acknowledging that I know the Foundation, RPF/RPT, do not usually reveal any of their plans in advance, that I wouldn't be expecting any detailed response to asking what their plans were, or any response at all.

[fruitoftheloom]

https://forum.manjaro.org/t/manjaro-arm ... ased/75594

[mahjongg]

Just for the unaware Manjaro uses ArchLinuxArm ARMv8 as it's base:

https://archlinuxarm.org/platforms/armv ... berry-pi-3

This installation has near full support for the device, including the VC4 graphics.


Please do not read any further as it has nothing to do with my original post which was for information, please debate with Manjora Developers

Excuse me 64bit FANPEOPLE WTF has all this crap got to do with my original post, you already have discussed 32/64 elsewhere in these forums

Go start your own post

don't know what to do about that, threads diverge. There is no single point where the thread suddenly stopped talking about Manjaro and changed to 64-bit Operating systems, that is, I don't see who "hijacked the thread", or I could try to split off the "hijacked part", and no fruitoftheloom, you cannot make that decision....

you could say the same thing (a thread not going the way you wanted it) about the thread about BASIC not being used, which diverged in-to discussions about algorithms running on many other programming languages, and forgetting that a language isn't the same thing as one implementation of it.

once you create a thread, its not just you who decides where the thread leads to, its all of the participants, you don't "own" the thread.

if you think they are not talking about the point you are trying to make, redefine the talking point, and try again, just don't start duplicates.

[hippy]

I would say that, when people simply post a link to something without any context or comment, without indicating what they believe the relevance or pertinent point of what they are linking to is, they are the ones who are throwing open the door of where a thread may go.