How to completely misunderstand the politics of creating of meaningful and useful standards behaviour.. a lesson.

Standardisation by diktat - even apparent diktat doesn't work. Or when it holds together it produces a nasty horrid mess that is cobbled together and frequently not actually using the standards it claims. About the only thing +Jon Masters seems to have forgotten is the official uniform and salute.

If you want people to use your standards then you need to offer a working setup with a compelling reason to use it. Then the rest tends to follow. You also need to build standards that are intrinsically flexible. Not "do A or else" but "support A".

Look at the internet standards, they start by specifying IP and how it can be carried along with other protocols. On top of that they build things like TCP and UDP, but you don't have to use them. In practical terms it means they evolve, new ideas come along and the openness allows them to grow and prosper. Without that kind of mentality we wouldn't have video conferencing today, or even discussion about faster HTTP using UDP.

Similarly a rigorous 'lick my boots peasant' approach to PC standards would have ended up with the PC still being a 16bit system with 4.77Mhz I/O busses and Linux would still be a minixalike 32bit OS.

Of course this could be a Baldrick sized cunning plan to piss off every other vendor so much they all standardize together on something else!

Anyway Jon I think you'll find that if a bunch of people implement an aarch64 system that doesn't use UEFI and provides +Linus Torvalds  with the bootstrap code for it "its our CPU" won't let you block such support.

The UEFI/ACPI fans should also ask themselves this question

"If UEFI and ACPI are so brilliant how come with bazillions of dollars of commercial backing why isn't everyone using it. In fact why is almost everyone using things like device tree unless they are constrained politically or by force from their platform vendor to use UEFI/ACPI 

Remind you of say ... Windows ?

Alan
Edit: Comments disabled. No UEFI/ACPI hating will be happening here. The below uses wording such as "Will". You can implement anything, of course. The goal here is to use spec-like language and to provide guidance so that you know a good way to do things. And that is what I will provide: some useful software recommendations, with examples. We have an opportunity here to build a good platform from day one :)

So you're building a 64-bit ARM server? If we're not already talking, reach out to me (I'm prepared to offer as much of my time as it takes to avoid fragmentation occurring, and I will work with you to assist in your hardware and software design process if necessary - it would not be the first time I have done this for 64-bit ARM). I am preparing a position whitepaper on what components and platform software you must provide. Meanwhile, contact me if you would like to receive a draft.

Things you should know:

0. You will implement AArch64 and you will (by definition in UEFI) boot in AArch64 mode. AArch32 is optional and will not be used if implemented. You will support both 4k and 64k pages.

1. You will implement EL3-EL0. EL3 is optional, but strongly encouraged. You will run UEFI at EL2 and you will handoff to the OS loader at EL2 (again, by definition in UEFI). Precise EL2/EL1 configuration register (example) values will be provided.

2. You will boot using exactly UEFI. There will be no U-Boot, and no alternative firmware permitted. You will pass the testsuite. You will handoff using 4k pages per spec but you will align all software and hardware addresses (for stage2 translation in particular) to 64k and anticipate a high remapping by a 64k OS. Precise UEFI calls and environment (examples) to be supported will be made available.

3. You will use precisely ACPI 5.0+ and not Device Tree. If a DTB is present, it shall be totally disregarded by OSPM. Details of this implantation (example) will be made available.

I strongly recommend following what we are building in LEG (Linaro Enterprise Group) and joining the effort, because that is what will be used on 64-bit ARM servers. There's some differentiation from the above in LEG - for example, it doesn't have a position on AArch32 or 64k pages, but I am choosing to take a personal position in the above.
Shared publiclyView activity