SAMA5D27-SOM1 Bare Metal Application Boot Problem

Moderator: nferre

enricoPalazzo
Posts: 7
Joined: Mon Jun 10, 2019 12:58 pm

SAMA5D27-SOM1 Bare Metal Application Boot Problem

Tue Jun 25, 2019 10:42 pm

I am trying to boot and run a bare metal Softpack example binary for the SAMA5D27-SOM1_EK1 starting with examples from AT91 website and this forum. My idea was to burn at91bootstrap, u-boot and the dtb to NVM (started with QSPI) using SAM-BA.

Got at91bootstrap and u-boot-at91 from GirHub.

Cross compiled at91bootstrap with GCC toolchain "arm-none-eabi".
$ make mrproper
$ make ARCH=arm CROSS_COMPILE=arm-none-eabi- sama5d27_som1_ekqspi_uboot_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-none-eabi-

same for u-boot-at91
$ make ARCH=arm CROSS_COMPILE=arm-none-eabi- sama5d27_som1_ek_qspiflash_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-none-eabi-

Got SAM-BA installed and verified JLink connection.
$ ./sam-ba --port help
Known ports: serial, j-link

Copied the sama5d27_som1_ek-dataflashboot-uboot-3.8.13-rc3.bin
from /at91bootstrap/binaries/
into /sam-ba_3.2.3/examples/sama5d2/qspiflash directory and renamed it at91bootstrap.bin.

Copied u-boot.bin output binary
from /u-boot-at91
into /sam-ba_3.2.3/examples/sama5d2/qspiflash directory.

Then attempted to write the 3 binaries to QSPI from the /sam-ba_3.2.3/examples/sama5d2/qspiflash directory. (I got the dtb from AT91 website.)
$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a qspiflash -c erase
$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a qspiflash -c writeboot:at91bootstrap.bin
$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a qspiflash -c write:u-boot.bin:0x8000
$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a qspiflash -c write:at91-sama5d27_som1_ek.dtb:0x60000
$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a bootconfig -c writecfg:bscr:valid,bureg0
$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a bootconfig -c writecfg:bureg0:ext_mem_boot,sdmmc1_disabled,sdmmc0_disabled,nfc_disabled,spi1_disabled,spi0_disabled,qspi1_disabled,qspi0_ioset3

This all appeared to go OK, but when I reset the board the "ROMBoot" message is all I got. I was expecting u-boot to run so I could set environment variables, etc. I was going to try to burn the bare metal application .bin also (or download it over Ethernet) as I have with other SoCs, but think I am doing something fundamentally wrong. Is there a jumper on this board that I need to make -the J13 connection is open?

I appreciate any guidance you can give! Thanks.
blue_z
Location: USA
Posts: 1988
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAMA5D27-SOM1 Bare Metal Application Boot Problem

Wed Jun 26, 2019 2:17 am

enricoPalazzo wrote: Then attempted to write the 3 binaries to QSPI from the /sam-ba_3.2.3/examples/sama5d2/qspiflash directory. (I got the dtb from AT91 website.)
...
$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a bootconfig -c writecfg:bscr:valid,bureg0
$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a bootconfig -c writecfg:bureg0:ext_mem_boot,sdmmc1_disabled,sdmmc0_disabled,nfc_disabled,spi1_disabled,spi0_disabled,qspi1_disabled,qspi0_ioset3
Why are you using this specific BUREG0 configuration value?
Your boot configuration disables all external memories except QSPI0, which will use I/O set 3.

According to SOM1 datasheet, Figure 5-7 indicates the QSPI flash chip is wired to pins PB05, PB07, PB08, PB09, and PB10.
Table 6.2 in the SAMA5D2 datasheet indicates that those pins can be multiplexed for QSPI1 with I/O set 2.

Your boot configuration does not match the hardware being used, i.e. wrong controller and wrong I/O set.

Regards
enricoPalazzo
Posts: 7
Joined: Mon Jun 10, 2019 12:58 pm

Re: SAMA5D27-SOM1 Bare Metal Application Boot Problem

Wed Jun 26, 2019 1:24 pm

Thank you for the explanation, Blue_z.

It also appears I have repeated a mistake made earlier (Ref: viewtopic.php?t=26516). I inadvertently reconfigured the JTAG interface to default values by using writecfg:bureg0.

