Booting a Non-Linux OS

Booting a Non-Linux OS

I want to boot a non-linux OS on the Xeon Phi. Is there any documentation on that? 

From the MPSS User Guide:

"The second part of the boot argument indicates to boot a Linux* image. It may also be set to elf to indicate booting a standard ELF format file. Documenting non-Linux* boot is beyond the scope of this document."

Is it possible to boot an elf-x86_64 (no unsupported vector instructions used) or does the elf need to be an elf-k1om? What is the entry point of the elf and can it be used to bootstrap the card OS?

There are two further questions that arise:
- How can the host be informed that the system is ready?
- How can the coprocessor OS write to the serial console (which arrives at /dev/ttyMICx on the host) ?

It is basically which SBOX registers do I have to set to which values? 

 

Thanks for any replies on the questions.

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I don't know of any specific Intel information but there have been other threads on this topic. See http://software.intel.com/en-us/forums/topic/489529.

Regards
--
Taylor
 

Quote:

Taylor Kidd (Intel) wrote:

I don't know of any specific Intel information but there have been other threads on this topic. See http://software.intel.com/en-us/forums/topic/489529.

OK, I managed to boot an elf-64. How can I get serial output from the card to the host when booting a elf-64?

The documentation says:

Intel® Xeon Phi™ coprocessor hardware supports a serial console using the serial port device on the SBOX I2C bus.

Best Reply

Serial output requires a "POST card," a small circuit board with two 7-segment displays (for the two-character boot progress code) and the UART in question. The board is connected to the Xeon Phi with an I2C cable that resembles one of those CD-audio cables used in computer optical drives about a decade ago. So, you'd need a POST card and a Xeon Phi with the appropriate connector soldered down.... On the engineering team, the former have always been in short supply and the latter were unavailable, so we'd hand-solder the missing connectors.

In any case, because the UART is on the far side of an I2C bus, you'd need a rather thick driver stack to access it, more than would be desirable for early boot messages, and indeed MPSS's Linux kernel is not capable of using that UART for early_printk. Honestly, I suggest you print to an in-memory ring buffer (see the host mic.ko's code for reading the Linux dmesg buffer across PCIe) or emulate a serial port with a pair of such rings (see the card's michvc.ko code and its companion bits in the host's mic.ko).

Thanks Evan for clearing up the misleading information in the documentation.

 

Quote:

Reto A. wrote:

- How can the host be informed that the system is ready?

If the system has been successfully booted, post code will be FF (ASCII encoded in SBOX address 0x242c). There's a check the host driver makes against SCRATCH2 register bit 0, but that value seems to be controlled by the boot loader.

If there's some better way, I'm interested myself.

Quote:

rhn wrote:

There's a check the host driver makes against SCRATCH2 register bit 0, but that value seems to be controlled by the boot loader.

if you boot the ELF way writing a 0x1 to SCRATCH2 will tell the host that its booted successfully. When booting the Linux way, there needs to be a SCIF based handshake. 

Leave a Comment

Please sign in to add a comment. Not a member? Join today