Even though I find Myir’s Z-Turn Lite + its IO Cape combination of cards useful and well designed, there’s a small and annoying detail about them: The spacers that arrive with the boards don’t allow setting them up steadily on a flat surface, because the Z-Turn board is elevated over the IO Cape board. As a result, the former board’s far edge has no support, which makes the two boards wiggle. And a little careless movement is all it takes to have these boards disconnected from each other.

So I made a simple 3D design of a plastic leg (or spacer, if you like) for supporting the Z-Turn Lite board. See the small white thing holding the board to the left of the picture above? Or the one in the picture below? That’s the one.

If you’d like to print your own, just click here to download a zip file containing the Blender v2.76 model  file as well as a ready-to-print STL file. It’s hereby released to the public domain under Creative Common’s CC0 license.

The units of this model is millimeters. You’ll need this little part of info.

I printed mine at Hubs (they were 3D Hubs at the time). Because I bundled this with another, more bulky piece of work, the technique used was FDM at 200 μm, with standard ABS as material. If you’re into 3D printing, you surely just read “cheapest”. And indeed, printing four of these should cost no more than one USD. But then there’s the set-up cost and shipping, which will most likely be much more than the printing itself. So print a bunch of them, even though only two are needed. It’s going to be a few dollars anyhow.

Even though these spacers aren’t very pretty, and with zero mechanical sophistication, they do the job. At least those I got require just a little bit of force to get into the holes, and they stay there (thanks to the pin diameter of 3.2 mm, which matches the holes’ exactly). And because it’s such a dirt simple design, this model should be printable with any technique and rigid material.

Wrapping up, here’s a picture of three printed spacers + two of the spacers that arrived with the boards. Just for comparison.

This post shows how to access some GPIO functionalities from Xillinux running on a Z-Turn Lite board (with an Z-turn Lite IO Cape board attached), directly from the command line.

Watchdog

When the “WD” jumper at J26 on the board is placed, it’s possible to utilize the board’s watchdog chip, which resets the processor if its watchdog-clear pin isn’t toggled for 1.2 seconds. If that pin is in high-Z, the watchdog is inactive, and doesn’t reset the processor even if no toggling has taken place. This can be achieved either by removing the “WD” jumper, which floats the pin, or making the pin high-Z by setting the relevant GPIO to an input (Xillinux ensures the latter, so booting it with the “WD” jumper is safe).

When the pin is high-Z, a small sawtooth-like pulse, which is a few microseconds wide, is visible with an oscilloscope every 1.2 sec, and it’s the watchdog driving the pin to verify that the wire is in high-Z.

The watchdog’s clear pin is wired to the Zynq’s PS-only pin MIO0, which is configured as GPIO 0.

To take control of this pin from the command line:

# echo 0 > /sys/class/gpio/export
# echo out > /sys/class/gpio/gpio0/direction

These commands turn the GPIO into an output, and hence it’s not a high-Z anymore. The pin must start toggling every 1.2 seconds from this moment, or the processor is reset.

To prevent this reset, the following command can be used:

# while [ 1 ] ; do echo 1 > /sys/class/gpio/gpio0/value ; echo 0 > /sys/class/gpio/gpio0/value ; sleep 0.5 ; done

This works on MYiR’s OOB Linux as well (not just Xillinux).

Sensing the IO Cape board’s pushbutton

Not to be confused with the button on the Z-Turn Lite board itself, this is how to fetch the value of the button on the IO Cape Board:

# echo 88 > /sys/class/gpio/export
# cat /sys/class/gpio/gpio88/direction
in
# cat /sys/class/gpio/gpio88/value

This prints out 0 or 1, depending on the button’s state.

Controlling the IO Cape board’s J8 pins

Out of the box, Xillinux routes 34 GPIO I/Os to the IO Cape board’s J8 connector. This can be modified easily by editing the top-level module of Xillinux’ logic design, but this is beyond this post’s scope.

The 34 pins are wired to the connector’s pins 3 to 36. In Linux, to access pin N on the J8, request GPIO number N+51.

