Not able to run raspi3-tutorial (by bztsrc) on 3B board

[LittleTree]

Hi,
I am trying out the famous "0F_executionlevel" tutorial from https://github.com/bztsrc/raspi3-tutori ... utionlevel on the real hardware board 3B.

My first attempt was to run launch it from U-Boot. This ended up in a board reset. The details of loading and reset log are given below

U-Boot> fatload mmc 0 0x1000000 kernel8.img
1000 bytes read in 5 ms (195.3 KiB/s)
U-Boot> go 0x1000000
## Starting application at 0x01000000 ...
"Synchronous Abort" handler, esr 0x86000004
elr: 000000010009877c lr : 000000010009877c (reloc)
elr: 000000013b36a77c lr : 000000013b36a77c
x0 : 0000000003000022 x1 : 0000000000000000
x2 : 0000000001000084 x3 : 000000000000003f
x4 : 0000000000000000 x5 : 0000000000001c80
x6 : 0000000000000010 x7 : 0000000000000008
x8 : 0000000000000001 x9 : 0000000000000008
x10: 0000000000000010 x11: 000000003e7f68a0
x12: 0000000000000001 x13: 000000003e7f68a0
x14: 0000000000000000 x15: 0000000000000000
x16: 0000000001000000 x17: 0000000000000004
x18: 000000003af4ddb0 x19: 000000003af4dc40
x20: 000000003b36bdbc x21: 000000003af4dd10
x22: 0000000000000000 x23: 0000000000000000
x24: 0000000000000002 x25: 000000000000000a
x26: 0000000000000000 x27: 0000000000000000
x28: 000000003af5f6c0 x29: 000000003af4dbe0

Code: "Synchronous Abort" handler, esr 0x96000004
elr: 0000000000082afc lr : 0000000000082adc (reloc)
elr: 000000003b354afc lr : 000000003b354adc
x0 : 000000003b3be097 x1 : 000000003ebebc00
x2 : 0000000000000040 x3 : 000000000000003f
x4 : 0000000000000000 x5 : 0000000000001c80
x6 : 0000000000000010 x7 : 0000000000000008
x8 : 0000000000000001 x9 : 0000000000000008
x10: 0000000000000010 x11: 000000003ea30440
x12: 0000000000000001 x13: 000000003ea30440
x14: 0000000000000000 x15: 0000000000000000
x16: 0000000000000004 x17: 0000000000000004
x18: 000000003af4ddb0 x19: 000000013b36a76c
x20: 000000003b3c3268 x21: 00000000fffffffc
x22: 000000003b3c41ce x23: 000000003b3be097
x24: 0000000000000002 x25: 000000000000000a
x26: 0000000000000000 x27: 0000000000000000
x28: 000000003af5f6c0 x29: 000000003af4da70

Code: d1004273 91073ad6 aa0003f7 12800075 (b9400261)
Resetting CPU ...

resetting ...

Then tried to load the code directly on the board (without U-Boot). It looks like it resulted in a half way hang (or UART fail?)

My config.txt file is given below

enable_uart=1
kernel=kernel8.img
arm_64bit=1
core_freq=250
device_tree=bcm2710-rpi-3-b.dtb

The execution log is given below (copied from terminal connected to UART, the main display is just the initial colourful start image)

Raspberry Pi Bootcode
Read File: config.txt, 91
Read File: start.elf, 2975104 (bytes)
Read File: fixup.dat, 7265 (bytes)
MESS:00:00:01.061593:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.065736:0: brfs: File read: 91 bytes
MESS:00:00:01.130393:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.134608:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:01.334746:0: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
MESS:00:00:01.342298:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:01.348207:0: *** Restart logging
MESS:00:00:01.352082:0: brfs: File read: 91 bytes
MESS:00:00:01.384011:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
MESS:00:00:01.399615:0: HDMI0: hdmi_pixel_encoding: 162000000
MESS:00:00:01.413001:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb
MESS:00:00:01.417665:0: Loaded 'bcm2710-rpi-3-b.dtb' to 0x100 size 0x7cb2
MESS:00:00:01.438813:0: brfs: File read: 31922 bytes
MESS:00:00:01.460180:0: brfs: File read: /mfs/sd/overlays/overlay_map.dtb
MESS:00:00:01.552701:0: brfs: File read: 2295 bytes
MESS:00:00:01.557537:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.567579:0: brfs: File read: 91 bytes
MESS:00:00:01.571427:0: brfs: File read: /mfs/sd/cmdline.txt
MESS:00:00:01.576004:0: Read command line from file 'cmdline.txt':
MESS:00:00:01.581870:0: 'earlycon=uart8250,mmio32,0x3f215040 console=serial0,115200 console=tty1 root=PARTUUID=7a50a74a-02 rootfstype=ext4 fsck.repair=yes rootwait'
MESS:00:00:02.261967:0: kernel=kernel8.img
MESS:00:00:02.264366:0: brfs: File read: 139 bytes
MESS:00:00:02.273191:0: brfs: File read: /mfs/sd/kernel8.img
MESS:00:00:02.277150:0: Loaded 'kernel8.img' to 0x80000 size 0x3e8
MESS:00:00:02.283068:0: Device tree loaded to 0x2eff7d00 (size 0x8215)
MESS:00:00:02.290860:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:02.297149:0: uart: Baud rate change done...
MESS:00:00:02.300580:0: uart: Baud rate

What might be the reason for this?

I ended up in this tutorial when my code for switching from EL2 to EL1 was not working. The details of this problem is given below.

1) The board booted using U-Boot and in EL2
2) Started my bare metal application from u-boot using fatload and go commands as shown above. Using the code from "03_uart1", I am able to print messages to the console.
3) The execution of ERET instruction is not working as expected (To land in EL1). It looks like the code is not landing in the EL1 handler. The system looks like hung. The same code works on QEMU (on virt board, without U-Boot).

Thanks in advance for any hints given. I can share more details if needed

[DougieLawson]

Why are you booting the 64-bit kernel with 32-bit userspace.

Change

Code: Select all

kernel=kernel8.img

to

Code: Select all

#kernel=kernel8.img

to get the 3B back to 32-bit everywhere.

[LittleTree]

Sorry, I did not understand.
The "kernel8.img" is just a name for a bare metal application (Not a Linux kernel). The application is a 64bit bare metal binary.

In bzsrc, the "tutorial - 0F_executionlevel" uses PL011 (uart0) for UART output. Looks like that UART code (or my UART configration/baudate) has some issue. Did not dig further. I have replaced that PL011 UART code with Primary UART code (tutorial - 03_uart1). When this program launched from config.txt (without U-Boot), it works as expected.

But when launched from U-Boot it is not working as expected!! In U-Boot I have used tftpboot to load the binary to the address 0x80000. Then gave "go 0x80000" command for execution. The EL2 part of the code is executed as expected. When the code switches to EL1, looks like the memory contain garbage... Not able to figure this out... ( I have inspected the memory using JTAG debugger. When the PC is in EL2, inspecting EL1 memory contains valid instructions. When the PC lands in EL1, the memory contains random values. Not sure if U-boot has some role to play in this)