kernkonzept / bootstrap

The bootloader of the L4Re operating system.
8 stars 4 forks source link

Request to add support for Zybo Z7 in zynq.cc #3

Closed ijyothi closed 6 months ago

ijyothi commented 6 months ago

Hello I am trying to run the L4Re on Zybo Z7.

Since it is a new bsp I tried to generate the defconfig file by following the guide of configuring your own bsp in L4Re documentation.

But, even the example Hello World doesnt work on Zybo Z7 which I think is happening probably in bootstrap as the bootstraper doesnt start.

I attach my U Boot log below

`U-Boot 2018.09-00427-g4024652143-dirty (Sep 01 2023 - 17:07:44 +0200)
CPU:   Zynq 7z020
Silicon: v3.1
Model: Digilent Zybo Z7 board
I2C:   ready
DRAM:  ECC disabled 1 GiB
MMC:   sdhci@e0100000: 0
Loading Environment from SPI Flash... SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 16 MiB
OK
In:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Net:   ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id

Warning: ethernet@e000b000 (eth0) using random MAC address - 36:c7:49:3e:11:ce
eth0: ethernet@e000b000
Checking if uenvcmd is set ...
Hit any key to stop autoboot:  0
15130688 bytes read in 967 ms (14.9 MiB/s)
11258 bytes read in 14 ms (785.2 KiB/s)
## Booting kernel from Legacy Image at 03000000 ...
   Image Name:   L4 Image #30
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    15130624 Bytes = 14.4 MiB
   Load Address: 01000000
   Entry Point:  01000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a00000
   Booting using the fdt blob at 0x2a00000
   Loading Kernel Image ... OK
   Loading Device Tree to 3eb2a000, end 3eb2fbf9 ... OK

Starting kernel ...`

Any advice on how to adapt the zynq.cc Uart etc for this to work?

admlck commented 6 months ago

Hi, looks like this is using the second UART. Could you try generating the uimage with PLATFORM_UART_NR=1 ?

ijyothi commented 6 months ago

Hi, thank you very much for the reply.

So the defconfig has the PLATFORM_UART_NR=1 which is same as that of Zedboard. Only the RAM size of Zybo becomes 1024 MB , as I understand the documentation. The entire architecture of L4 and Fiasco is same for Zedboard and Zybo therefore I think this porting should be natural, but it is not.

Hence I think it comes from the UART definition in the zynq.cc file. How are the values for Zedboard calculated? I didn’t quite understand that.

Thanks for the help!

ijyothi commented 6 months ago

Hello, I have the L4 Bootstrapper booting up. For this I used the ZedBoard defconfig with modified RAM_SIZE and kuart.base_baud in zynq.cc as 0.


U-Boot 2018.09-00427-g4024652143-dirty (Sep 01 2023 - 17:07:44 +0200)

CPU:   Zynq 7z020
Silicon: v3.1
Model: Digilent Zybo Z7 board
I2C:   ready
DRAM:  ECC disabled 1 GiB
MMC:   sdhci@e0100000: 0
Loading Environment from SPI Flash... SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 16 MiB
OK
In:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Net:   ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id

Warning: ethernet@e000b000 (eth0) using random MAC address - b2:c3:4d:32:25:a9
eth0: ethernet@e000b000
Checking if uenvcmd is set ...
Hit any key to stop autoboot:  0
1914864 bytes read in 131 ms (13.9 MiB/s)
11258 bytes read in 18 ms (610.4 KiB/s)
## Booting kernel from Legacy Image at 03000000 ...
   Image Name:   L4 Image #35
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1914800 Bytes = 1.8 MiB
   Load Address: 01000000
   Entry Point:  01000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a00000
   Booting using the fdt blob at 0x2a00000
   Loading Kernel Image ... OK
   Loading Device Tú
