[wronglebowski]

It’s incredible how bad driver support is the ARM space. I was looking into some of the various Ambernic handhelds and their Linux firmware. Despite their SoCs being advertised as having Vulkan 1.1 support every firmware for the device ships with it disabled.

[ryandrake]

So many chipmakers and development board manufacturers see software/driver support as some kind of necessary evil--a chore that they grudgingly do because they have to, and they will do the absolute minimum amount of work, with barely enough quality to sell their hardware.

[ozarkerD]

It bewilders me. Software's gotta be easier than hardware right? Not that either is easy but as a software engineer, the engineering that goes into modern hardware mystifies me.

[bri3d]

It's different definitions of "easy."

With hardware, you have about one billion validation tests and QA processes, because when you're done, you're done and it had better work. Fixing an "issue" is very very expensive, and you want to get rid of them. However, this also makes the process more of, to stereotype, an "engineer's engineering" practice. It's very rules based, and if everything follows the rules and passes the tests, it's done. It doesn't matter how "hacky" or "badly architected" or "nasty" the input product is, when it works, it works. And, when it's done, it's done.

On the other hand, software is highly human-oriented and subjective, and it's a continuous process. With Linux working the way it does, with an intentionally hostile kernel interface, driver software is even more so. With Linux drivers you basically chose to either get them upstreamed (a massive undertaking in personality management, but Valve's choice here), deal with maintaining them in perpetuity at enormous cost as every release will break them (not common), or give up and release a point in time snapshot and ride into the sunset (which is what most people do). I don't really think this is easier than hardware, it's just a different thing.

[generativenoise]

From the outside looking in. It really seems like both fields are working around each other in weird ways, somewhat enforced by backwards compatibility and historical path dependence.

The transition from more homogeneous architectures to the very heterogeneous and distributed architectures of today has never really been all that well accounted for, just lots of abstractions that have been papered over and work for the most part. Power management being the most common place these mismatches seem to surface.

I do wonder if it will ever be economical to "fix" some of these lower level issues or if we are stuck on this path dependent trajectory like the recurrent laryngeal nerve in our bodies.

[altfredd]

> intentionally hostile kernel interface

If open-sourcing your entire kernel is being "hostile", I don't think that there is or ever was a "friendly" OS.

[OvermindDL1]

I think what they were referencing with that is that the kernel hardware interface is unstable, it changes literally every version, which is why you went to upstream it so you don't have to keep it up yourself after that.

[IshKebab]

I've done both. There are difficulties with both but overall I would say software is significantly more difficult than hardware.

Most hardware is actually relatively simple (though hardware engineers do their best to turn it into an incomprehensible mess). Software can get pretty much arbitrarily complex.

In a way I suspect it's because hardware engineers are mostly old fogies stuck in the 80s using 80s technologies like Verilog. They haven't evolved the tools that software developers have that enable them to write extremely complicated programs.

I have hope for Veryl though.

[vrinsd]

Wow, super hard disagree, comment here sounds like the typical arrogance hardware engineers face from people in software who've never really done the job or have some superficial experiences.

I won't blindly state "software is easier" but software is definitely easier to modify, iterate and fix, which is why sofware tools and resulting applications can evolve so fast.

I have done both HW & SW, routinely do so, and switch between deep hardware jobs and deep software so I'm qualified to speak.

If you're blinking a light or doing something with Bluetooth you can buy microcontrollers that have this capability and yes that hardware is simple.

But have you ever DESIGNED a microcontroller, let alone a modern processor or complex system ?

Getting something "simple" like a microcontroller to reliably start-up involves complex power sequencing, making sure an oscillator works, a phase-locked-loop that behaves correctly and that's just "to make a clock signal run at a frequency" we're not talking about implementing PCIe Gen5 or RDMA over 100Gbps Ethernet.

Hardware engineers definitely welcome better tools but the cost of using an unproven tool or tool that might have "a few" corner cases resulting in your $5-million SoC not working is a hard risk to tolerate, so sadly(and to our pain) we end up using proven but arcane infrastructure.

Software in contrast can evolve faster because you can "fix it in software". New tools can be readily tested, iterated on and deployed.

[IshKebab]

> But have you ever DESIGNED a microcontroller

Yes... But in fairness I was just talking about the digital RTL, not the messy analogue stuff (PLLs, power/reset, etc.) I've never done that.

> but software is definitely easier to modify, iterate and fix,

Definitely true.

> which is why sofware tools and resulting applications can evolve so fast.

Not sure I agree here though. It seems to me that EDA tools evolve super slowly because a) hardware engineers are timid old fogies who never want to learn anything new, and b) the big three have a monopoly on tooling.

[poly2it]

What do you think about Atopile? I'm not a hardware person yet, but these seem similar.

https://atopile.io/

[bri3d]

PCB and RTL are completely separate disciplines.

[Melatonic]

Software can always ship a new update for bugs or features.

Hardware not so much

[lonjil]

In my experience, hardware companies all believe that software is trivial nonsense they don't need to spend any effort on. Consequently, the software that drives their hardware really sucks.

[OneDeuxTriSeiGo]

Software is easier than hardware in general but companies generally pay their hardware guys 25-50% less than their software counterparts

[sgerenser]

People repeat this line a lot but I don’t think it’s true. Companies like Intel, AMD, Arm, Broadcom, etc. afaik all pay their software folks of equivalent YoE or level roughly the same as their hardware folks. To the extent there’s any difference, it’s much less than 25%.

OTOH, there’s a small slice of (mainly) software companies like Google and Meta, along with Unicorn private companies, that skew the average software engineer salary high. Then there’s a long tail of “old school” hardware companies like TI, Motorola, Atmel, Microchip, and tons of smaller less well known companies that all pay much lower than Google. But they pay their software people poorly as well.

So if you just look at “average software engineer salary” vs “average hardware engineer salary” it appears that SW people are making 50% more than HW people, but it’s not at the same companies.

[OneDeuxTriSeiGo]

> Companies like Intel, AMD, Arm, Broadcom, etc. afaik all pay their software folks of equivalent YoE or level roughly the same as their hardware folks.

This is a fairly new phenomenon and it's mostly a consequence of the AI hype wave driving investment in hardware. Wages have mostly caught up at the big boy hardware companies but you'll still generally see a disparity outside that big group.

[makeitdouble]

Come to think of it, for them it is basically customer support.

Most will want to outsource it as cheap as possible and/or push it to the community. They won't care if it takes an eternity for the customer to get their issues solved as long as new customers keep buying.

And a few companies will see an opportunity to bring better customer care as an advantage and/or integrate it in their philosophy.

[LtWorf]

And it's the reason why for several years I didn't consider buying anything that had an AMD card (not now, but for many many years it was insanity).

[doubled112]

Are you talking about the FGLRX drivers on Linux desktops?

Or their Windows driver quality back then?

I remember them both being pretty brutal.

[LtWorf]

The linux desktop was my reason.

[andyferris]

But - doesn’t open sourcing it kinda make it someone else’s chore?

Obviously it has to “work” at sale but ongoing maintenance could be shared with the community.

[opan]

I would recommend the Anbernic RG353M running ROCKNIX, or for a more powerful device, Retroid's Pocket 5 running ROCKNIX. Most other options have awful software support and are just e-waste, unfortunately.

[colechristensen]

They're stuck in the building model of making semi-custom SoCs for enormous corporations and releasing/developing drivers for them in extreme NDA environments.

It's fine (or arguably not) for locked down corporate devices.

Not so fine for building computers people want to use and own themselves.