Загрузка ядра Linux на устройствах Zynq (Zybo и ZedBoard)

Мы пытаемся загрузить Linux в системе xilinx, следуя инструкциям в wiki-xilinx-linux. После множества различных тестов, после просмотра (среди прочего) здесь , мы включили опцию «НИЗКОУРОВЕННАЯ ОТЛАДКА ЯДРА И РАННИЕ ПЕЧАТИ». Благодаря этому мы смогли увидеть следующее:

U-Boot 2016.07-03720-g95e11f6 (Oct 13 2016 - 03:48:21 -0700)

Model: Zynq MMC:   sdhci@e0100000: 0
SF: Detected S25FL256S_64K with page size 256 Bytes, eIn:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Model: Z00b000
Hit any key to stop autoboot:  0 
Copying Linux from SD to RAM...
Device: sdhci@e0100000
Manufacturer ID: 2
OEM: 544d
Name: SA04G 
Tran Speed:reading uImage
3842280 bytes read in 342 ms (10.7 MiB/s)
reading devicetree.dtb
8955 bytes read in 20 ms (436.5 KiB/s)
## Booting kernel from Legacy Image at 0008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a00000
   Booting using the fdt blob at OK
   Loading Device Tree to 1eb0e000, end 1eb132fa ... OK

Starting kernel .... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.6.0-xilinx-22282-g7d819bd (leProcessor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasiMemory policy: Data cache writealloc
percpu: Embedded 12 pages/cpu @debcd000 s1115200 root=/dev/mmcblk0p2 rw rootwait
PID hash table entries: 2048 (order: 1, (order: 5, 131072 bytes)
Memory: 494528K/524288K available (5304K kernel code, or  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000( 512 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf   .data : 0xc0900000 - 0xc0939b60   ( 231 kB)
       .bss : 0xc0939b60 - 0xc09R_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cp00 -> 0x72760000
L2C: DT/platform modifies aux control register: 0x72360000 -> ortex-A9
L2C-310 ID prefetch enabled, offset 1 lines
L2C-310 dynamic clock gatnq_clock_init: clkc starts at e0802100
Zynq clock init
sched_clock: 64 bits at_idle_ns: 440795209040 ns
Switching to timer-based delay loop, resolution 3ns
my device 80x30
Calibrating delay loop (skipped), value calculated using timer )
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testinx100058
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP
   VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
clocksT: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic cohe maximum watchpoint size is 4 bytes.
zynq-ocm f800c000.ocmc: ZYNQ OCM pool: 256interface driver usbfs
usbcore: registered new interface driver hub
usbcore: r00
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - CoLinux Sound Architecture Driver Initialized.
clocksource: Switched to clocksourle entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (establish (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered nameRegistered tcp NFSv4.1 backchannel transport module.
hw perfevents: enabled witx_order=17 bucket_order=0
jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Rever for PL330 DMAC-241330
dma-pl330 f8003000.dmac:    DBUFF-128x8bytes Num_Chans-led
xdevcfg f8007000.devcfg: ioremap 0xf8007000 to e086c000
[drm] Initialized brd: module loaded
loop: module loaded
CAN device driver interface
libphy: MACB_mii_bus: probed
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 145 (0rne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copci-pci: EHCI PCI platform driver
usbcore: registered new interface driver usb-si2c /dev entries driver
EDAC MC: ECC not enabled
Xilinx Zynq CpuIdle Driver ste Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: Invalid maximummc0: SDHCI controller on e0100000.sdhci [e0100000.sdhci] using ADMA
ledtrig-cphid: USB HID core driver
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
can: controller ar protocol (rev 20120528 t)
can: netlink gateway (rev 20130117) max_hops=1
Regards found.
Waiting for root device /dev/mmcblk0p2...
mmc0: new high speed SDHCmmcblk0: p1 p2
VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -30
Ple4 ram1  (driver?)
0102           16384 ram2  (driver?)
0103           16384 ra     16384 ram7  (driver?)
0108           16384 ram8  (driver?)
0109          0c           16384 ram12  (driver?)
010d           16384 ram13  (driver?)
010e ?)
b300         3813376 mmcblk0  driver: mmcblk
  b301         1048576 mmcblk0: Unable to mount root fs on unknown-block(179,2)
CPU1: stopping
CPU: 1 PID: 0nd_backtrace) from [<c010a608>] (show_stack+0x10/0x14)
[<c010a608>] (show_stackb24>] (ipi_cpu_stop+0x3c/0x70)
[<c010cb24>] (ipi_cpu_stop) from [<c010d394>] (h4>] (__irq_svc+0x54/0x90)
Exception stack(0xde46ff70 to 0xde46ffb8)
ff60:     01 debdc5c0 474d4ec6 00000000 45283f08 00000000 00000000 00000000
ffa0: 0000000/0x1c0)
[<c0492ccc>] (cpuidle_enter_state) from [<c014a72c>] (cpu_startup_entryFS: Unable to mount root fs on unknown-block(179,2)

Похоже, что Виртуальная файловая система пытается прочитать какой-то неизвестный блок:

VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -30

Погуглил, решений не нашел. Кто-нибудь знает, как это решить? Где мы можем посмотреть? С каким параметром играть?


linux-kernel embedded-linux xilinx vivado zynq
person Leos313    schedule 13.10.2016    source источник
comment
Из этого вывода не видно, что вы вводите в качестве командной строки ядра. У вас там есть rootwait?   -  person 0andriy    schedule 13.10.2016
comment
Я не думаю, что ожидание root поможет, потому что ядро ​​​​уже обнаружило оба раздела. Одна вещь, которую вы можете сделать для отладки, это добавить поле занятости в образ виртуального диска и использовать его как root, чтобы вы могли попытаться вручную смонтировать второй раздел. Также убедитесь, что второй раздел монтируется на другом компьютере с Linux. И убедитесь, что в вашем ядре настроена соответствующая файловая система.   -  person Jamey Hicks    schedule 02.11.2016
comment
У меня похожая проблема с моим Zynq Mini-ITX. Пытаюсь вспомнить, действительно ли я уже решил это. У него есть дополнительный симптом, заключающийся в том, что раздел отображается как доступный только для чтения без видимой причины.   -  person Jamey Hicks    schedule 02.11.2016
comment
Я только что добавил ответ с проблемами, которые я нашел (и решил)   -  person Leos313    schedule 02.11.2016

Ответы (2)


arrow_upward
2
arrow_downward

Наконец я решил все проблемы, которые у меня были (запуск Linux на Zybo с пользовательским аппаратным обеспечением в Programmable Logic). Да, поскольку я новичок, я обнаружил разные проблемы:

1) Одна из проблем была в .dts: полностью отсутствовала часть с eFuse. Xilinx зафиксировала еще одну версию .dts с исправленной проблемой.

2) Еще большая проблема была с битстримом: в начале я хотел запрограммировать PL на Zybo с работающим линуксом, используя: cat bitstream.bit > /dev/xdevcfg. Конечно, это вполне возможно (я проверял), как это объясняется на [этой вики-странице][1]. Проблема: если у вас есть кастомное HW в FPGA, у вас также есть его описание в дереве устройств. Ядро пытается инициализировать всю периферию, подключенную к PS, но, конечно, PL еще не подключен!! Решение состоит в том, чтобы загрузить битовый поток раньше, включив его в boot.bif, чтобы правильно сгенерировать boot.bin:

    image : {
        [bootloader]fsbl.elf
        bitstream.bit
        u-boot.elf
        devicetree.dtb
        uramdisk.image.gz
        uImage.bin   // currently bootgen requires a file extension. this is just a renamed uImage
}

конечно используя: bootgen -image boot.bif -o i boot.bin. Были и другие небольшие проблемы, и я постараюсь добавить список в будущем редактировании этого ответа.

ОБНОВЛЕНИЕ:

для решения описанной в вопросе проблемы, если нет дополнительных проблем/ошибок, достаточно добавить bootargs опцию rootdelay=3 (rootdelay — время задержки перед попыткой монтирования корневой файловой системы). Это может быть необходимо, потому что u-boot слишком быстро пытается получить доступ к SD, а SD еще не готова.

person Leos313    schedule 02.11.2016

arrow_upward
1
arrow_downward

Вы настроили использование корневой файловой системы на mmcblk0p2 — втором разделе вашей SD-карты. Если файловая система действительно находится там, вы должны убедиться, что ядро ​​​​поддерживает то, с чем раздел был отформатирован (например, ext3). Это готовый образ или тот, который вы создали сами? Если вы используете команду petalinux-config перед сборкой, вы можете изменить настройки для хранения файловой системы. Кстати, это очень распространенная проблема, поэтому вы должны найти много информации, если будете использовать правильные термины при поиске в Google.

person Anders    schedule 13.10.2016
comment
Я не использовал petalinux: я использовал файл ramdisk.gz, загруженный с веб-страницы wiki-xilinx-Linux в разделе сборки и изменения корня системного файла. После этого рамдиск был вставлен в тот же раздел boot.bin, devicetree.dtb и uImage. - person Leos313; 14.10.2016
comment
И я создал (спасибо xilinx-tools) все нужные мне файлы: FSBL, U-BOOT, .DTS и так далее. Я надеюсь, что с этой информацией ситуация может быть достаточно ясной. большое спасибо за вашу поддержку - person Leos313; 14.10.2016
comment
Почему-то ищет корень на втором разделе. Обычно вам нужно изменить это, остановив U-boot при нажатии любой клавиши, чтобы остановить автозагрузку, и проверить настройки с помощью printenv. Найдите root=/dev/mmcblk0p2 rw rootwait. Вы также можете начать с просмотра default_bootcmd и выяснить, что он делает. На ZedBoard вы можете установить режим загрузки с помощью перемычек, поэтому обязательно проверьте их. Я свяжусь с вами, когда проверю, какими должны быть загрузочные аргументы при использовании виртуального диска. - person Anders; 15.10.2016
comment
Еще раз спасибо. Может быть, мы нашли одну из проблем: я дам вам новости в понедельник - person Leos313; 16.10.2016
comment
Наконец мы решили проблемы (да, мы столкнулись не с одной): - Командная строка ядра: console=ttyPS0,115200 root=/dev/mmcblk0p2 rw EarlyPrintk rootfstype=ext4 rootwait devtmpfs.mount=1 - Файл zynq-7000 .dtsi был неверным: ВЧЕРА Xilinx закоммитила еще одну версию на git !!!!!!!!!! - person Leos313; 18.10.2016
comment
Рад слышать, что это сработало. Вы можете поместить эту информацию в ответ и отметить ее как правильный ответ. - person Anders; 19.10.2016
comment
Я только что добавил ответ с проблемами, которые я нашел (и решил несколько дней назад). раньше не было возможности написать - person Leos313; 02.11.2016