06-12-2016, 06:40 AM
(06-11-2016, 06:02 PM)ssvb Wrote: They are trying to implement whatever has practical value. And nothing is set in stone, the work is still being done.It sounds very subjective. Who's deciding on that "practical value"? Some standard may be whether supported or not supported. There is no such a thing like "partially pregnant".)
Anyway I wish them success, I am not fighting uboot, I am just trying to implement UEFI firmware on few arm/mips SBC's. With the intention to give it to grow and evolve if it succeeds and is interesting for others.
Quote:However U-Boot currently has much better UEFI support than your implementation. Simply because your implementation does not exist yetI agree, U boot is better than what doesn't exist yet.
Quote:Do you realize that "Uefi is an advanced firmware standard, and it can give a rich set of booting possibilities for end users. Of mini PC range as well. It's not tight to servers at all. GPT partitioning, exhaustive list of boot options from any imaginable media and protocol - eMMC modules, SD cards, USB sticks, SSD drives, SATA and SCSI HDD drives, CD roms, network, UART, etc. It has security options (if needed)" is not something that automatically comes as given with UEFI? It is just a big task list for you. Can you handle all of this work alone and in a reasonable time frame?Clearly, it's big, it's huge, but fear is not a rational argument.
Well, I've enumerated all the possibilities that Uefi can handle, this not necessarily is presented on every machine. For example miniPC's don't have PCI, and SCSI hard drives aren't often used there. CD drives also.
So I will begin with only a subset of peripherals which are presented on SBC's - eMMC, NAND, SD, USB, UART, network. And then someone interested might add.
Quote:And I believe that U-Boot is doing a reasonably good job. Standards exist for interoperability and U-Boot implements them. This works.I didn't say it's doing a bad job, it just has its way. But to be honest, it doesn't implement standards (yet). At most it does it partially, like with this awkward Uefi adoption or Device Tree support pulled off from OpenFirmware. Does it use device tree at all, or just blindly gives it away for the linux kernel?
But of course, It has an undoubtful advantage - it already works (at least by the principle "better than nothing").
Quote:U-Boot is on the way to support booting Windows: http://lists.denx.de/pipermail/u-boot/20...55532.htmlThis. The normal firmware should boot every appropriate client from the very beginning. And not invent for itself after decade of existing, that there are other clients except linux. This is for what such standards like ARC/OF/UEFI existed and exist - they provide a unified standardized way for FW to interact with OS (loaders). And every OS, aware of this standard can be loaded by the normal fw without any special efforts.
Quote:Which core?Uefi core. If you are a Uefi driver developer, you write your driver and when it is finished, you just install it on the board among the already installed uefi. Uefi finds it and loads and runs it.
You don't have to learn all Uefi internals and compile it in order to add your driver. or a test application. or an OS loader. And the main thing - writing such a driver for Uefi is easier than extending uboot. Because it has a well defined driver model and the core gives you a very rich set of services to facilitate your work. It's not only helper fuinctions, it's the whole API and rules and model. it is developed very well. just read how driver binding in uefi occurs, what ConnectController() does for this. for example. very much burden is put into uefi core, and thus the driver developer may take advantage of this.
Quote:Let's be honest, the maximum you have on a particular board now is an ability to boot from SD/eMMC. And possibly through TFTP. And board vendors obviously are struggling to add in uboot something yet (like USB boot), despite these features are often requested. Easiness of multiboot and from any media on uboot exists only theoretically, the same as my Uefi implementation.Quote:uefi gives a very powerful and well defined set of services for implementing device support, it has well developed UEFI driver model. End users would advantage of this having more abilities to boot their OSes, this is especially relevant for development boards on which often there is a need to try many builds of different OSes or to have easily achieved and managed multi boot options. Uefi is designed for this. You are inserting your SD card with as many GPT partitions as you want with tons of OSes installed on them, insert USB stick, plug in an HDD and network, and are able to boot from any of this media choosing options in boot menu. Of course, it's kind of idyll, but it's possible.So what? You are listing the features that are already provided by U-Boot.
ANT - my hobby OS for x86 and ARM.