[Automated-testing] minnowboard boot & control

[Krau, Michael P]

Hello Bill, et al;

To answer the one additional question in your message:

> UiApp - The device manager of the platform (think setup)
>
Does this app interact with the user via serial port or keyboard/video?
Short answer:
To my knowledge; this application is written to use the console drivers in UEFI , and therefore will be available in both serial and Video/keyboard configurations.  

Technical explanation:
The UEFI console (output and input) is actually an abstraction at the firmware level within UEFI to the devices attached as the console devices.  So basically, any shell application that utilizes the system console for I/O will interact with the user via both serial and keyboard /video.   (The console driver support (APIs) are limited to those features which are compatible to a serial console as the lowest common denominator for operation).

In the case of the serial port, the 'terminal' attached to the device should be Vt101 or an emulation thereof (a standard serial console emulation - most terminal programs have this capability - for many it is the only default), as serial terminal control functions for a serial console will expect this behavior to display data correctly (cursor movement, overwrite, "text graphics").

Also there is one exception note: In the case of an application written to operate directly with the graphics driver and not through the console drivers (i.e. applications doing true graphic output - usually things that cannot be emulated via "text graphics"), the serial console will not (cannot) display the output for obvious reasons.  In that case, the application will start, and all "console data" will still be visible on the serial port, but the graphics output will (of course) not be displayed on the serial terminal.

Thank you,


Michael Krau
 
-----Original Message-----
From: William Mills [mailto:wmills at ti.com] 
Sent: Monday, February 10, 2014 8:47 AM
To: Krau, Michael P; Garman, Scott A; automated-testing at yoctoproject.org
Cc: danders at circuitco.com
Subject: Re: minnowboard boot & control

All,

I just realized that Michael's answers did not go to the list.
As I suspect many people on the list may want the answers I have fwd.

With the mix of top and inline posting, the thread has become a bit messy.  I will post a summary at the top here to my initial theory.

 >  > At a minimum I think we can:
 >  > * Interrupt boot via serial control and change boot order

I tested and it seems the UEFI firmware always gives 4 seconds for a user to interrupt via the serial port before it tries the remembered or default boot order.  This should be all we need.

 >  > * Assume no one trashes SPI in the general case

The SPI flash in use actually has several methods of locking the flash (w/o hw change) but we will assume none of these are in use.

 >  > * Possibly rig & automate SPI flasher tool to recover board for >  >  > test beds that require extra robustness

I have ordered parts to try this out.  (Including a 2nd minnowboard.)

I was hands on with my first minnowboard over the weekend.
I updated to 1.00 of UEFI firmware.
I saw IPv4 & IPv6 in boot options somewhere (bcfg command?) I have not tested network boot yet.

More inline:

On 02/04/2014 07:20 PM, Krau, Michael P wrote:
> Hello Bill,
>
> Rather than try to put my answers in line, I will try to respond here 
> and answer your questions.  Though first off I will state that Scott's 
> responses were correct, so while I may repeat some of them, the ones I 
> miss are correct.
>
> First off, ALL answers are related to the 1.00 version of the Firmware 
> for the MinnowBoard.  Older versions of the firmware are different, 
> and are no longer under active support, the 1.00 was that much 
> improvement that it is just best to go forward with it.
>
> The SP1 part is not protected, the MinnowBoard is a development 
> vehicle, so the hardware is open.  There is even an SPI header on the 
> board to enable direct programing of the flash via an external 
> programmer (like a dedi-prog).  The flash has no 'bootblock' and 
> recovery is via external programming rather than internal software infrastructures.
>
> On the MinnowBoard, the SPI flash contains the platform initialization 
> firmware, so the first instructions fetched will always be from the 
> SPI part.
>
> The flow is:
>
> *Initialize the hardware
>
> *Establish the UEFI pre-boot environment
>

It appears to pause here for 4 seconds to allow user to input ESC via the serial port.  If the user does that it appears to go directly to the Shell.

> *Boot to selected device (if a device is selected)
>
> *Fall back to UEFI shell failing boot order (or boot to shell if 
> selected up front).
>
> The firmware is full UEFI and I believe Full UEFI shell support
>
> The system will boot to the last selected boot device, if it is 
> available for boot, or fall back to boot order ending with the shell, 
> failing that boot option.
>

Again, this appears to be the case if the user does not input ESC in the first 4 seconds from the serial port.

> By 'exit' from shell, you can see the boot options and select the boot 
> device.  Boot order is not controlled by any buttons, but by user 
> selection (first attempted boot), then list order.  The menu is:
>
> Shell - The UEFI shell
>
> UiApp - The device manager of the platform (think setup)
>

Does this app interact with the user via serial port or keyboard/video?

> EFI USB Device - the USB drive or SD drive on the platform (there may 
> be multiple of these, for the SD and add-on thumb drives)
>
> SATA (if a device is attached and identified)
>
> Eth0-IPv4 - Boot from network under IPv4
>
> Eth0-IPv6 - Boot from network under IPv6
>
> Yes, boot from network does work, from the onboard Ethernet port (you 
> will need a PXE server on the other end to provide the boot image to 
> the system though J).
>

