UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor panyu
Visitor
10,907 Views
Registered: ‎01-04-2013

Zedboard booting problem in a Yocto build

Hi all,

 

I'm using the meta layer from https://github.com/milosoftware/meta-zynq with Yocto Danny for my Zedboard build. I used Xilinx 14.2 SDK to generate the FSBL, and included no bitstream in BOOT.bin. The zc702-proto-image builds fine. However while booting from SD card, the init got stuck at the point of udev. Removing the udev script under /etc/rcS.d enables booting straight to the login, however, I'm not sure about the side effects.

 

The boot log is as follows

 

U-Boot 2012.04.01-00304-g7639205-dirty (Jan 03 2013 - 19:23:26)
                                                        
DRAM:  512 MiB
WARNING: Caches not enabled
MMC:   SDHCI: 0
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   zynq_gem
Hit any key to stop autoboot:  0 
Device: SDHCI
Manufacturer ID: 2
OEM: 544d
Name: SA08G 
Tran Speed: 25000000
Rd Block Len: 512
SD version 2.0
High Capacity: Yes
Capacity: 7.3 GiB
Bus Width: 4-bit
reading zedboard-autorun.scr

335 bytes read
## Executing script at 01900000
Load kernel from SD card...
reading uImage

2920880 bytes read
reading devicetree.dtb

17860 bytes read
Booting...
## Booting kernel from Legacy Image at 000079c0 ...
   Image Name:   Linux-3.5.0-14.3-build2
   Created:      2013-01-03  10:57:10 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2920816 Bytes = 2.8 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 1fb64000, end 1fb6b5c3 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Linux version 3.5.0-14.3-build2 (panyu@gallium1) (gcc version 4.7.2 (GCC) ) #1 3
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq ZED
Memory policy: ECC disabled, Data cache writealloc
PERCPU: Embedded 7 pages/cpu @c0932000 s7296 r8192 d13184 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
Kernel command line: console=ttyPS0,115200 root=/dev/mmcblk0p2 rw rootfstype=ext
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512MB = 512MB total
Memory: 514352k/514352k available, 9936k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xe0800000 - 0xfd000000   ( 456 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc04b628c   (4793 kB)
      .init : 0xc04b7000 - 0xc04dac80   ( 144 kB)
      .data : 0xc04dc000 - 0xc0511ae0   ( 215 kB)
       .bss : 0xc0511b04 - 0xc052a880   ( 100 kB)
Preemptible hierarchical RCU implementation.
        Dump stacks of tasks blocking RCU-preempt GP.
NR_IRQS:128
Zynq clock init
xlnx,ps7-ttc-1.00.a #0 at 0xe0800000, irq=43
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1332.01 BogoMIPS (lpj=6660096)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
Setting up static identity map for 0x35c2b0 - 0x35c2e4
Map SLCR registers
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated (2664.03 BogoMIPS).
devtmpfs: initialized
NET: Registered protocol family 16
xgpiops e000a000.gpio: gpio at 0xe000a000 mapped to 0xe0806000
registering platform device 'pl330' id 0
registering platform device 'arm-pmu' id 0
registering platform device 'zynq-dvfs' id 0
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
xslcr xslcr.0: at 0xF8000000 mapped to 0xF8000000
bio: create slab <bio-0> at 0
SCSI subsystem initialized
xqspips e000d000.spi: master is unqueued, this is deprecated
xqspips e000d000.spi: at 0xE000D000 mapped to 0xE0808000, irq=51
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Linux video capture interface: v2.00
Advanced Linux Sound Architecture Driver Version 1.0.25.
Switching to clocksource xttcpss_timer1
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 5, 196608 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
xscugtimer xscugtimer.0: ioremap fc00c200 to e080a200 with size 400
pl330 dev 0 probe success
Xilinx CpuIdle Driver started
fuse init (API version 7.19)
msgmni has been set to 1004
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
e0001000.uart: ttyPS0 at MMIO 0xe0001000 (irq = 82) is a xuartps
console [ttyPS0] enabled
xdevcfg f8007000.devcfg: ioremap f8007000 to e080e000 with size 1000
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
loop: module loaded
m25p80 spi1.0: s25fl256s1 (32768 Kbytes)
5 ofpart partitions found on MTD device spi1.0
Creating 5 MTD partitions on "spi1.0":
0x000000000000-0x000000060000 : "qspi-bootloader"
0x000000060000-0x000000070000 : "qspi-u-boot-env"
0x000000070000-0x000000080000 : "qspi-device-tree"
0x000000080000-0x000000480000 : "qspi-linux"
0x000000480000-0x000001000000 : "qspi-rootfs"
GEM: BASEADDRESS hw: e000b000 virt: e0810000
XEMACPS mii bus: probed
eth0, pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
usb_hcd_xusbps_probe: No OTG assigned!
usb_hcd_xusbps_probe: OTG now assigned!
xusbps-ehci xusbps-ehci.0: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.0: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.0: irq 53, io mem 0x00000000
xusbps-ehci xusbps-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
Xilinx PS USB Device Controller driver (Apr 01, 2011)
mousedev: PS/2 mouse device common for all mice
usbcore: registered new interface driver Philips webcam
gspca_main: v2.14.0 registered
usbcore: registered new interface driver uvcvideo
USB Video Class driver (1.1.1)
xwdtps f8005000.swdt: Xilinx Watchdog Timer at 0xe0812000 with timeout 10s
cpuidle: using governor ladder
cpuidle: using governor menu
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: Invalid maximum block size, assuming 512 bytes
mmc0: SDHCI controller on e0100000.sdhci [e0100000.sdhci] using ADMA
/amba@0/leds/mmc_led: could not find phandle
Skipping unavailable LED gpio -22 (mmc_led)
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
NET: Registered protocol family 17
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
Registering SWP/SWPB emulation handler
registered taskstats version 1
gpio-keys gpio_keys.4: Unable to get irq number for GPIO 50, error -6
ALSA device list:
  No soundcards found.
Waiting for root device /dev/mmcblk0p2...
mmc0: new high speed SDHC card at address 1234
mmcblk0: mmc0:1234 SA08G 7.28 GiB 
 mmcblk0: p1 p2
EXT4-fs (mmcblk0p2): recovery complete
EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 179:2.
devtmpfs: mounted
Freeing init memory: 140K
INIT: version 2.88 booting
Error opening /dev/fb0: No such file or directory
Starting udev
udev[664]: starting version 164

 

Thanks for your help :-)

 