L4 Bootstrapper
  Build: #35 Thu Mar 14 09:58:05 CET 2024, 11.4.0
  Scanning up to 1024 MB RAM, starting at offset 32MB
  Memory size is 1024MB (00000000 - 3fffffff)
  RAM: 0000000000000000 - 000000003fffffff: 1048576kB
  Total RAM: 1024MB
  Scanning fiasco
  Scanning sigma0
  Scanning moe
  Moving up to 7 modules behind 1100000
  moving module 06 { 11b4000-11d37af } -> { 12a3000-12c27af } [128944]
  moving module 05 { 11b3000-11b3084 } -> { 12a2000-12a2084 } [133]
  moving module 04 { 113c000-11b299f } -> { 122b000-12a199f } [485792]
  moving module 03 { 1127000-113b623 } -> { 1216000-122a623 } [83492]
  moving module 02 { 10fc000-1126747 } -> { 11eb000-1215747 } [173896]
  moving module 01 { 10f5000-10fb467 } -> { 11e4000-11ea467 } [25704]
  moving module 00 { 1011000-10f47ef } -> { 1100000-11e37ef } [931824]
  Loading fiasco
  find kernel info page...
  found kernel info page (via ELF) at 2000
  Loading sigma0
  Loading moe
Regions of list 'regions'
    [     1000,     ecfff] {    ec000} Kern   fiasco
    [    ed000,     edfff] {     1000} Root   mbi_rt
    [   200000,    20b22f] {     b230} Sigma0 sigma0
    [   240000,    2680d7] {    280d8} Root   moe
    [   26a008,    276577] {     c570} Root   moe
    [  1000000,   100f9a3] {     f9a4} Boot   bootstrap
    [  10000d0,   1000143] {       74} Root   cpu_boot
    [  1010180,   10106c9] {      54a} Boot   modinfo
    [  1216000,   12c27af] {    ac7b0} Root   Module
  found kernel options (via ELF) at 3000
    ---------------------------------------------------------------------
    CPU 0 [00000003]: Kernel prefetch abort
Trap in JDB: IP:00000003 PSR=000f0193 ERR=cc000000
Trap in JDB: IP:00ffff00 PSR=00ffff00 ERR=00ffff0c

KERNEL: Warning: No page-fault handler for 0xe592a018, error 0x94000005, pc f00183e8
EXCEPTION: (00) undef insn pfa=f00e74c8, error=00000000 psr=600001d3
R[0]: f00e74c8 00000000 00000000 ffff0000  f13c8000 f13c81e0 00000000 00000000
R[8]: f00183e8 04000000 ffff0000 00000001  00000000 f004450c 00000001 f0018c3c
Data around PC at 0xf0018c3c:
  0xf0018c24: 1a000014
  0xf0018c28: e594e034
  0xf0018c2c: e3ce0002
  0xf0018c30: e5901000
  0xf0018c34: e591300c
  0xf0018c38: e12fff33
->0xf0018c3c: e3500000
  0xf0018c40: 02841f47
  0xf0018c44: 0affff04
  0xf0018c48: e1a00005
  0xf0018c4c: eb008aa1
  0xf0018c50: e30509d0
  0xf0018c54: e34f0008

KERNEL: Warning: Sigma0 raised an exception --> HALT
Panic: ...
Trap in JDB: IP:f00169f4 PSR=a0000193 ERR=cc000000
Not using serial hack in slow timer handler.
Welcome to L4/Fiasco.OC!
L4/Fiasco.OC microkernel on arm
Rev: unknown compiled with gcc 11.4.0 for Xilinx Zynq    []
Build: #7 Wed Mar 13 19:05:43 CET 2024

KERNEL: Warning: No page-fault handler for 0xed0ffff0, error 0x94000048, pc f003ac84

KERNEL: Warning: No page-fault handler for 0xea000005, error 0x94000045, pc f0010c30

KERNEL: Warning: No page-fault handler for 0xea000005, error 0x94000045, pc f0010c30

KERNEL: Warning: No page-fault handler for 0xea000005, error 0x94000045, pc f0010c30

KERNEL: Warning: No page-fault handler for 0xea000005, error 0x94000045, pc f0010c30

KERNEL: Warning: No page-fault handler for 0xea000005, error 0x94000045, pc f0010c30

