2

Does the Zephyr OS(version 1.9) needs any BIOS or UBOOT for booting?

Since I am new to this please provide booting process of zephyr RTOS

artless noise
  • 21,212
  • 6
  • 68
  • 105
Antony
  • 51
  • 2

2 Answers2

4

Zephyr RTOS is designed first of all to be "baremetal" OS. It boots directly on the hardware and initialized it completely itself.

But: first of all, you need to get a Zephyr application onto your board/MCU. This can be done using an in-circuit programmer (JTAG, SWD, etc.), but for end user, it may be more convenient to use an MCU-specific bootloader and upload an app via a UART/USB connection. Note that these MCU specific bootloaders aren't "BIOS" or "UBOOT"

Going further, when new ports appear to architectures which normally use e.g. the U-Boot bootloader, I guess Zephyr port to that architecture will take advantage of that, to make application deployment easier.

Summing up: Zephyr RTOS doesn't need a special bootloader. But it can take advantage of it to make application deployment easier for a user.

pfalcon
  • 6,724
  • 4
  • 35
  • 43
  • Thanks for detailed explanation, but I have a few doubts. Does it mean when we flash the application to the board, we are flashing OS along with it? Can we run multiple applications on a board using this OS? – dfordevy Feb 20 '20 at 05:17
  • 1
    "we are flashing OS along with it" - Yes, with Zephyr, OS and application is a single, statically linked binary image. "Can we run multiple applications on a board using this OS?" - a) by building each application separately and reflashing each as needed; b) by building "mega-application" which includes functionality of several apps; c) by using additional layer, e.g. scripting language interpreter like MicroPython or JerryScript which support dynamic loading; d) implement something like dynamic loading in the OS itself (may happen sooner or later, but not yet). – pfalcon Feb 20 '20 at 10:04
  • Zephyr app and the zephyr kernel are linked together as a single binary. Dynamic module is being implemented. – smwikipedia Jan 17 '22 at 05:46
0

An additional power of u-boot is to configure peripherals to a known state. One is SDRAM. SDRAM configuration is complex and can take quite a bit of code. u-boot is supporting several stage boot loaders to accomplish this. SDRAM is typically found on larger platforms.

Zephyr has the app linked to the kernel. This makes it next to impossible to make a 'distribution'. Ie, a Ubuntu-Zephyr, Zephyr-deb, etc. A 2nd important feature of u-boot is to support kernel tags or device tree. This can allow several 'boards' to work with one code release of the kernel. You can see the Zephyr 'boards' directory is quite complex. For example, arm has approximately 360 boards in the directory.

So, the fact that Zephyr is made to be more resource constrained by the design choice to link an application with the kernel, it makes it difficult to make distributions and hence to create anything except a purpose built embedded application (which seems to be the use case for this OS). This makes 'u-boot' less of a win for these devices. It would only function as a 'boot debugger', but most of the target CPUs support JTAG debugging. Zephyr was not created in an era of 'in-circuit emulators'.

artless noise
  • 21,212
  • 6
  • 68
  • 105