$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a bootconfig -c writecfg:bureg0:ext_mem_boot,sdmmc1_disabled,sdmmc0_disabled,nfc_disabled,spi1_disabled,spi0_disabled,qspi1_disabled,qspi0_ioset3
Opening J-Link with S/N '483029745'
...
Setting BUREG0 to 0x00040ffe (QSPI0_IOSET3,QSPI1_DISABLED,SPI0_DISABLED,SPI1_DISABLED,NFC_DISABLED,SDMMC0_DISABLED,SDMMC1_DISABLED,UART1_IOSET1,JTAG_IOSET1,EXT_MEM_BOOT)
Connection closed.

Now the device is "Unsupported" as demonstrated when I tried SAM-BA again.

$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a qspiflash -c erase
Opening J-Link with S/N '483029745'
Error: Unsupported device

There did not appear to be a resolution for this in the earlier thread so I guess I bricked-it?
is there any way to avoid a repeat? Would have explicitly setting it to JTAG_IOSET3 in the same command avoided the reconfiguration?
enricoPalazzo
Posts: 7
Joined: Mon Jun 10, 2019 12:58 pm

Re: SAMA5D27-SOM1 Bare Metal Application Boot Problem

Wed Jun 26, 2019 3:18 pm

Crisis averted. I found you can use "-p serial:ttyACM(x)" option (as opposed to "-p jlink") to communicate as a serial port. Then I set JTAG_IOSET3 and "jlink" works again.

Is there a concise reference to determine the addresses where the binaries are expected? For example, the at91bootstrap "sama5d27_som1_ekqspi_uboot_defconfig" has CONFIG_IMG_ADDRESS = "0x00040000" and CONFIG_JUMP_ADDRESS="0x23f00000". That "image" the location appears to be "ECC ROM" according to the datasheet memory map (Figure 8-1). Is that the location the bootstrap boot.bin is located before it is written and runs from 0x0? The "jump" address is in DDRAM. Is that where u-boot.bin is expected to run from? The u-boot.map file has "0x23f00000" as the location of ".text".

Thanks again for the help.
3F800000
Posts: 13
Joined: Wed Apr 25, 2018 6:36 pm

Re: SAMA5D27-SOM1 Bare Metal Application Boot Problem

Thu Jun 27, 2019 1:57 am

IIRC the bootstrap is flashed at offset 0, and u-boot.bin at 0x40000. The bootstrap is copied by the boot ROM to SRAM, which then runs and copies flash from 0x40000 to 0x23f00000 (DDRAM) and executes that.

I suspect the following command should reference 0x40000 rather than 0x8000.

$ ../../../sam-ba -p jlink -b SAMA5D27-SOM1 -a qspiflash -c write:u-boot.bin:0x8000
blue_z
Location: USA
Posts: 1988
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAMA5D27-SOM1 Bare Metal Application Boot Problem

Thu Jun 27, 2019 2:42 am

enricoPalazzo wrote: Is there a concise reference to determine the addresses where the binaries are expected?
Your question is ambiguous, and the "addresses" you mention can refer to several different address spaces.
Some of those numbers are nonvolatile storage addresses, e.g. an offset in a Flash device.
Other numbers are physical memory addresses in the SoC memory space.

enricoPalazzo wrote: For example, the at91bootstrap "sama5d27_som1_ekqspi_uboot_defconfig" has CONFIG_IMG_ADDRESS = "0x00040000" and CONFIG_JUMP_ADDRESS="0x23f00000".
CONFIG_IMG_ADDRESS = "0x00040000" is for an offset in a storage device.
CONFIG_JUMP_ADDRESS="0x23f00000" is for a physical memory address.
Both of these numbers (a source offset and a destination address) refer to the image (e.g. U-Boot or Linux kernel or standalone program) that AT91Bootstrap retrieves from storage and loads into memory.

enricoPalazzo wrote: That "image" the location appears to be "ECC ROM" according to the datasheet memory map (Figure 8-1). Is that the location the bootstrap boot.bin is located before it is written and runs from 0x0?
CONFIG_IMG_ADDRESS is a storage offset that is unrelated to the SoC memory space.
CONFIG_IMG_ADDRESS is the offset of the image that AT91Bootstrap retrieves from storage.
The image of AT91Bootstrap is typically written/stored at offset zero in a flash device. This is typically the only prescribed storage offset, and depends on the SoC and storage medium.

Your use of "before it is written" is confusing.
The AT91Bootstrap image is written to nonvolatile storage. That's what a SAM-BA command performs.
The AT91Bootstrap image is read from nonvolatile storage (by the SoC ROM boot program), and loaded into SRAM (memory that is integrated with the SoC).