Pan Yu

 

0 Kudos
14 Replies
Scholar austin
Scholar
10,899 Views
Registered: ‎02-27-2008

Re: Zedboard booting problem in a Yocto build

Pan,

 

You might also want to post on the forums on zedboard.org website, which is dedicated to these boards.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Adventurer
Adventurer
10,892 Views
Registered: ‎05-07-2012

Re: Zedboard booting problem in a Yocto build

I think the problem is the udev version that was in meta-oe until recently. That version should have been removed so the build uses the recipe from oe-core. I already replied to Pan Yu in email.

 

Updating the meta-oe layer should resolve the issue.

 

 

0 Kudos
Visitor panyu
Visitor
10,884 Views
Registered: ‎01-04-2013

Re: Zedboard booting problem in a Yocto build

@balister, thanks a lot for your suggestions both here and in the email. I'm using yocto, and will modify the udev recipe to match with the oe-core one and let you know.

 

@austin, sorry for posting the less related topic here. It was for the reason that both the authors of the BSP layer are actively using this forum. I'll use zedboard.org later on for zedboard related issues. Thank you for your understanding.

0 Kudos
Adventurer
Adventurer
10,879 Views
Registered: ‎05-07-2012

Re: Zedboard booting problem in a Yocto build

Pan, git pull on the meta-oe layer should result in the problem recipes being removed.

0 Kudos
Visitor panyu
Visitor
10,860 Views
Registered: ‎01-04-2013

Re: Zedboard booting problem in a Yocto build

Hi Balister, this is an update, and it seems still not working properly.

 

I have extracted the udev/udev-extraconf recipes from oe-core, and put them under yocto's meta/recipes-core/udev, with slight modifications such that both yocto's udev_164.bb and oe-core's udev_182.bb should work.

 

I have "bitbake -s | grep udev" to see the following, so as to ensure that bitbake picks up the updated udev recipe.

udev                                                  :182-r3                          
udev-extraconf                                        :1.0-r7   

