AVR32 Architecture Called For Removal From Mainline Linux Kernel

[starshipeleven]

That's not my point at all. Primarily I'm trying to point out that new stuff is based on or built-on top of old stuff. Writing portable code makes it adaptable, more robust and useful going forward. Throwing everything out and starting again, recreating the wheel each time, is something that happens all the time in closed source development, but it's not something to aspire to, and it doesn't obviously improve development time or reduce costs.

I agree here but I still don't see how it is related to his post. He just ignores that 32bit in non-x86 archs isn't outdated garbage. We are all taking of arch-specific code here.

[L_A_G]

Well if it was another microcontroller architecture I'd definitely be raising an eyebrow, but seeing how we're talking about AVR32 I'm not exactly going to throw my hands up and protest.

When the first AVR32-based chips launched they did so into a market that had already been cornered by companies with way more money for development and marketing not to mention being more established. Their 8 bit ATMega chips did and still do have a nice niche, but you're just going to go up against ARM in the 32 bit microcontroller market and come out of it as a winner unless you have absolutely enormous amounts of money to burn.

[Azrael5]

Not so fast. A lot of embedded devices are 32bit only and the Linux kernel is king on this environment.

How to know if an embedded device supports only 32bit? However if the main board manufacture states that its main board is 64bit compliant I assume its devices support both 32 and 64bit. Normally drivers are available for both the platforms.

[starshipeleven]

How to know if an embedded device supports only 32bit?

Look at processor type. ARM v8 cores have theoretically support for 64-bit but pretty much all the times are run in 32-bit mode because they don't mount more than 1-2GB of RAM. Older ARM is 32 bit.

Also looking at RAM size is a general rule of thumb to assume what hardware has no 64 bit support or is running in 32bit mode. Most embedded devices don't have anywhere near 512MiB. For a router even 128MiB is a lot.

Mobile segment is another matter, and quite frankly would do fine with 32 bit too, but having octa-cores, 6 GiB of RAM and 4k screens seems to be crucial for some models.

However if the main board manufacture states that its main board is 64bit compliant I assume its devices support both 32 and 64bit. Normally drivers are available for both the platforms.

embedded devices have no "main board" and don't usually state their bits.

32bit is usually chosen even when 64bit is available because it is faster for the intended tasks and uses less resources, which is preferred for embedded devices.

[Brane215]

Seems reasonable to remove AVR32. This was Atmel's try to make a 32-bit architecture for microcontrollers and it failed pretty miserably in the market. It never took off and quickly was displaced by ARM's Cortex-M line of cores.

AVR32 is far from miserable. It's very decent 32-bit microcontroller. Thing is that it was never emant to run Linux, since it doesn't have necessary horsepower nor an MMU or FPU, at least in base models. AVR32 is a very nice, simple core, for which Linux is way over its reach. Sure, you can do it without address translation etc, but that's a rape of its fundamental design.

Microchip still offers it after Atmel acquisition. gcc still supports it AFAIK and that's much more relevant.

[Azrael5]

Look at processor type. ARM v8 cores have theoretically support for 64-bit but pretty much all the times are run in 32-bit mode because they don't mount more than 1-2GB of RAM. Older ARM is 32 bit.

Also looking at RAM size is a general rule of thumb to assume what hardware has no 64 bit support or is running in 32bit mode. Most embedded devices don't have anywhere near 512MiB. For a router even 128MiB is a lot.

Mobile segment is another matter, and quite frankly would do fine with 32 bit too, but having octa-cores, 6 GiB of RAM and 4k screens seems to be crucial for some models.

embedded devices have no "main board" and don't usually state their bits.

32bit is usually chosen even when 64bit is available because it is faster for the intended tasks and uses less resources, which is preferred for embedded devices.

So linux operating system which kind of drivers install when 64bit platform has been chosen? 32bit or 64bit? How to know this information? If the user prefer a pure 64bit operating system what he must to do?

[starshipeleven]

So linux operating system which kind of drivers install when 64bit platform has been chosen? 32bit or 64bit? How to know this information? If the user prefer a pure 64bit operating system what he must to do?

If you choose 64, then only 64 bit drivers. If 32 the only 32 bit drivers.

Userspace programs can be both 32 or 64 bits on a 64bit system or only 32 bit on a 32 bit system.

Hardware may be capable of working in 64 bit, but if you install a 32-bit kernel on it, it will work in 32-bit mode.

[s_j_newbury]

I agree here but I still don't see how it is related to his post. He just ignores that 32bit in non-x86 archs isn't outdated garbage. We are all taking of arch-specific code here.

Maybe I was reading too much into his comment, but to me it read that he was suggesting development should just focus on the architecture/platform du jour (or at least just 64-bit capable CPU designs). It brought back to mind the situation with Chromium and Firefox dropping generic portable code in favour of multi-platform implementations* or even just maintaining x86-64/SSE2+ code-paths, which apparently only I have a problem with.

* SIMD accelerated functions are great, but they should be optimisations not a requirement, at least at source level

[starshipeleven]

Maybe I was reading too much into his comment, but to me it read that he was suggesting development should just focus on the architecture/platform du jour (or at least just 64-bit capable CPU designs). It brought back to mind the situation with Chromium and Firefox dropping generic portable code in favour of multi-platform implementations* or even just maintaining x86-64/SSE2+ code-paths, which apparently only I have a problem with.

* SIMD accelerated functions are great, but they should be optimisations not a requirement, at least at source level

Meh, that's just a browser. I agree on the principle but it isn't crucial for the system so I'm not worried.
I prefer them having more oomph to fix stuff on supported platforms than keeping the door open to an hypotetical new platform that isn't something that pops out overnight (so you have time to add it if needed).

[technosaurus]

The same thing happened with the h8300 architecture in 3.12. and later restored by Yoshinori Sato, but the kernel gatekeepers then treated it like a new architecture so the new version predominantly uses the kernel's generic code, making it incompatible with older kernels. Most importantly the syscall numbers are all different, yet there is no mention of that in any documentation. Likewise the commits that removed avr32 don't bother to document its removal anywhere. It would be nice to at least acknowledge previously supported architectures somewhere; not just for credits, but also just in case there is a revival of the architecture (like j-core is doing for SuperH)