Re: [U-Boot] Edison's U-Boot Architecture
On Mon, 2017-10-09 at 14:45 +0300, Andy Shevchenko wrote: > On Mon, 2017-10-09 at 08:10 +0200, Zoran Stojsavljevic wrote: > > > > Andy/Andrej, > > Andy is okay :-) > > > Question here: Did I get the correct idea how Edison works with U- > > Boot? Could you, please, elaborate how this is done with Edison? > > See above > > > (Vopros sdes6: Ja praviljno ugadal kak eto sdelano/rabotaet? Mozno > > bolee dannih kad celaja eta arhitectura rabotaet so Edisonom?) > > Ne ugadal :-) Smotri vyshe. Btw, I'm going to attend ELC2017 Europe (in Prague), anyone who has questions, comments, anything to discuss or just have a dinner, are welcome! -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Edison's U-Boot Architecture
On Mon, 2017-10-09 at 08:10 +0200, Zoran Stojsavljevic wrote: > Hello Andy, > > Thank you very much for the reply. Instead reply-ing to you in Open > Source fashion, I'll answer to you in the form of the new @. Easier > and more clean/clear approach. > > Nevertheless, Edison is cancelled. But since it is already out there, > and you do it, and using it as the test vehicle Let me start asking > in the Edison/Tangier core design light the similar questions, I > already have asked on this list about U-Boot E3900 and BDW-DX > architectures. I hope you understand that I can't comment much on the internals. I would point out that Intel Tangier (and basically entire Intel MID family has beyond the poor documentation available publicly). > We all know (or I assume U-Boot list knows about Coreboot) and I also > assume majority of the people heard how x86 does work for Coreboot. > Quick recap: > https://www.intel.com/content/www/us/en/intelligent-systems/intel-firm > ware-support-package/intel-fsp-overview.html > > And we have here in nutshell the following peculiar architecture as > the result of FSP: FSP/Coreboot inter-mingled with U-Boot as a > Coreboot's payload!? Practically three boot-loaders to bring x86 > architecture to YOCTO... FSP being binary blob, actually translating > to three binary blobs in FSP 2.0 spec. > > And we know that U-Boot maintainers do not allow binary blobs in U- > Boot. Not like this. > > So, what we really want: independent U-Boot on x86, don't we? > > I am curious about the following x86 HW/FW configuration with regards > to the U-Boot? > > In order to protect INTEL Intellectual Properly (IP), FSP is invented. > Seems that FSP did NOT solve any of the issues. Furthermore, I have no > idea how big projects/players are using x86 with U-Boot (example: BMW, > their Ulm and Munich IT Car depts.) are using YOCTO with x86. > > My best guess is that they have private U-Boot (NOT public one), > already adjusted to work as two stage boot-loader, with very clean > division of the layers. First of all, you have to distinguish ACPI/UEFI enabled platform vs. non-as-such. Almost all platforms you are talking about are UEFI compatible and thus no magic here, U-Boot can be just a UEFI application. Some of them might not use that approach (own or different BIOS), but this is beyond my scope. > Something like this (in the lieu of Tangier, as an example): > > Edison/Tangier cores -> IFWI -> MBR -> U-Boot -> eLinux/YOCTO ?! Nope. Intel MID has quite different boot flow. I can't tell much, but there is much more happened before IFWI, and not exactly how you put it after. > Here are some explanations regarding the terms/context: > > IFWI is the Intel FirmWare Interface, a binary blob loaded from the > eMMC boot partition that executes a secondary loader (in this case U- > Boot) from the main eMMC. IFWI blobs for the x86 are provided by > Intel. That's correct. > Normal IFWI eMMC boot process > > On-chip boot rom inits eMMC and loads IFWI from the MMC boot > partitions > IFWI looks for OSIP header at top of eMMC (MBR boot block) AFAIU OSIP is a header of DnX protocol (which is in [OTP] ROM) and runs before IFWI. On the actual media there is nothing like OSIP headers. > The header directs IFWI to the start, size, load address, and entry of > U-Boot in eMMC > (need clarification) If u-boot is not found, try the alt u-boot image > at 5MB into the eMMC Those are just two partitions on eMMC. Look at Edison closer. U-Boot is used as a chain loader (32-bit application) in similar way as UEFI app. > U-Boot is loaded into RAM and executed > OSIP stands for OS Image Profile, and it is nothing more and less than > INTEL name for very known old fashion MBR, considering DATA structure. This is incorrect (except, perhaps, the abbreviation decode of OSIP). > Andy/Andrej, Andy is okay :-) > Question here: Did I get the correct idea how Edison works with U- > Boot? Could you, please, elaborate how this is done with Edison? See above > (Vopros sdes6: Ja praviljno ugadal kak eto sdelano/rabotaet? Mozno > bolee dannih kad celaja eta arhitectura rabotaet so Edisonom?) Ne ugadal :-) Smotri vyshe. > > (I da, esli est6 informacii na Russkom, davaite ih... Rasberus6! Ja > boltaju Russij jazik tocno kak Russkie rozdennie). ;-) Nice! Though mailing list is for wider audience. Can't use non-English, except for swearing like Linus in Finnish :-) Information on public is so little WRT Intel MID family. The best way to get something is to read code, comments, and commit messages during Linux kernel history. You may try to search on communities.intel.com for Edison forum. This might shed some light on something. -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Edison's U-Boot Architecture
Hello Andy, Thank you very much for the reply. Instead reply-ing to you in Open Source fashion, I'll answer to you in the form of the new @. Easier and more clean/clear approach. Nevertheless, Edison is cancelled. But since it is already out there, and you do it, and using it as the test vehicle Let me start asking in the Edison/Tangier core design light the similar questions, I already have asked on this list about U-Boot E3900 and BDW-DX architectures. We all know (or I assume U-Boot list knows about Coreboot) and I also assume majority of the people heard how x86 does work for Coreboot. Quick recap: https://www.intel.com/content/www/us/en/intelligent-systems/ intel-firmware-support-package/intel-fsp-overview.html And we have here in nutshell the following peculiar architecture as the result of FSP: FSP/Coreboot inter-mingled with U-Boot as a Coreboot's payload!? Practically three boot-loaders to bring x86 architecture to YOCTO... FSP being binary blob, actually translating to three binary blobs in FSP 2.0 spec. And we know that U-Boot maintainers do not allow binary blobs in U-Boot. Not like this. So, what we really want: independent U-Boot on x86, don't we? I am curious about the following x86 HW/FW configuration with regards to the U-Boot? In order to protect INTEL Intellectual Properly (IP), FSP is invented. Seems that FSP did NOT solve any of the issues. Furthermore, I have no idea how big projects/players are using x86 with U-Boot (example: BMW, their Ulm and Munich IT Car depts.) are using YOCTO with x86. My best guess is that they have private U-Boot (NOT public one), already adjusted to work as two stage boot-loader, with very clean division of the layers. Something like this (in the lieu of Tangier, as an example): Edison/Tangier cores -> IFWI -> MBR -> U-Boot -> eLinux/YOCTO ?! Here are some explanations regarding the terms/context: *IFWI is the Intel FirmWare Interface, a binary blob loaded from the eMMC boot partition that executes a secondary loader (in this case U-Boot) from the main eMMC. IFWI blobs for the x86 are provided by Intel.* *Normal IFWI eMMC boot process* 1. *On-chip boot rom inits eMMC and loads IFWI from the MMC boot partitions* 2. *IFWI looks for OSIP header at top of eMMC (MBR boot block)* 3. *The header directs IFWI to the start, size, load address, and entry of U-Boot in eMMC* 4. *(need clarification) If u-boot is not found, try the alt u-boot image at 5MB into the eMMC* 5. *U-Boot is loaded into RAM and executed* *OSIP stands for OS Image Profile, and it is nothing more and less than INTEL name for very known old fashion MBR, considering DATA structure.* Andy/Andrej, Question here: Did I get the correct idea how Edison works with U-Boot? Could you, please, elaborate how this is done with Edison? (Vopros sdes6: Ja praviljno ugadal kak eto sdelano/rabotaet? Mozno bolee dannih kad celaja eta arhitectura rabotaet so Edisonom?) (I da, esli est6 informacii na Russkom, davaite ih... Rasberus6! Ja boltaju Russij jazik tocno kak Russkie rozdennie). ;-) Thank you in advance, Zoran ___ On Sun, Oct 8, 2017 at 3:45 PM, Andy Shevchenko wrote: > On Sat, 2017-10-07 at 16:32 +0800, Bin Meng wrote: > > +Cc: Ferry (he might be interested in this thread) > > > > Edison?! Edison is dead (end), as I know it... > > Some people don't think so, there are ones who like the board. > > Actually, while working for Linux kernel at Intel I'm using that board > on almost daily basis to do many tests which are not related strictly to > Edison or even Tangier. > > > > The project is cancelled. > > That's correct [1]. > > But be honest, don't you like the idea to have an example of the board, > which was never designed to be ACPI compatible, actually to become one > (as much as hardware and ACPI specification allow to, of course)? > > Besides that I have started looking into Edison's stuff around spring > time of 2015. You may see my progress here [2] (first article dated > 27.03.2015, the chapter "6 What is working and what doesn't" shows > progress of upstreaming). U-Boot was appeared on my radar when the stock > one stopped working with vanilla kernels. > > > > Correct me if I am wrong! > > See above. > > > I don't know that story. Loop Andy in to comment. > > Thanks, Bin, for including me in the loop. > > > But my understanding > > is that these are pretty much Intel Tangier SoC related, > > ...and Merrifield as a platform, which had been used in some x86-based > phones. > > > and Edison is > > just a reference board. > > Edison is one of the Intel's IoT boards, but the only board from Intel > MID family [3]. > > > > Much more important INTEL U-Boot businesses are ATOM E3900/APL-I > > > family and > > > CORE-5 BDW-DE (possible also BDW-DE NS), > > > > > > What about these? > > I can't answer on this. Work on Edison stuff may be considered as my > hobby project (I have never been a part of an official team which had > done Edison). > > [1]: https://
