MrHamburger

Maybe it is stagnant because companies does not need to compete for staff?

I would just start working for a different company and ignore the one I don't want to work for. What is the one trying to hold me going to do? Fire me for abstention? Well that's my goal to begin with.

> The OS receives the devicetree in a memory location

Which memory location? Any ARM SoC does not have defined where RAM must be. So which address are you going to touch from your OS to get the configuration? Yep, that's exactly what UEFI and ACPI are for

And no "at the end of kernel image" is not a memory location, because then your solution works only with your specific ad-hoc setup. All the Linux distros are not working, BSD is not working, Windows is not working. Only your blessed Linux Kernel will work and that's going to be all. No difference from adding a device tree directly into a Kernel then.

Because it is a standard. Your proposed solution is ad-hoc which will work on your device(s), but nowhere else.

Just make a mind experiment - Is flash memory SPI or parallel NAND? What if it is a Parallel NOR? Is EEPROM I2C? On which address? Which I2C controller should you use if there is more than one? Is EEPROM SPI? Which SPI controller you should use? How you should configure your SPI/I2C/Parallel controller? Which registers, on which addresses? On which GPIO pins is your memory device connected?

You would still need some board specific mini device tree in your OS to resolve this issue. That's the reason why we have UEFI booting first and letting board manufacturer resolve it and then just providing a communication layer to make standardized queries without knowing all those questions above.

1. Sourcing is difficult. Would you buy some random batteries from China? Do you trust the dealer that it won't fry your customer in few months after installation? Can you verify that what they are selling is what you have in your hand?

2. You need to know a lot about batteries and even more about battery management system and then know how to integrate batteries + BMS into a car. Sure you might be able to reuse existing BMS for a car you are targeting but it will quickly become a bottle neck in your manufacturing if you do so.

3. Pairing of parts. Related to point 3. You might be able to build a battery pack, are you able to also force the car to take the battery pack? Car might outright refuse to talk to it, because it is not paired and OEM won't let you pair it, because "safety", but more like safety of their profits.

4. Shipping of Lithium batteries in general is huge PITA. Try to ship battery of any size with Fedex/DHL/UPS. They either outright refuse to or you will pay a lot of extra.

Open and free devicetree is absolutely useless if it needs to be part of OS image. The purpose of ACPI and UEFI is to have single booting mechanism with standardized device enumeration which is available directly on the hardware. If you need to have a random file in your OS image to actually boot on board X and if you have a file for board Y then OS will just crash boot loop, then your solution is useless for 90%+ of users because people are not going to build their own Linux distributions for their own hardware.

If you know what board are you booting on, then you can load correct hardware drivers for everything else. But that's not going to work without UEFI and ACPI.

To disrupt any kind of x86 dominance ARM Motherboard manufacturers will first need to get their UEFI and ACPI support working first, otherwise their boards are nothing more than one-purpose toys running only a specific build of a system.

With this logic you should also insist on legs instead of wheels.

AI drone with pattern recognition of military vehicles and personnel is being furiously developed on Ukrainian and Russian side to circumvent ever present electronic warfare. So the model is expected to run offline on cheap disposable hardware. That's where the most obvious business case today is.

I don't think that whole battery pack will be standardized, more like it will have slots for smaller standardized packs (i.e. 10kg ones). Similar to standardization in PC.

That would be solving so many problems.

1. Repairability - You can replace all packs, or just some. Depends on your financial situation.

2. Independence - You are not dependent when your company will stop manufacturing your special battery pack.

3. Longevity - You can buy 10 year old car with dead battery and buy latest set of standard packs with latest battery technology, suddenly your car is having twice the range than it was a new. Like HDD -> SSD

4. Less dependency on street infrastructure - You can charge the car on a charger or if you can't charge at your place, you can just pull one or two packs out of your car and charge them on 230V in your apartment or hotel room.

5. No wall box needed - You can have two sets of these standardized packs. You can put one into garage where it will be charged during the day (i.e. Solar array) and you can use the other one in your car. Swap them when needed.

Changing a head gasket will be detected by what exactly? Rebuilding your failed transmission (the wheels inside) will be detected by which sensor?

Battery pack being DRM locked, while gas tank can't be.

> Companies not respecting consumer rights isn't an inherent property of having an electric drivetrain.

But it is so much easier. How car will tell that mechanical part has been changed? It can't.

But you can replace any of those 2000 moving parts with same one from eBay. You can either make your own if you know how. You can't change DRM locked part unless it is a new one and installed by approved technician using approved software for installation. Have you been naughty boy? No parts for you.

This will work against all new cars in general.

> Plus Tesla still has trouble with parts and service. The company is twenty years old now. They should have that figured out.

This is direct result of constant changes in the hardware during manufacturing. It might look good from customer perspective that they are always getting latest and greatest hardware, but it is an absolute nightmare from aftermarket perspective as you don't have Model X, but "Model X 2020 Week 23" which was only model using part XYZ v1, every other model is using part XYZ v2, which is not compatible with v1 model. It gets really messy really fast.

Regular OEM manufacturer won't get into this issue simply because they will close the changes and then will manufacture exactly same car with exactly same parts for i.e. 5 years straight.

Imagine sharing pirated content on i.e. AWS, which would cause disconnection of whole AWS. Easy way how to get rid of competition.