For example, in order to toggle pin J8/3, the GPIO to request is 3 + 51 = 54, so the following commands at shell prompt cause some fast toggling:

# echo 54 > /sys/class/gpio/export
# echo out > /sys/class/gpio/gpio54/direction
# while [ 1 ] ; do echo 1 > /sys/class/gpio/gpio54/value ; echo 0 > /sys/class/gpio/gpio54/value ; done

The GPIO pins can also be used as inputs, by following the standard Linux API for GPIO. Note however that pins J8/31 and J8/34 are pulled up with resistors on the IO Cape board.

Xilinx’ documentation says that XC7Z007S, among other “S” devices, is a single-core device, as opposed to, for example, its older brother XC7Z010, which is dual-core. So I compared several aspects of the PS part of a Z007S vs. Z010, and to my astonishment, I found that Z007S is exactly the same: Two CPUs are reported by the hardware itself, SMP is kicked off on both, and a simple performance test I made showed that Z007S runs two processes in parallel as fast as Z010.

So the question is: In what sense is XC7Z007S single-core? For now, I have no answer to that. I’ll update this post as soon as someone manages to explain this to me. In the meanwhile, I’ve tried to get this figured out in Xilinx’ forum.

The rest of this post outlines the various similarities between the Z007S vs. Z010 I tested. The PL bitfiles of different Zynq devices are incompatible, so there’s no chance I mistook which devices I worked with.

The tests below were made with Xillinux-2.0 (kernel v4.4) on two Z-turn Lite boards, one carrying Z007S, and one Z010.

Found 2 CPUs?

I started wondering when the kernel’s dmesg log indicated that it had found 2 CPUs on a Z007S:

[    0.132523] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.132586] Setting up static identity map for 0x82c0 - 0x82f4
[    0.310962] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.311065] Brought up 2 CPUs
[    0.311102] SMP: Total of 2 processors activated (2664.03 BogoMIPS).
[    0.311121] CPU: All CPU(s) started in SVC mode.

Also, /proc/cpuinfo consistently listed two CPUs. One could think that it’s because two CPUs are declared in the device tree, but removing one of them makes no difference.

On Z010, the exact same log and appears in this matter, and /proc/cpuinfo says the same.

CPU’s hardware register reporting two CPUs

According to the Zynq-7000 AP SoC Technical Reference Manual (UG585), the processor’s SCU_CONFIGURATION_REGISTER indicates the number of CPUs present in the Cortex-A9 MPCore processor in bits 1:0. Binary ’01′ means two Cortex-A9 processors, CPU0 and CPU1. Binary ’00′ means one Cortex-A9 processor, CPU0.

Using Xillinux-2.0′s poke kernel utility to read the processor’s SCU_CONFIGURATION_REGISTER register, I got exactly the same result on Z007S and Z010:

poke read addr=f8f00004: value=00000511

In other words, both devices report two processors.

I’m under the impression that the kernel uses this register to tell the number of CPUs by virtue of the scu_get_core_count() (defined in arch/arm/kernel/smp_scu.c) function, called by zynq_smp_init_cpus() in arch/arm/mach-zynq/platsmp.c.

The latter function sets the kernel’s “CPU possible” bits, so it’s how the Zynq-specific kernel setup code tells the kernel framework which CPUs indexes are good for use.

Also, the U-Boot code used by Xillinux for Z-Turn Lite prints out the processor count, based upon SCU_CONFIGURATION_REGISTER, as well as other info. For Z007S it gave:

U-Boot 2013.07 (Sep 17 2018 - 11:51:45)              

Detected device ID code 0x3 (XC7Z007S) with 2 CPU(s), PS_VERSION = 3
Strapped boot mode: 5 (SD Card)

and for Z010:

U-Boot 2013.07 (Sep 17 2018 - 11:51:45)              

Detected device ID code 0x2 (XC7Z010) with 2 CPU(s), PS_VERSION = 3
Strapped boot mode: 5 (SD Card)

A simple benchmark test