KERNEL: Warning: No page-fault handler for 0xea000005, error 0x94000045, pc f0010c30

KERNEL: Warning: No page-fault handler for 0xea000005, error 0x94000045, pc f0010c30

How can I fix this issue of panic in sigma 0? Any kind of insight would be appreciated.

admlck commented 6 months ago

I do not see an immediate reason. Could you make maybe the device tree (dtb) of the Zybo board available? And the globalconfig.out from fiasco's build-tree are helpful as well as the .config from the l4 build tree. Thanks.

ijyothi commented 6 months ago

Hello, To reproduce this, I am using the PT= Zedboard and its CPU type etc for this build. I also am using a very simple dts. I cannot seem to grep to the error Warning: Sigma0 raised an exception --> HALT Panic: ... I am attaching the files you requested to this issue. output_files.zip Hope to fix this soon, thanks

admlck commented 6 months ago

Hi, to cross check, does it work in QEMU? With: qemu-system-arm -kernel images/bootstrap.elf -serial null -serial stdio -m 512 -M xilinx-zynq-a9 For debugging your fiasco and sigma0 binaries are also useful. Thanks.

ijyothi commented 6 months ago

Hello

Thanks for the update. No, I have not worked on qemu as my main goal was to do sd boot on the hardware. But if you insist, I can try.

I am also attaching the binaries you requested. bin.zip

Thanks

admlck commented 6 months ago

Can you please also attach the generated bootstrap.elf? Note that I do not have your board, I'm merely trying to reproduce your issue with the means I have (QEMU).

ijyothi commented 6 months ago

Hello, yes thanks for the help.

EDIT: Updated the elf file. I am attaching the bootstrap_image.zip I am using. Upon further searching I found that the page fault happens in this file here in fiasco, can you direct me as to why this happens and if i can override this? Also FYI, I am using RAM_SIZE=1024MB, does this have anything to do with these ?

if none of this works, is there a prebuilt image binary I can use for Zynq 32bit SoCs with ARM Cortex-A9, L4Re architecture ARMv7-A (same as Zedboard)?

ijyothi commented 6 months ago

I tried running on Qemu and end up getting stuck here now.. image

admlck commented 6 months ago

Could you please update your fiasco repository (from github) and rebuild? I have fixed this particular issue I believe.

ijyothi commented 6 months ago

Hello , I tried with the latest Fiasco, but it still fails at sigma 0 exception. bootstrap (2).zip

image

admlck commented 6 months ago

Could you also please update all of the other repos as well? We recently changed the kernel invocation mechanism and I see sigma0 using the previous (old) method.

ijyothi commented 6 months ago

Hello, thanks for the information and your constant advice. I happened to rebuild from the github, previously I was using the 2023 Snapshot, and now it boots on qemu machine for me. Although the same elf file still doesnt boot on the board from sd card. Do you happen to have an idea why this inconsistency? Qemu> image

Uboot of sd boot> image

admlck commented 6 months ago

Hi, we can try to figure it out what the difference might be. First thing would be to see what's on f003c96c. Could you share the fiasco / bootstrap.elf file that you use on the target?

ijyothi commented 6 months ago

Hello, here are the files I am working with. I m thinking perhaps it could be the address mismatch from zedboard to zybo, although I am not sure. Thanks for the support. files.zip

admlck commented 6 months ago

Ok, one more, also please the fiasco.debug file :)

ijyothi commented 6 months ago

Attaching with the debug file. EDIT: updated the link files.zip

admlck commented 6 months ago

Is the link ok? It just points to this issue's URL...

admlck commented 6 months ago

The fault happens in the CPU boot-up of the second core. Does it work if you disable multi-processing in the fiasco config? Does the Zybo have one or two cores?

ijyothi commented 6 months ago

The Zybo has two cores. I will try with disabling the multiprocessing in Fiasco. Is it a part of the menuconfig?

admlck commented 6 months ago

Yes, it's in the menuconfig.

ijyothi commented 6 months ago

Yes! that solved it! Thank you so much for this support!

image