Yes, I saw it in the boot options but have not tried to make it work yet.

> Thank you,
>
> Michael Krau
>
> -----Original Message-----
> From: Scott Garman [mailto:scott.a.garman at intel.com]
> Sent: Tuesday, February 04, 2014 3:06 PM
> To: William Mills; danders at circuitco.com; Krau, Michael P
> Subject: Re: minnowboard boot & control
>
> Hi Bill.
>
> Michael, can you clarify answers to the questions I'm not certain of below?
>
> Thanks,
>
> Scott
>
> On 02/04/2014 01:45 PM, William Mills wrote:
>
>  > Dave/Scott/All,
>
>  >
>
>  > I am trying to understand the Minnowboard boot flow and how it can 
> be
>
>  > controlled from a test bed.
>
>  >
>
>  > On BeagleBone Black:
>
>  > The Si Boot ROM can boot from TFTP.
>
>  > The Si Boot ROM can boot from eMMC or SD.
>
>  > With relay controlled pull-ups/downs I can control the boot device.
>
>  >
>
>  > With this control I can recover a device regardless of what a 
> previous
>
>  > test has done to eMMC or SD Card.
>
>  > (My work is documented at:
>
>  > http://processors.wiki.ti.com/index.php/BeagleBone_in_a_Board_Farm
>
>  > )
>
>  >
>
>  > My assumptions & questions about Minnow and it's UEFI:
>
>  > A1) always boots from SPI
>
> By this I'm sure you mean it will load the firmware from SPI before 
> booting anything, which is true.
>
>  > Q1) Does SPI have a write protect jumper or other means to protect 
> SPI
>
>  > contents via external control (e.g. relay)
>
> Not sure, Michael?
>
>  > A2) SPI contains UEFI
>
> Yes.
>
>  > Q2) Does SPI contain all of UEFI?  Does it have the Shell?
>
> Yes and yes.
>
>  >      Are there important components that always come from
>
>  >      the UEFI boot partition?
>
> Now I'll assume you're talking about a UEFI boot partition on media 
> (e.g, a microSD card). Yes, you need a UEFI-compatible bootloader 
> stored within a standardized directory format (/EFI/<vendor>).
>

My basic question here was, are there any firmware drivers or updates in the UEFI partition that need to be present to get the shell up & running.

The answer is no, SPI has everything you need.

Scott's answer is true also and relates to the requirements to boot an OS from media.


>  > Q3) Does UEFI look at any pins or buttons to effect boot order
>
> I don't believe so, Michael?
>
>  > Q4) Does UEFI support user configuration of boot order?
>
>  >      is that preference stored in SPI?
>
> Yes and yes.
>
>  > Q5) Does UEFI support boot from network?
>
> Yes, and to do this, I you'll need v1.00 of the MinnowBoard firmware, 
> which was released in December. I believe we support PXE boot with 
> that, although I haven't personally tested it. Michael, can you 
> confirm what options there are for networking booting?
>
> Are you running fw v1.00? That could explain your troubles.
>
>  > At a minimum I think we can:
>
>  > * Interrupt boot via serial control and change boot order
>
>  > * Assume no one trashes SPI in the general case
>
>  > * Possibly rig & automate SPI flasher tool to recover board for 
> test
>
>  > beds that require extra robustness
>
>  >
>
>  > So far I have read:
>
>  > http://elinux.org/Minnowboard:SPI_Boot_flash
>
>  > http://www.elinux.org/Minnowboard:Booting_Angstrom
>
>  > http://elinux.org/Minnowboard:Debian_Bare_Minimum_Bootstrapping
>
>  > http://www.minnowboard.org/technical-features/
>
>  > Minnow Board UEFI 1.0 release
>
>  >      Release Notes  **
>
>  >      doc/dediprog ...
>
>  >      doc/serial console ...
>
>  >      doc/flash utility
>
>  >
>
>  > ** After reading the release notes I still do not understand:
>
>  > - if network boot is or is not working.  It is in the fixed and 
> known
>
>  > issue lists.  It is not in the "fixed" boot order anywhere.
>
>  > - It appears that once you boot from SD or USB, there is no option 
> to
>
>  > interrupt to get a shell if that SD or USB image no longer works.
>
>  > Is that correct?
>
> That might be true, Michael?

This does not appear to be an issue.  It always waits 4 seconds for the user to interrupt even after a successful boot.

What the successful boot does appear to do is put that option first in the boot order for next time.  So a successful boot from SATA will cause SATA to be tried first after the 4 seconds pause.

>
>  > I do have a Minnowboard at home but I hate to admit it is still in 
> the
>
>  > box.  I did look at it and I think I booted it once but was being
>
>  > "disciplined" and did not study at that time.  I have yet to pick 
> it
>
>  > up again.  I'll rectify that soon.
>
> Depending on how old it is, I'm guessing you need to flash to the 
> latest
>
> firmware:
>
> http://uefidk.intel.com/content/minnowboard-uefi-firmware
>
> Scott
>
> --
>
> Scott Garman
>
> Embedded Linux Engineer - Yocto Project
>
> Intel Open Source Technology Center
>