The proof is in the pudding. I wrote a simple program, which forks into two processes, each running a certain amount of plain CPU-intensive operations, and then quits. The output of this program is of no interest, but it’s printed out to avoid the compiler from optimizing away the crunching. Its listing is given at the end of this post for reference.

Using the “time” utility to measure the execution times, I ran the program on Z007S and Z010, and consistently got the same results, except for slight fluctuations:

# time ./work 400
Parent process done with LSR at e89c4641
Child process quitting with LSR at e89c4641
Parent process quitting

real	0m3.604s
user	0m7.030s
sys	0m0.010s

The 3.6 seconds given as “real” is the wall clock time. The 7 seconds of “user” time is the amount of consumed CPU. And as one would expect from a program that runs on two processes on a dual core machine, the consumed CPU time is approximately double the wall clock time. This is the result I expected from Z010, but not from Z007S.

Just to be sure I wasn’t being silly, I booted the kernel with “nosmp” in the kernel command line, which forced a single-CPU bringup. Indeed, the kernel reported finding one CPU in its logs, and /proc/cpuinfo reflected that as well.

And the pudding?

# time ./work 400
Parent process done with LSR at e89c4641
Child process quitting with LSR at e89c4641
Parent process quitting

real	0m6.998s
user	0m6.970s
sys	0m0.010s

Exactly as expected: With one processor, forking into two processes has no advantage. The CPU time is the wall clock time. I waited twice as long for it to finish.

At some point I suspected that the specific Linux version I used had a specific scheduler issue, which allowed a single-core CPU to perform as well as a dual-core. However the dual-core results were repeated on a Zybo board with three completely different kernels (except Xillinux-2.0) and yielded the same results (or slightly worse, with older kernels).

Conclusion

Given the results above, it’s not clear why Z007S is labeled as a single-core device. It’s not a matter of how it quacks or walks, but in the end, the device performs twice as fast when the work is split into two processes.

Or I missed something here. Kindly comment below if you found my mistake.

———————————–

Appendix: The benchmark program’s listing

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <time.h>
#include <signal.h>
#include <errno.h>
#include <string.h>
#include <sys/wait.h>

static unsigned int lsr_state;

int main(int argc, char *argv[]) {

  int count, i, j, bit;
  pid_t pid;

  if (argc != 2) {
    fprintf(stderr, "Usage: %s count\n", argv[0]);
    exit(1);
  }

  count = atoi(argv[1]);

  lsr_state = 1;

  pid = fork();

  if (pid < 0) {
    perror("Failed to fork");
    exit(1);
  }

  for (i=0; i<count; i++)
    for (j=0; j<(1<<20); j++) {
      bit = ((lsr_state >> 19) ^ (lsr_state >> 2)) & 0x01;

      lsr_state = (lsr_state << 1) | bit;

      if (lsr_state == 0) {
	fprintf(stderr, "Huh? The LSR state is zero!\n");
	exit(1);
      }
    }

  if (pid == 0) {
    fprintf(stderr, "Child process quitting with LSR at %x\n", lsr_state);
    return 0;
  }

  fprintf(stderr, "Parent process done with LSR at %x\n", lsr_state);

  pid = wait(&i);

  fprintf(stderr, "Parent process quitting\n");

  return 0;
}

saved as work.c, compiled with

# gcc -O3 -Wall work.c -o work

directly on the Zynq board itself (Xillinux comes with a native gcc compiler). But cross compilation should make no difference.

• The relevant sources must be compiled into the kernel. Modules are loaded too late. The choice of PHY frontend is made when the USB driver is initialized, and if the relevant driver isn’t handy, a generic PHY is picked instead…
• … which is most likely as good. In retrospect, there’s is very little reason to load the actual driver.
• In particular, my system works great without the dedicated USB PHY driver.

So it’s about adding a plain pr_info() into the kernel’s drivers/usb/phy/phy-ulpi-viewport.c, so it prints every ULPI register write command to the kernel log. Added code marked in red:

static int ulpi_viewport_write(struct usb_phy *otg, u32 val, u32 reg)
{
	int ret;
	void __iomem *view = otg->io_priv;

	pr_info("ulpi_viewport_write: reg 0x%04x = 0x%02x\n",
		reg, val);

	writel(ULPI_VIEW_WAKEUP | ULPI_VIEW_WRITE, view);
	ret = ulpi_viewport_wait(view, ULPI_VIEW_WAKEUP);
	if (ret)
		return ret;

	writel(ULPI_VIEW_RUN | ULPI_VIEW_WRITE | ULPI_VIEW_DATA_WRITE(val) |
						 ULPI_VIEW_ADDR(reg), view);

	return ulpi_viewport_wait(view, ULPI_VIEW_RUN);
}

And that’s it. One can also cover the ulpi_viewport_read() method in the same way, but it wasn’t important to me (I wanted to the powering on of Vbus).

The relevant part in my device tree read:

	usb_phy0: phy0 {
		compatible = "ulpi-phy";
		#phy-cells = <0>;
		reg = <0xe0002000 0x1000>;
		view-port = <0x0170>;
		drv-vbus;
	};

	usb0: usb@e0002000 {
		compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2";
		clocks = <&clkc 28>;
		interrupt-parent = <&ps7_scugic_0>;
		interrupts = <0 21 4>;
		reg = <0xe0002000 0x1000>;
		phy_type = "ulpi";
		dr_mode = "host";
		usb-phy = <&usb_phy0>;
	};

And this is what I got in the dmesg log:

[    1.396317] ulpi_phy_probe() invoked
[    1.399968] ulpi_phy_probe() returns successfully
[    1.405148] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.418505] ehci-pci: EHCI PCI platform driver
[    1.429765] ehci-platform: EHCI generic platform driver
[    1.441924] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.454951] ohci-pci: OHCI PCI platform driver
[    1.466237] ohci-platform: OHCI generic platform driver
[    1.478504] uhci_hcd: USB Universal Host Controller Interface driver
[    1.492047] usbcore: registered new interface driver usb-storage
[    1.505250] chipidea-usb2 e0002000.usb: ci_hdrc_usb2_probe invoked
[    1.518410] e0002000.usb supply vbus not found, using dummy regulator
[    1.532049] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, revision: 22, lpm: 0; cap: e0d0a100 op: e0d0a140
[    1.532062] ulpi_init() invoked
[    1.542033] ULPI transceiver vendor/product ID 0x0424/0x0007
[    1.554611] Found SMSC USB3320 ULPI transceiver.
[    1.566118] ulpi_viewport_write: reg 0x0016 = 0x55
[    1.577825] ulpi_viewport_write: reg 0x0016 = 0xaa
[    1.589383] ULPI integrity check: passed.
[    1.600057] ulpi_viewport_write: reg 0x000a = 0x06
[    1.611516] ulpi_viewport_write: reg 0x0007 = 0x00
[    1.622872] ulpi_viewport_write: reg 0x0004 = 0x41
[    1.634203] ci_hdrc ci_hdrc.0: It is OTG capable controller
[    1.634233] ci_hdrc ci_hdrc.0: EHCI Host Controller
[    1.645628] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[    1.672482] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[    1.684475] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.697770] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.711521] usb usb1: Product: EHCI Host Controller
[    1.722832] usb usb1: Manufacturer: Linux 4.4.30-xillinux-2.0 ehci_hcd
[    1.735797] usb usb1: SerialNumber: ci_hdrc.0
[    1.747236] hub 1-0:1.0: USB hub found
[    1.757421] hub 1-0:1.0: 1 port detected
[    1.767881] ulpi_viewport_write: reg 0x000a = 0x67

The log entries in green above are just some other similar debug outputs I made, and they pretty much explain themselves.

Did you note that the ULPI was detected by vendor ID / product ID? It’s for real. These were obtained by ULPI registers read (not shown above). I’m not all that convinced that this detection made any difference, except for printing out the name of the device.

As for the meaning of these ulpi_viewport_write dumps, most is pretty boring: The first two writes to address 0x16 do nothing. It’s a scratch pad register. Most likely used by the driver to test the ULPI interface.

The following three writes just assign the default values. So this does effectively nothing as well.

