4.18. Marvell Embedded Business Unit (mvebu)

4.18.1. Move of the Register Window

When an mvebu SoC comes up the internal registers are mapped at 0xd0000000 in the address space. To make it possible to have more than 3.25 GiB of continuous RAM in Linux this window is moved to 0xf1000000. Unfortunately the register to configure the location of the registers is located in this window, so there is no way to determine the location afterwards.

4.18.2. RAM initialisation

Traditionally the RAM initialisation happens with a binary blob that have to be extracted from the vendor U-Boot:

scripts/kwbimage -x -i /dev/mtdblock0 -o .

This creates among others a file “binary.0” that has to be put into the board directory. For license reasons this is usually not included in the barebox repository.

Note that in the meantime U-Boot has open source code to do the RAM initialisation that could be taken.

4.18.3. Booting second stage

Since v2017.04.0 barebox can boot a barebox image even if the register window is moved. This is implemented by writing the actual window position into the image where it is then picked up by the second stage bootloader.

4.18.4. Booting from UART

The mvebu SoCs support booting from UART. For this there is a tool available in barebox called kwboot. Quite some mvebu boards are reset once more when they already started to read the first block of the image to boot which obviously results in a failure to boot this image. If you want to boot such a board, use the parameter -n 15 for kwboot to delay uploading the image and try to hit the right (i.e. second) window harder. (The number might have to be adapted per board. The semantic is that the magic string is sent until the 15th NAK is seen and only then the image is sent.) A typical commandline is:

kwboot -b barebox.img -n 15 -B 115200 -t /dev/ttyUSB

4.18.5. mvebu boards

Not all supported boards have a description here.