After regenerating and deploying the zc702-proto-image, The boot process still got stuck at the same udev point with udev enabled, showing the following (again it confirms that udev 182 version is now in place.

Starting udev
udevd[666]: starting version 182

 Any more suggestions?

0 Kudos
Scholar milosoftware
Scholar
10,849 Views
Registered: ‎10-26-2012

Re: Zedboard booting problem in a Yocto build

My guess is that you have "something" configured that needs FPGA logic to function, e.g. a framebuffer.

At boot, udev will enumerate the hardware and try to load the drivers for it. If it loads the driver for the framebuffer while the FPGA bitfile hasn't been loaded yet, the system will completely hang at that point. So make sure you load the bitfile before udev starts.

 

BTW, I'd recommend using mdev instead of udev on embedded systems. It offers over 90% of the functionality with less than 10% of the code (and complexity).

0 Kudos
Visitor panyu
Visitor
10,842 Views
Registered: ‎01-04-2013

Re: Zedboard booting problem in a Yocto build

@milosoftware, thanks a lot for your reply. Currently I don't include a bitstream in BOOT.bin, so I guess there shouldn't be anything preconfigured in the PL. The board is out-of-the-box state with jumpers set to SD card boot. I attached a board picture with jumper settings in case you'd like to perform some testing on your side. As mentioned previously, I am using the meta-zynq layer with Yocto 1.3 danny, and not sure whether this makes some difference than with OE.

 

I'll keep in mind for mdev later on when I got more familiar with Yocto/OE. Thanks for your suggestions.

zedboard_init_jumper_setup.jpg
0 Kudos
Scholar milosoftware
Scholar
10,839 Views
Registered: ‎10-26-2012

Re: Zedboard booting problem in a Yocto build

Well, since you're using "my" bsp, it does not need a BOOT.bin with logic, you can load the logic from linux. This is much faster than loading from BOOT.bin.

 

What I recommend:

- boot once from the SD card with the jumpers as you have them.

- Write the boot.bin into the first partition on the internal flash, you should be able to do this from within linux, by running:
 "flashcp /media/mmcblk0p1/BOOT.bin /dev/mtd0" (provided that you've mounted the SD card).

- Set the third jumper to the lower position to select booting from internal flash.

- Optional: Add "fpga-image" to your image to load the bitstream into the FPGA logic at boot.

 

Loading the bootloader from QSPI flash will save you about 5 seconds boot time, for some reason booting from SD is very very slow. The BSP provided u-boot will check the SD card and automatically load the kernel and rootfs from it if detected and an image is present on it, otherwise it will try to boot from the flash. So you will never need to change the jumper setting again, at least untill you kill the bootloader in flash...

0 Kudos
Explorer
Explorer
10,280 Views
Registered: ‎02-17-2013

Re: Zedboard booting problem in a Yocto build

Hey 

When I build my Open embedded Os I have this warning I can't fetch a file compressed Is is serious ? 

WARNING: Failed to fetch URL ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz, attempting MIRRORS if available

0 Kudos
Scholar milosoftware
Scholar
4,636 Views
Registered: ‎10-26-2012

Re: Zedboard booting problem in a Yocto build

This warning means that one of the mirrors was down. If it doesn't turn into an error there is not much to worry about yet.

0 Kudos
Explorer
Explorer
4,628 Views
Registered: ‎02-17-2013

Re: Zedboard booting problem in a Yocto build

More I want know how I add my PL the file system.bit in the u-boot.bin when I build the os base on the distribution open-embedded. Do you have an idea ? 

0 Kudos
Scholar milosoftware
Scholar
4,626 Views
Registered: ‎10-26-2012

Re: Zedboard booting problem in a Yocto build

Several actually.

 

But I wouldn't. Putting the bitstream into boot.bin is just bad practise (my opinion). It's much more convenient and efficient to put it in the root filesystem and have Linux load it. It allows the bitfile to be compressed (less space and/or faster loading) and allows other processes to continue while the PL is initializing.

 

Slightly less efficient, but still much more efficient than a boot.bin is to have u-boot initialize the PL. Then it can be "anywhere" like on SD or TFTP and you can also compress it.

 

If you use the recipes from my meta-zynq layer, it will even call the Xilinx tools and compile the bitfile into the image by just pointing it at a repository. By default it loads a reference design that enables most hardware (like HDMI).

https://github.com/milosoftware/meta-zynq

0 Kudos
Explorer
Explorer
4,613 Views
Registered: ‎02-17-2013

Re: Zedboard booting problem in a Yocto build

WIth your meta-zynq layer, when I build the OS how can I add my PL = system.bit in the rootfs ? What files I need change ? 

0 Kudos
Scholar milosoftware
Scholar
4,608 Views
Registered: ‎10-26-2012

Re: Zedboard booting problem in a Yocto build

Add the "fpga-image" to your image recipe. That will take care of everything, put the FPGA bitstream in the rootfs, and load it at boot. The "my-image" example showcases this.

 

Beware - any kernel driver that requires PL at "probe" time must be compiled as a "module". Most drivers will fail horribly when the PL isn't there. The standard kernel/image in the layer has this properly configured already, so that you can use the framebuffer and audio drivers as usual.

0 Kudos