The last write to register 0x0a (OTG register) sets bits 6, 5 and 0, which are DrvVbusExternal, DrvVbus and IdPullup. The interesting part to me was DrvVbusExternal and DrvVbus, because setting any of these two (or both) causes the chip’s CPEN pin to go high, which turns on the power supply for Vbus. This is the point where the USB port starts behaving like a host and feeds power.

On an embedded ARM-based Lubuntu 16.04, I had LXDE’s logoff dialog window offering suspend as an option, and when that was chosen, the system got itself into some nasty state with network and keyboard off. The serial console was still active, and yet, I was better off without it.

It turned out that the kernel was misconfigured to announce that it supported suspend to RAM:

# cat /sys/power/state
freeze mem

So no wonder that option was presented to the user on GUI. The solution: Turn off the CONFIG_SUSPEND kernel compilation flag. Recompile, deploy, and that’s it:

# cat /sys/power/state
#

And the faulty options were gone.

The rest of this post contains things I jotted down as I wasted time trying to find out what the problem was.

Irrelevant notes

• There’s a systemd-inhibit utility for preventing suspends and sleeps while a certain program is running. Essentially, it issues an “Inhibit” command with what / who, why /mode info on DBus for”org.freedesktop.login1″.
• polkit’s manual (“man polkit” lacks some info) directs to a list of directories with rules.d files written in JavaScript (!!!). The action/ directories are policy files, in XML, which describe who might be allowed what operation, and what to write (in several languages) in the dialog box asking for authentication (typically a password).
• Obtaining the sources for the study below

  # apt-get source lxsession-logout
  # apt-get source systemd

A journey in the sources (more wasted time)

I tried to follow how lxsession-logout, which is LXDE’s program that displays the logout dialog box, decides which low-power modes to offer. And what actually happens when suspend is requested.

• lxsession-logout.c learns if the system can suspend (and hence the button shall be presented) by calling dbus_systemd_CanSuspend().
• which is implemented in lxsession-logout-dbus-interface.c, and calls systemd_query() with “CanSuspend” as its parameter
• which (implemented in the same file) in turn opens a session with “org.freedesktop.login1″ over DBus and issues a query
• Judging by the “BusName=org.freedesktop.login1″ directive in /lib/systemd/system/systemd-logind.service, systemd-logind.service, (running systemd-login) is answering this query.
• Looking in systemd’s login-dbus.c, “CanSuspend” calls the method method_can_suspend(), which in turn calls method_can_shutdown_or_sleep() with “org.freedesktop.login1.suspend” as the key argument, which calls bus_test_polkit() for an answer on that.
• Implemented in systemd/shared/bus-util.c, bus_test_polkit() makes a DBus query on “org.freedesktop.PolicyKit1″
• There are also references to upowerd in lxsession-logout.c, but since stopping this service changes nothing, I focused on logind.
• Judging by the “BusName=org.freedesktop.PolicyKit1″ directive in /lib/systemd/system/polkitd.service, polkitd.service (running /usr/lib/policykit-1/polkitd) answer this.
• Back to login-dbus.c, a “Suspend” request causes a call to method_suspend(), which calls method_do_shutdown_or_sleep(), which calls bus_manager_shutdown_or_sleep_now_or_later(), which calls execute_shutdown_or_sleep(). The “unitname” parameter traverses these calls with the value SPECIAL_SUSPEND_TARGET. There are several checks on the way that may cancel the request, but this is the chain to fulfilling it.
• execute_shutdown_or_sleep() issues a DBus request on “org.freedesktop.systemd1″ (I have a wild guess which process is on the other side).
• Apparently (without following the execution chain), systemd/src/sleep.c is responsible for putting the system in suspend mode and such. Among others, it writes to /sys/power/state. This is where it hit me that maybe the kernel’s configuration was the problem.

/dts-v1/;
#include "zynq-7000.dtsi"

and later on there’s, among others,

&sdhci0 {
	status = "okay";
};

&uart1 {
	status = "okay";
};

