Re: [U-Boot] Broadwell-DE bare metal
> To start porting I was planning to copy all the files of the board minnowmax and rename it with the name of our product. > I saw that minnowmax use FSP 1.0 exactly like Broadwell-DE. I hope that helps. You might want to join Coreboot mailing list. I am 1000% sure this will help you far beyond your expectations. Zoran On Tue, Oct 10, 2017 at 2:29 PM, vnktux wrote: > Hi Simon, > > Thanks for the info. I already have all the necessary blobs from the > current working implementation with Coreboot + U-Boot: FPS, ME, Microcode, > Flash Descriptor, VGA Rom. > > To start porting I was planning to copy all the files of the board > minnowmax and rename it with the name of our product. I saw that minnowmax > use FSP 1.0 exactly like Broadwell-DE. I hope that helps. > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > > Original Message > > Subject: Re: [U-Boot] Broadwell-DE bare metal > > Local Time: October 9, 2017 4:43 PM > > UTC Time: October 9, 2017 2:43 PM > > From: s...@chromium.org > > To: vnktux > > u-boot@lists.denx.de > > > > Hi, > > > > On 3 October 2017 at 08:58, vnktux wrote: > >> Hi all, > >> > >> For my graduation project my company asked to use U-Boot as bare metal > boot-loader on one of their product. The product in an embedded board with > a Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist of > Coreboot + U-Boot, but of course they want to get rid of Coreboot. I have > almost no experience with U-Boot (Just with ARM processor a little bit) and > so far I don"t even know if it"s possible or not to achieve the final goal. > What I have understood is that I need the following binary blobs to work: > fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is it true? Can > somebody point me in the right direction because I am a little bit lost? > Plus I don"t see many x86 boards implemented in the source code of U-Boot. > > > > The original U-Boot payload support was done with Broadwell-DE (I"m > > not sure which one though). It allows U-Boot to boot from EFI. > > > > For what you want, yes you will need to obtain various binary blobs. > > Hopefully you can get the FSP from Intel, and with that the work > > required in U-Boot is probably not too large. Although I"m sure that > > the FSP API will have changed a little. > > > > Regards, > > Simon > > > >> > >> Best regards, > >> Vincenzo > >> > >> Sent with [ProtonMail](https://protonmail.com) Secure Email. > >> ___ > >> U-Boot mailing list > >> U-Boot@lists.denx.de > >> https://lists.denx.de/listinfo/u-boot > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Broadwell-DE bare metal
> What project are you doing currently for the investigation? I did some E3900/APL-I investigation, back a year ago. Built Coreboot with FSP 2.0, and used as payload SeaBIOS. Did not like the methodology, especially if it comes to YOCTO via U-boot, as payload. Does not sound correctly. Now, I am doing some serious projects with ARM, U-Boot and YOCTO, but x86 stays still a mystery with the SEC + lower part od PEI (in other words FSP) for Embedded/IoT. Stays a mystery for years. For years I am trying to make some viable/meaningful architecture while I worked with x86. Nowadays, a i am in the same shoes as Andy, doing this investigation mostly for myself. But this stays to be main obstacle with U-Boot. With IoTG community, I should say. Well... And I am really now having you on my radar, since the job you'll do is not an easy one. And... Looking forward to read/experience more about your x86 U-Boot bare metal porting. Thank you for an effort, Zoran On Tue, Oct 10, 2017 at 7:08 AM, Bin Meng wrote: > Hi Zoran, > > On Tue, Oct 10, 2017 at 11:53 AM, Zoran Stojsavljevic > wrote: > > Hello Bin, > > > > You understood me, seems, perfectly. And this is what I am talking about > > here. > > > > The whole story told by Andy (Shevchenko) as RE: to my other thread does > not > > stand, just because of the booting times. > > > > But I need Andy's story (further) to investigate, and have currently no > any > > spare/free time. But I will later. > > > > And, BTW, you addressed me (wrongly). You should address Simon. To be > > politically correct. ;-) > > > > Please avoid top-posting.. > > What project are you doing currently for the investigation? > > Regards, > Bin > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Broadwell-DE bare metal
Hello Bin, You understood me, seems, perfectly. And this is what I am talking about here. The whole story told by Andy (Shevchenko) as RE: to my other thread does not stand, just because of the booting times. But I need Andy's story (further) to investigate, and have currently no any spare/free time. But I will later. And, BTW, you addressed me (wrongly). You should address Simon. To be politically correct. ;-) Thank you, Zoran On Tue, Oct 10, 2017 at 5:40 AM, Bin Meng wrote: > Hi Zoran, > > On Tue, Oct 10, 2017 at 11:34 AM, Zoran Stojsavljevic > wrote: > >> Yes but at the time there was no FSP. I suspect now it would not be > > needed. > > > > What about booting times? How long it'll take to boot EFI -> U-Boot -> OS > > loader -> init process on x86? > > > > My best guess at least/minimum 10s. Did anybody measure the booting time? > > > > I thought we were discussing U-Boot running as bare metal on the x86 > processor. Booting U-Boot from a UEFI BIOS is nice, but that's not the > main usage for U-Boot x86. > > Regards, > Bin > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Broadwell-DE bare metal
> Yes but at the time there was no FSP. I suspect now it would not be needed. What about booting times? How long it'll take to boot EFI -> U-Boot -> OS loader -> init process on x86? My best guess at least/minimum 10s. Did anybody measure the booting time? Thank you, Zoran On Tue, Oct 10, 2017 at 1:29 AM, Simon Glass wrote: > Hi, > > On 9 October 2017 at 10:32, Zoran Stojsavljevic > wrote: > > > > > It allows U-Boot to boot from EFI. > > > > This is a true art of overkill... Really. > > > > Full EFI (around 1 to 2 million lines of code: SEC, PEI, DXE phases, > with ME HECI involved, altogether) -> U-Boot -> YOCTO. Wow. ;-) > > > Yes but at the time there was no FSP. I suspect now it would not be needed. > > (BTW as this is a mailing list, please avoid top-posting) > > Regards, > Simon > > > > > > > Zoran > > > > On Mon, Oct 9, 2017 at 4:43 PM, Simon Glass wrote: > >> > >> Hi, > >> > >> On 3 October 2017 at 08:58, vnktux wrote: > >> > Hi all, > >> > > >> > For my graduation project my company asked to use U-Boot as bare > metal boot-loader on one of their product. The product in an embedded board > with a Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist > of Coreboot + U-Boot, but of course they want to get rid of Coreboot. I > have almost no experience with U-Boot (Just with ARM processor a little > bit) and so far I don't even know if it's possible or not to achieve the > final goal. What I have understood is that I need the following binary > blobs to work: fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is > it true? Can somebody point me in the right direction because I am a little > bit lost? Plus I don't see many x86 boards implemented in the source code > of U-Boot. > >> > >> The original U-Boot payload support was done with Broadwell-DE (I'm > >> not sure which one though). It allows U-Boot to boot from EFI. > >> > >> For what you want, yes you will need to obtain various binary blobs. > >> Hopefully you can get the FSP from Intel, and with that the work > >> required in U-Boot is probably not too large. Although I'm sure that > >> the FSP API will have changed a little. > >> > >> Regards, > >> Simon > >> > >> > > >> > Best regards, > >> > Vincenzo > >> > > >> > Sent with [ProtonMail](https://protonmail.com) Secure Email. > >> > ___ > >> > U-Boot mailing list > >> > U-Boot@lists.denx.de > >> > https://lists.denx.de/listinfo/u-boot > >> ___ > >> U-Boot mailing list > >> U-Boot@lists.denx.de > >> https://lists.denx.de/listinfo/u-boot > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Broadwell-DE bare metal
> It allows U-Boot to boot from EFI. This is a true art of overkill... Really. Full EFI (around 1 to 2 million lines of code: SEC, PEI, DXE phases, with ME HECI involved, altogether) -> U-Boot -> YOCTO. Wow. ;-) Zoran On Mon, Oct 9, 2017 at 4:43 PM, Simon Glass wrote: > Hi, > > On 3 October 2017 at 08:58, vnktux wrote: > > Hi all, > > > > For my graduation project my company asked to use U-Boot as bare metal > boot-loader on one of their product. The product in an embedded board with > a Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist of > Coreboot + U-Boot, but of course they want to get rid of Coreboot. I have > almost no experience with U-Boot (Just with ARM processor a little bit) and > so far I don't even know if it's possible or not to achieve the final goal. > What I have understood is that I need the following binary blobs to work: > fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is it true? Can > somebody point me in the right direction because I am a little bit lost? > Plus I don't see many x86 boards implemented in the source code of U-Boot. > > The original U-Boot payload support was done with Broadwell-DE (I'm > not sure which one though). It allows U-Boot to boot from EFI. > > For what you want, yes you will need to obtain various binary blobs. > Hopefully you can get the FSP from Intel, and with that the work > required in U-Boot is probably not too large. Although I'm sure that > the FSP API will have changed a little. > > Regards, > Simon > > > > > Best regards, > > Vincenzo > > > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ 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://
Re: [U-Boot] Please pull u-boot-x86
Hello Bing, Edison?! Edison is dead (end), as I know it... The project is cancelled. Correct me if I am wrong! 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? Thank you, Zoran Stojsavljevic ___ On Sat, Oct 7, 2017 at 9:16 AM, Bin Meng wrote: > Hi Tom, > > The following changes since commit 3ea0520512089cffbe02b7d6eb645c > dfddb09c5c: > > disk: part_dos: Use the original allocation scheme for the SPL case > (2017-10-05 10:45:33 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-x86.git > > for you to fetch changes up to 256df1e1c6664e94926affe9318faa8258c18582: > > x86: edison: Bring minimal ACPI support to the board (2017-10-07 > 15:07:59 +0800) > > > Andy Shevchenko (2): > x86: tangier: Enable ACPI support for Intel Tangier > x86: edison: Bring minimal ACPI support to the board > > Stefan Roese (3): > x86: theadorable-x86-common: Add further pci hotplug cmdline > parameters > x86: theadorable-x86-common: Move "-generic" into kernel-ver variable > x86: theadorable-x86-xxx_defconfig: Enable setexpr command > > arch/x86/cpu/tangier/Makefile | 1 + > arch/x86/cpu/tangier/acpi.c | 87 > +++ > arch/x86/include/asm/arch-tangier/acpi/global_nvs.asl | 16 ++ > arch/x86/include/asm/arch-tangier/acpi/platform.asl | 31 > +++ > arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 298 > > + > arch/x86/include/asm/arch-tangier/global_nvs.h| 22 > board/intel/edison/.gitignore | 3 ++ > board/intel/edison/Kconfig| 6 +++ > board/intel/edison/Makefile | 1 + > board/intel/edison/dsdt.asl | 13 + > configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig | 1 - > configs/theadorable-x86-conga-qa3-e3845_defconfig | 1 - > configs/theadorable-x86-dfi-bt700_defconfig | 1 - > include/configs/edison.h | 3 ++ > include/configs/theadorable-x86-common.h | 11 ++-- > 15 files changed, 487 insertions(+), 8 deletions(-) > create mode 100644 arch/x86/cpu/tangier/acpi.c > create mode 100644 arch/x86/include/asm/arch-tangier/acpi/global_nvs.asl > create mode 100644 arch/x86/include/asm/arch-tangier/acpi/platform.asl > create mode 100644 arch/x86/include/asm/arch- > tangier/acpi/southcluster.asl > create mode 100644 arch/x86/include/asm/arch-tangier/global_nvs.h > create mode 100644 board/intel/edison/.gitignore > create mode 100644 board/intel/edison/dsdt.asl > > Regards, > Bin > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] INTEL E3900 Apollo Lake I (APL-I) with U-Boot?
> Normally U-Boot boots from SPI NOR, and Linux can be loaded directly > from U-Boot via the 'zboot' command. I am much more interested (since the last stage I know) what would be the initial sequence of events: E3900/APL-I -> IFWI -> MBR -> U-Boot, or ...??? Thank you, Zoran On Thu, Oct 5, 2017 at 1:34 PM, Bin Meng wrote: > Hi Zoran, > > On Thu, Oct 5, 2017 at 6:22 PM, Zoran Stojsavljevic > wrote: > > Hello Bin, > > > >> So far Apollo Lake is not supported in U-Boot. However it is on my todo > >> list. > > > > All Good. Please, take your time. If you do not mind, I would like to > know > > ASAP, do I have correct prediction/anticipation/vision how this whole > thing > > should work? > > > > The one I originally described in my original/intro email to this email > > thread? Namely: E3900/APL-I -> IFWI -> MBR -> U-Boot -> eLinux/YOCTO ?! > > > > I will need investigate this before commenting anything since this is > not a normal boot sequence supported in U-Boot. > > > With the following/forwarding explanation (please, in original email)? > > > > It is very important for me to know how the future U-Boot architecture > will > > look like for E3900/APL-I! > > > > I would like to thank you in advance, > > Normally U-Boot boots from SPI NOR, and Linux can be loaded directly > from U-Boot via the 'zboot' command. > > Regards, > Bin > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Broadwell-DE bare metal
> So far Broadwell-DE is not supported in U-Boot. However it is on my todo list. Excellent thread! Just what I needed, and was thinking to enter! ;-) What will be the architecture of this porting effort? The same question as I have asked an hour ago for ATOM E3900/APL-I. Thank you in advance, Zoran Stojsavljevic ___ On Thu, Oct 5, 2017 at 1:21 PM, Bin Meng wrote: > Hi, > > On Thu, Oct 5, 2017 at 5:43 PM, vnktux wrote: > > Hi Bin, > > > > Thanks a lot for the reply. Is there something I can do to help you? I > mean > > that's my graduation project and I will have to work on it either I > succed > > or not, and here I have available hardware aswell. > > > > If you can't wait, you can start trying to port U-Boot on your > Broadwell-DE board, and I can help review. Thanks! > > Regards, > Bin > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] INTEL E3900 Apollo Lake I (APL-I) with U-Boot?
Hello Bin, > So far Apollo Lake is not supported in U-Boot. However it is on my todo list. All Good. Please, take your time. If you do not mind, I would like to know ASAP, do I have correct prediction/anticipation/vision how this whole thing should work? The one I originally described in my original/intro email to this email thread? Namely: E3900/APL-I -> IFWI -> MBR -> U-Boot -> eLinux/YOCTO ?! With the following/forwarding explanation (please, in original email)? It is very important for me to know how the future U-Boot architecture will look like for E3900/APL-I! I would like to thank you in advance, Zoran Stojsavljevic ___ On Thu, Oct 5, 2017 at 11:27 AM, Bin Meng wrote: > Hi Zoran, > > On Wed, Oct 4, 2017 at 1:52 PM, Zoran Stojsavljevic > wrote: > > Hello to the U-Boot Community, > > > > I am curious about the following HW/FW configuration with regards to the > > U-Boot? > > > > Did anybody managed to run the following: INTEL Atom E3900 APL-I with > > U-Boot? > > > > E3900 -> 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 APL-I are provided by Intel and are > > specific for different flavors of the MID silicon.* > > *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.* > > > > So far Apollo Lake is not supported in U-Boot. However it is on my todo > list. > > Regards, > Bin > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Fwd: INTEL E3900 Apollo Lake I (APL-I) with U-Boot?
Repeating, since I am not sure that this email reached the community! Zoran -- Forwarded message -- From: Zoran Stojsavljevic Date: Wed, Oct 4, 2017 at 7:52 AM Subject: INTEL E3900 Apollo Lake I (APL-I) with U-Boot? To: u-boot@lists.denx.de Hello to the U-Boot Community, I am curious about the following HW/FW configuration with regards to the U-Boot? Did anybody managed to run the following: INTEL Atom E3900 APL-I with U-Boot? E3900 -> 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 APL-I are provided by Intel and are specific for different flavors of the MID silicon.* *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.* Thank you in advance, Zoran ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] u-boot hangs after reboot
Hello Mike, It could be that newer versions of U-Boot include ECC testing/checking for Olimex-olinuxino-micro-emmc. and this might influence your tests/reboots. Please, check for ECC and try not to use/to exclude ECC checking algorithm... Just to simplify use case?! Hint out of desperation. ;-) Zoran On Wed, Oct 4, 2017 at 8:53 AM, Mike Mildner wrote: > Hi all, > > i'm new to this list... > > I have a strange problem with my Olimex-olinuxino-micro-emmc (Allwinner > A20): > > I've tested u-boot-v2016.07/09/11 2017.03/05/09 - all this version hangs > after reboot. > Only reseting or repowering helps. > On Display i get this: > > U-Boot SPL 2016.09 (Oct 04 2017 - 08:12:07) > DR > > The version u-boot-v2016.03 reboots fine and always. > > Any ideas or hints? > > Thx Mike > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] INTEL E3900 Apollo Lake I (APL-I) with U-Boot?
Hello to the U-Boot Community, I am curious about the following HW/FW configuration with regards to the U-Boot? Did anybody managed to run the following: INTEL Atom E3900 APL-I with U-Boot? E3900 -> 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 APL-I are provided by Intel and are specific for different flavors of the MID silicon.* *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.* Thank you in advance, Zoran ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
