OSDev.org

This is becoming a bad habit between the two of us.

bzt wrote:Erhm, invalid how?

"manufacturer couldn't care less" vs. "manufacturer actually supplies it". "Invalid" was probably the wrong word. "Wrong" would have been better.

bzt wrote:DT is still a Linux thing

At least u-boot also uses it.

bzt wrote:and the other manufacturers don't give a sh*t about providing DTBs (in contrast to ACPI tables which are in memory so manufacturers must provide it in the firmware regardless to the OS).

At least one manufacture cares enough. That is enough to disprove your claim that no manufacturers care. In reality the number of manufacturers that care exceeds one, and is not limited to just PowerPC. Now on x86, yes, there nobody makes DTBs. But x86 is often lost in its own little world. It is starting to infect the ARM world. We shall see.

bzt wrote:And you can just as well fix an AML in five minutes.

Last time I had a BIOS update it took significantly longer than five minutes.

bzt wrote:The problem is, if it's wrong, how do you know what are the correct parameters (for both ACPI and DT)?

Documentation. If unavailable, choose another manufacturer.

bzt wrote:Sadly no. The market is dominated by x86, and now with the rise of mobiles ARM. All the others' share are just marginal (sadly, I liked PowerPC a lot).

Depends on "market". Desktops and servers, yes. Embedded not so much. Embedded is dominated by ARM instead. And yes the rest is marginal, but not dead yet.

bzt wrote:Yes, of course I know, that's the reason why I've linked it... What is your point here?

The sentence immediately following was the point. Sometimes even different sentences are connected.

bzt wrote:There's no other way to detect hardware on many architectures,

No other reliable/universal way, yes. You could also require the bootloader to identify the platform and hold a repository of information on how a bunch of specific mainboards work, and for a small kernel that only has to run on computers the author directly controls, this could be enough. And that is exactly what DTBs are.

bzt wrote:Citation needed! How on earth could some tables and bytecode in memory shut out an OS??? That just makes no sense.

Probably bad word choice on my part. I was referring to the _OSI method and how you need to pretend to be a recent Windows version to get the AML to give you all the features.

nullplan wrote:

bzt wrote:Erhm, invalid how?

"manufacturer couldn't care less" vs. "manufacturer actually supplies it". "Invalid" was probably the wrong word. "Wrong" would have been better.

Nope, I wrote, "manufacturers", in plural. Just because there's one or two exceptions, doesn't make DT a world-wide industry standard. Let me put it this way:

Hardware that support ACPI for sure: ALL desktops, ALL servers
Hardware that might support: ALL arm, ALL ppc, ALL mips etc. (there's an ACPI table for the Raspi too and for many other ARM boards. Interestingly TianoCore devs can convert DT into AML...)
Mainstream OSes that support ACPI: ALL. Literally. Win, Mac, Linux, BSDs, even non-mainstream ones like Haiku, ReactOS, whatever. All SMP capable hobby OS included.
Compatiblity: well-defined standard. Even if you don't rely on ACPICA library, you're good.

Now on the other hand:

Hardware that support DT: marginal, less than 5% of all the computers have DTBs, and those are not created by the hardware manufacturers
Mainstream OSes that support DT: Linux, some BSD. End of list.
Compatibility: no promises. Neither on the libfdt API, nor on the DTB format. Even if you use the "official" library, you can find yourself on the wrong side of the s*cked d*ck easily.

nullplan wrote:

bzt wrote:DT is still a Linux thing

At least u-boot also uses it.

First u-boot is not a kernel at all, but a loader that passes the DT blob to the actual kernel and second, from the Device Tree's CONTRIBUTORS file: Rest assured, DT is a Linux thing.

nullplan wrote:Now on x86, yes, there nobody makes DTBs. But x86 is often lost in its own little world. It is starting to infect the ARM world. We shall see.

ARM world doesn't care either. On RaspberryPi the DTB is actually loaded from a file only to pass to the kernel. And it is created by the reseller, Raspberry, not the manufacturer, Broadcom!

nullplan wrote:Documentation. If unavailable, choose another manufacturer.

No commertial product has that kind of detailed documentation. Open hardware are extremely rare.

nullplan wrote:

bzt wrote:Sadly no. The market is dominated by x86, and now with the rise of mobiles ARM. All the others' share are just marginal (sadly, I liked PowerPC a lot).

Depends on "market". Desktops and servers, yes. Embedded not so much. Embedded is dominated by ARM instead. And yes the rest is marginal, but not dead yet.

Market as in all computers included all around the globe. On ARM, seriously @nullplan, learn to read. I also wrote that now ARM dominates, so WTF?

nullplan wrote:The sentence immediately following was the point. Sometimes even different sentences are connected.

You should take your own advice, see the quote above. And just for the records, I was talking about (instead of converting DT into AML and vice versa, as any sane person would) they actually planning to embed untouched DTB blobs in an ACPI entry, essentially duplicating all descriptions and doubling the size of all the system tables without no guarantee that the two match. Now isn't that just plain stupid?

nullplan wrote:Probably bad word choice on my part. I was referring to the _OSI method and how you need to pretend to be a recent Windows version to get the AML to give you all the features.

Still makes no sense. It is your kernel that interprets the AML bytecode, and only the parts it wants to interpret. ACPI has no say in that matter at all. Neither the ACPI tables nor the AML is "watching", so there's no-one to pretend for.

Cheers,
bzt

If OS developer don't want to deal with a DTB, then, well, we are just hobbyists. I plan on using AML and ACPI (and I'm excited to implement it ), but I don't see why one would have to use the DTB. Also,

bzt wrote:All SMP capable hobby OS included.

is not true, as one can use the MP spec (in theory)

nexos wrote:is not true, as one can use the MP spec (in theory)

Good luck finding MP tables on a non-ancient system. QEMU doesn't count.

bzt wrote:No commertial product has that kind of detailed documentation. Open hardware are extremely rare.

You first say that no commercial product has that kind of documentation, then you say open hardware is extremely rare -- meaning that commercial products do actually have that documentation because open hardware is, you know, commercial. And, as a matter of fact, neither of the above quoted sentences are true. The Armv8-M processor contains a system address map for the processor on page 250 of the Armv8-M Architecture Reference Manual. Where the manual falls short, embedded devices like the Raspberry PICO fill the gaps. Also, I'd like to point you to all the other embedded hardware out there that's supposedly 'not commercial'. How about the HiFive1 Rev. B or the Freedom Unmatched? Both of these devices are open hardware but they are also commercialized.
Now, if you meant devices that are truly closed devices like the Pixel, the first statement is true, but that's because those devices were never built with the intention to allow you to run anything else than what they come with, and so the manufacturer has no reason to publish the address map for those devices. But the second statement -- that open hardware is rare -- is not true at all. If anything, open hardware is becoming more and more popular as the years go by.