&usb0 {
	status = "okay";
	dr_mode = "host";
	usb-phy = <&usb_phy0>;
};

Let’s look on the last one, relating to the usb0 label. In zynq-7000.dtsi, there’s

		usb0: usb@e0002000 {
			compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2";
			status = "disabled";
			clocks = <&clkc 28>;
			interrupt-parent = <&intc>;
			interrupts = <0 21 4>;
			reg = <0xe0002000 0x1000>;
			phy_type = "ulpi";
		};

So the “okay” assignment in zynq-zed.dts overrides the one in zynq-7000.dtsi, “disabled”.

As explained on this page, if the “status” property is present, it must be “ok” or “okay”, or the device entry node is ignored (or should be). This allows the .dtsi file to include all possible hardware entries, and keep them “disabled”, and let the .dts file including it hand-pick those required, only by changing the “status”.

And indeed, in drivers/of/base.c it says

/**
 *  of_device_is_available - check if a device is available for use
 *
 *  @device: Node to check for availability
 *
 *  Returns true if the status property is absent or set to "okay" or "ok",
 *  false otherwise
 */
bool of_device_is_available(const struct device_node *device)
{
	unsigned long flags;
	bool res;

	raw_spin_lock_irqsave(&devtree_lock, flags);
	res = __of_device_is_available(device);
	raw_spin_unlock_irqrestore(&devtree_lock, flags);
	return res;

}
EXPORT_SYMBOL(of_device_is_available);

and

/**
 *  __of_device_is_available - check if a device is available for use
 *
 *  @device: Node to check for availability, with locks already held
 *
 *  Returns true if the status property is absent or set to "okay" or "ok",
 *  false otherwise
 */
static bool __of_device_is_available(const struct device_node *device)
{
	const char *status;
	int statlen;

	if (!device)
		return false;

	status = __of_get_property(device, "status", &statlen);
	if (status == NULL)
		return true;

	if (statlen > 0) {
		if (!strcmp(status, "okay") || !strcmp(status, "ok"))
			return true;
	}

	return false;
}

This feature was added to the kernel back in 2008 in commit 834d97d452208279edf11c57eca150360d2dd1d6, but it seems it took some time before it was actually adopted.

Note that when there’s no “status” entry, it’s treated as “okay”. This retains backward compatibility with DTS files that don’t care much about this feature.

First, I looked up which GPIO pin it is. The pin assignments can be found in the FPGA bundle, in xillydemo.ucf (or in xillydemo.sdc, if Vivado was used to build the project).

So I choose to connect to PMOD header JB, first pin, and the PMOD’s GND.

In the UCF file there’s a line saying

## Pmod Header JB
NET PS_GPIO[32]       LOC=T20 | IOSTANDARD=LVCMOS33; #IO_L15P_T2_DQS_34

and its counterpart in the SDC file is

## Pmod Header JB
set_property -dict "PACKAGE_PIN T20 IOSTANDARD LVCMOS33" [get_ports "PS_GPIO[32]"]

So it’s quite clear and cut that the PS_GPIO[32] signal is connected to PMOD B. It doesn’t hurt taking a look on the board’s schematics as well, if you’re convenient with those drawings, and see that the Zynq device’s pin T20 indeed goes to PMOD B, and which pin.

Hooked up as shown in this pic (click to enlarge):

The offset between PS_GPIO numbers and those designated by Linux is 54. So this pin is found as number 32+54=86.

Hence

# echo 86 > /sys/class/gpio/export
# echo out > /sys/class/gpio/gpio86/direction

And then poor man’s oscillator:

# while [ 1 ] ; do echo 1 > /sys/class/gpio/gpio86/value ; echo 0 > /sys/class/gpio/gpio86/value ; done

This runs at a staggering 2.9 kHz. Pretty impressive for the slowest form of programming one can think about.

This is yet another war story about making the FSBL boot on a Zynq processor.