enricoPalazzo wrote: The "jump" address is in DDRAM. Is that where u-boot.bin is expected to run from?
Yes.

Regards
enricoPalazzo
Posts: 7
Joined: Mon Jun 10, 2019 12:58 pm

Re: SAMA5D27-SOM1 Bare Metal Application Boot Problem

Thu Jun 27, 2019 10:54 pm

Thank you blue_z and 38F00000. Clarifying the difference between offset address in NVM vs. physical address in the SOM memory map helped a lot.

I used SAM-BA to burn the Softpack application binary at the CONFIG_IMG_ADDRESS in QSPI. Also changed the CONFIG_JUMP_ADDRESS to 0x20000000 (the typical start address of Softpack DDRAM binaries cstartup routine). Those changes allowed me to use the bootstrap to start the application directly (ie: without u-boot) as I have read others do.

Is it correct that provided the application begins with the cstartup routine (which restarts the processor with the application's requirements for initializing clocks, peripherals, etc.) it is unnecessary to compile bootstrap (and u-boot) with the same initialization as the application?

Would like to get u-boot running in the loop as well because I may need to download the application with TFTP while in development. I am not clear on how to modify the procedure bootstrap->u-boot->Linux to be instead bootstrap->u-boot->bare metal app. I will need to review u-boot documentation I expect.
blue_z
Location: USA
Posts: 1988
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAMA5D27-SOM1 Bare Metal Application Boot Problem

Fri Jun 28, 2019 4:16 am

enricoPalazzo wrote: Is it correct that provided the application begins with the cstartup routine (which restarts the processor with the application's requirements for initializing clocks, peripherals, etc.) it is unnecessary to compile bootstrap (and u-boot) with the same initialization as the application?
I'm not exactly sure what you mean by "cstartup routine"; this is not a microcontroller. Your description (which incorporates a processor restart) sounds bizarre and unworkable.

BTW the "bootstrap" you are probably referring to has an actual name.
These Atmel microprocessors use a multi-stage boot sequence, so be concise when referring to a "bootstrap".

You seem to have the boot and the initialization sequence out of order.
The ROM boot program only initializes the hardware necessary to perform its boot task, and then undoes that initialization prior to branching.
The AT91Bootstrap only initializes the hardware necessary to perform its boot task.
U-Boot can be configured to utilize a wide range of the hardware, e.g. Ethernet and USB, that may not be essential to the actual boot task.
The application would be the last program to start execution in this sequence.

However each (boot) program has rather specific and minimal expectations of what hardware has been previously initialized.
In general each program level initializes the hardware it uses even if that means reinitialization, with the exception being the hardware that is explicitly required to be already initialized, such as the DRAM controller and the clock(s) it requires (by AT91Bootstrap).
Hence your mention of "restart the processor" by the application is nonsensical.
So, no, that is not correct.

enricoPalazzo wrote: Would like to get u-boot running in the loop as well because I may need to download the application with TFTP while in development. I am not clear on how to modify the procedure bootstrap->u-boot->Linux to be instead bootstrap->u-boot->bare metal app. I will need to review u-boot documentation I expect.
Yes, TFTP can speed-up the compile-load-test cycle.
Environment variable bootcmd specifies the default command(s) for booting, e.g. load image(s) and execute.
The Linux kernel requires the bootz or bootm command to start execution, but a standalone program should be executed with the go command.

Regards
enricoPalazzo
Posts: 7
Joined: Mon Jun 10, 2019 12:58 pm

Re: SAMA5D27-SOM1 Bare Metal Application Boot Problem

Fri Jun 28, 2019 1:49 pm

By "cstartup routine", I was referring to the assembly program cstartup.S in the Microchip Softpack package. Each processor target (in my case, sama5d2) has assembly code to initialize the chip including a C function board_init() that calls other C functions to initialize clocks, DDRAM, and the MMU. cstartup.S then branches to the main() function. cstartup is located at 0x20000000 where I had at91bootstrap branch.

I take your point about "restarting the processor" as incorrect. My understanding is that cstartup.S would "re-initialize the processor" hardware with the state required by the application code when it runs after at91bootstrap. I missed the point about ROMBoot "undoing" the initialization prior to branching. How does it do that and do at91bootstrap (and should u-boot) do something similar?

Thanks again for the clarifications and instruction. I will review suggestions regarding U-Boot to start standalone programs.

Return to “SAMA5-based”

Who is online

Users browsing this forum: No registered users and 0 guests