I had prepared an FSBL for a certain target using SDK 14.6, and then someone needed it in a Vivado package, using the SDK attached to Vivado 2014.1. In a perfect world, I would have exported the system’s configuration from XPS 14.6 to Vivado as an XML file, and generated the FSBL there. But experience shows that nothing really guarantees that the processor’s configuration will be adopted correctly in Vivado. As a matter of fact, I’ve seen that Vivado imports some parameters, and others are ignored.

But hey, I could just copy the existing FSBL source files to a new workspace in the target SDK? After all, it’s just C code!

This is in fact possible, going File > Import… > General > Existing Projects into Workspace. Then navigate to the path of the original project’s workspace. And don’t forget marking “Copy projects into workspace” so that the old one can be moved or deleted. A popup will allow selecting which projects to import, and it’s done!

Well, not. Selecting the three projects in an FSBL source set (fsbl, fsbl_bsp and system_hw_platform) will indeed create a fresh FSBL project, but it fails compiling (saying that it can’t find libxilffs as required by the -lxilffs or something like that).

To work around this, I imported only the system_hw_platform project, and generated the FSBL project in Vivado’s SDK, as usual: File > New > Application Project. Set the name to “fsbl”, make sure that the underlying hardware project it system_hw_platform. Click “Next” and pick “Zynq FSBL” as the template.

This makes sense, because the FSBL project relies on the C sources that were generated when XPS exported the project to SDK. So the hardware configuration remains correct, and the FSBL is new. No reason why this shouldn’t work, in theory.

The project compiled right away, and an fsbl.elf was ready for mixing into a boot.bin file.

Hurray! Not. It didn’t boot.

Despair not

The immediate measure for these cases in compiling the FSBL with the -DFSBL_DEBUG compilation parameter (which defines the FSBL_DEBUG compilation variable, turning on debug messages). With some luck, something informative will show up on the serial console, even if it appeared dead before.

I was one of those lucky bas#$%*s. I got:

PS7_INIT_FAIL : PS7 initialization successful
FSBL Status = 0xA012

Hmmm… That sounds like a mixed-up error message. It failed because it was successful? Well, in fact, the message itself represents the confusion causing the problem.

The FSBL status 0xA012 is returned when the call to ps7_init() fails in main.c. Or more precisely, when the returned value isn’t FSBL_PS7_INIT_SUCCESS. By the way, the FSBL generated by SDK 14.6 doesn’t even bother to check the return value of ps7_init(), but that’s irrelevant here.

Anyhow, note that ps7_init() is defined in the system_hw_platform, which consists of sources generated by XPS 14.6, but called by the FSBL, which was generated by Vivado.

This is a bit delicate, because ps7_init() returns PS7_INIT_SUCCESS when successful (see ps7_init.c), which happens to be defined in ps7_init.h as

#define PS7_INIT_SUCCESS   (0)    // 0 is success in good old C

and non-zero values meaning failure. This is the classic UNIX convention.

For some reason, this is what one finds in fsbl.h:

#ifdef NEW_PS7_ERR_CODE
#define FSBL_PS7_INIT_SUCCESS	PS7_INIT_SUCCESS
#else
#define FSBL_PS7_INIT_SUCCESS	(1)
#endif

In short: FSBL_PS7_INIT_SUCCESS=1, PS7_INIT_SUCCESS=0. A problem indeed.

So this is a direct consequence of mixing an old hardware project with a new FSBL. They changed the error code values somewhere in the middle.

Solution

The clean way to fix this is defining NEW_PS7_ERR_CODE during compilation. The less clean method is just remove this #ifdef statement and leave it as

#define FSBL_PS7_INIT_SUCCESS	PS7_INIT_SUCCESS

And with this FSBL booted correctly and all was well.

I know that getting the FSBL to boot is a recurring problem. Please don’t turn to me for help if your board doesn’t boot — there’s no secret trick, just good old debugging that takes time and effort.

So this is my story: After upgrading the Linux kernel from 3.3 to 3.12 (both having a strong Xilinx flavor, as the target is a Zynq board), but kept an old version of U-boot, I ran through the drill that usually makes the kernel boot:

zynq-uboot> fatload mmc 0 0x8000 zImage
reading zImage

2797680 bytes read
zynq-uboot> fatload mmc 0 0x1000000 devicetree.dtb
reading devicetree.dtb

5827 bytes read
zynq-uboot> go 0x8000
## Starting application at 0x00008000 ...

Error: unrecognized/unsupported machine ID (r1 = 0x1fb5662c).

Available machine support:

ID (hex)        NAME
ffffffff        Generic DT based system
ffffffff        Xilinx Zynq Platform

Please check your kernel config and/or bootloader.

So the kernel didn’t boot. Looking at the way I attempted to kick it off, one may wonder how it worked at all with kernel v3.3. But one can’t argue with the fact that it used to boot.

The first thing to understand about this error message, is that it’s fatally misleading. The real problem is that the device tree blob isn’t found by the kernel, so it reverts to looking for a machine ID in r1. And r1 just has some value. The error message comes from a piece of boot code that is never reached, if the device tree is found and used.

Now, let’s try to understand the logic behind the sequence of commands: The first command loaded the zImage into a known place in memory, 0x8000. One could ask why I didn’t use uImage. Well, why should I? zImage works, and that’s the classic way to boot a kernel.

The device tree blob is then loaded to address 0x10000000.

And then comes the fun part: U-boot just jumps to 0x8000, the beginning of the image. I think I recall that one can put zImage anywhere in memory, and it will take it from there.

But how does the kernel know that the device tree is at 0x10000000? Beats me. I suppose it’s hardcoded somewhere. But hey, it worked! At least on older kernels. And on U-boot 2012.10 and older (but not 2013.10).

For the newer kernel (say, 3.12), a completely different spell should be cast. Something like this (using U-Boot 2012.10 or 2013.10):

zynq-uboot> fatload mmc 0 0x3000000 uImage
reading uImage                                                                  

3054976 bytes read
zynq-uboot> fatload mmc 0 0x2A00000 devicetree.dtb
reading devicetree.dtb                                                          

7863 bytes read
zynq-uboot> bootm 0x3000000 - 0x2A00000
## Booting kernel from Legacy Image at 03000000 ...
   Image Name:   Linux-3.12.0-1.3-xilinx
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3054912 Bytes = 2.9 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a00000
   Booting using the fdt blob at 0x02a00000
   Loading Kernel Image ... OK
OK
   Loading Device Tree to 1fb4f000, end 1fb53eb6 ... OK                         

Starting kernel ...                                                             

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
[ ... kernel boots, bliss and happiness ... ]

OK, so I twisted it all around. All of the sudden, I use an uImage, rather than zImage. Why? Because bootm works with uImage, and bootz wasn’t supported by that specific U-boot version (or configuration, I’m not really sure).

The addresses I loaded into are different too, and I’m not sure it matters. What surely matters, is that bootm was explicitly given the address of the device tree blob, and therefore passed that through a register to the kernel. So in this case, it’s pretty obvious how the kernel finds what’s where.

Ah, but there’s a twist. The latter, bootm-based method didn’t work on the 3.3 kernel. In fact, I got a very similar error message when I tried that.

As I said in the beginning, I never cared dive deep into U-boot. So all I’m saying is — if you encounter an error message like the one above, just try the other magic spell, and hope for good.

And if someone known more about what happened in the connection between U-boot and Linux somewhere in 2012, or has a link to some mailing list discussion where this was decided upon, please comment below. :)

• Download from Buildroot’s home page
• Run “make xconfig”. The configuration is stored in .config
• Possibly set BR2_JLEVEL=8 for parallel compilation(even though 0 should just do it right according to the number of processors present)
• Pick little Endian ARM Cortex-9 for Xillinux (Zynq-7000)
• “make source” to grab the tarballs
• The run “make”. Should take 10 minutes on a quadcore with hyperthreading.
• The cross compiler’s executable is at output/host/usr/arm-buildroot-linux-uclibcgnueabi/bin/gcc but don’t use it directly (or you get “error trying to exec ‘cc1′: execvp: No such file or directory”)
• Instead, go something like

  output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -Wall -O3 --static -o hello hello.c

• The same prefix goes for other cross-compilation binutils