at91bootstrap running on custom sama5d36 board

[cajjed]

I have a custom sama5d36 board that is working fine. I would like to update the 1st stage bootloader to get the external oscillator for the RTC to work. Currently when I build a new board I put an existing nand_header_boot.bin (comes from a very old bootstrap version) file into mtd0 with the following commands from an SD card that I boot:

Code: Select all

flash_erase /dev/mtd0 0 0
nandwrite -p /dev/mtd0 nand_header_boot.bin

I built the sama5d3_xplained-nandflashboot--3.8.11.bin.pmecc from the at91bootstrap GitHub and tried the same commands to load it but all I get is RomBOOT. I have validated that I have the same pmec/nand_header for both files so I assumed that I would at least see something even if I had some configuration errors. I have tried tweaking some of the configuration settings but no change. I would try sam-ba but all I have is a debug port. The at91bootstrap site (https://www.at91.com/linux4sam/bin/view ... 1Bootstrap) does recommend trying it via uboot which I have not tried yet because I assume it is doing the same thing as my code above.

Any insight on how I can get the newest at91bootstrap to work on my custom board?

[blue_z]

I would like to update the 1st stage bootloader ...

According to the SoC datasheet:

The ROM code is a boot program contained in the embedded ROM. It is also called “First level bootloader”.

You cannot modify this "1st stage bootloader" because it is in ROM.

... but all I get is RomBOOT.

You need to thoroughly investigate this failure mode to gather salient details.
What happens when you type V# after the RomBOOT string appears after a reset?
See this topic.

Additionally you need to perform a sanity test by erasing the first block of NAND to confirm that the SAM-BA Monitor does get executed after a reset.
If you can't get a response to V# and wFFFFFE54,# commands, then you have additional issues.

I have validated that I have the same pmec/nand_header for both files so I assumed that I would at least see something ...
...
> ... because I assume it is doing the same thing as my code above.

Instead of making assumptions, you need to confirm that the PMECC header, AT91Bootstrap, U-Boot, and the Linux kernel are individually configured with the exact same NAND and PMECC parameters for the specific NAND flash chip in use.

Regards

[cajjed]

Thank you blue_z, the response is very insightful. What I meant to write is that I wanted to modify the 2nd stage bootloader.

The post you linked was very helpful also, I got the same response from the command:

Code: Select all

RomBOOT

v2.1 Oct 19 2012 17:38:58
>
0x00000000
>

So this board can only be booted from SD card, in other words by using boot.bin from uboot? This would make since since the nand_header_boot.bin file is actually just a cat of the nand_header and boot.bin.

Code: Select all

RomBOOT

U-Boot SPL 2014.07 (Oct 12 2018 - 12:56:12)
Board Revision: R2
Increase core voltage from 1.2V to 1.25V

So is there a way to modify things so I can use at91bootstrap or should I just stick with uboot?

[cajjed]

I did find in the datasheet (Section 11.5.1) the command list and I do see that the "word" I read (0xFFFFFE54) is the BSC_CR register which is set to 0, indicating that I can boot from any mode (Section 11.4.1). However, how to you set it so that it will boot using the AT91bootparams binary file rather than boot.bin from uboot?

[blue_z]

I got the same response from the command:
...

You need to be more precise.
Is this response when trying to boot AT91Bootstrap from NAND, or when NAND is erased, or some other condition?

So this board can only be booted from SD card, in other words by using boot.bin from uboot?

No. What??!!

Code: Select all

RomBOOT

U-Boot SPL 2014.07 (Oct 12 2018 - 12:56:12)
Board Revision: R2
Increase core voltage from 1.2V to 1.25V

What is this?

However, how to you set it so that it will boot using the AT91bootparams binary file rather than boot.bin from uboot?

"AT91bootparams binary file"???
"boot.bin from uboot"???

[cajjed]

As always, your help is appreciated...

The response I got was the same response as received in the link you provided. In the provided link I interpreted the response as meaning that the only option was an SD card boot. After reading the datasheet, I realized the error in my statement. I only get a command (V#) response when NAND is erased.

The uboot information is what I get when I nandwrite into /dev/mtd0 boot.bin from 2014 version of uboot. That is what I currently use to boot from nand flash.

What I want to do is use at91bootparams instead of uboot in /dev/mtd0. I have tried building my own custom at91bootparams, but have not had success as of yet getting it to boot.

[cajjed]

I apologize for my vagueness, as always I have learned much during this interaction and it has been very helpful for me. However, as a result much of what I posted was erroneous. Let me start from the beginning and see if I can clarify. My current custom sama5d36 board is set up as follows using nand flash:

RomBOOT -> U-boot (boot.bin) -> U-boot (u-boot.bin) -> Linux

So in order to program nand flash I boot my board from an SD card, I then erase the nand flash and write the code to the appropriate MTD (Memory Technology Device) partitions:

Code: Select all

flash_erase /dev/mtd0 0 0
flash_erase /dev/mtd1 0 0

...

nandwrite -p /dev/mtd0 nand_header_boot.bin
nandwrite -p /dev/mtd1 u-boot.bin

...

To create these files the manufacturer of the board has provided a 2014 version of Uboot that creates the boot.bin and u-boot.bin files. My goal was to update to a newer version, not realizing at first that my second stage bootloader was uboot and not AT91Bootstrap (https://github.com/linux4sam/at91bootstrap). I am in the process of creating a custom board configuration in AT91Bootstrap that I can get running on my board. If my partition that holds the second stage bootloader (/dev/mtd0) is erased then I can use the SAM-BA monitor commands (See section 11.5.1 of the datasheet):

Code: Select all

RomBOOT

V# (command does not get echoed)
v2.1 Oct 19 2012 17:38:58
wFFFFFE54,# (command does not get echoed)
>
0x00000000
>

This command tells me that my boot value (section 11.4.1 of the datasheet) is 0 and thus setup to boot in any available mode (SD card, nand flash, etc.).

Currently when I attempt to load my AT91Bootstrap binary I get no response after RomBoot and can't get response to my commands. Thus, my assumption is that I haven't gotten my contributed driver code and configuration options correct yet. So that is my current challenge, insight as always is appreciated.

Hopefully, this answers your questions. at91bootparams was just a mistake, I meant AT91Bootstrap.

Also, thanks for the information about U-boot SPL vs AT91Bootstrap. I will have to explore a newer version of U-boot and see how it works.

[blue_z]

As a first step I would try to simply build AT91Bootstrap, and then try to boot it from SDcard rather than NAND flash.
You can use the same AT91Bootstrap configured for NAND boot, but install the boot.bin binary file (from the binaries directory) to a FAT partition on SDcard.
This is a simpler boot test that removes all the NAND and PMECC unknowns from the boot problem.
The goal is simply to see if you can build a AT91Bootstrap that executes on your board.

Erase the first block of NAND flash prior to this test of SDcard booting.
If the AT91Bootstrap produces no output when booted, then test for a response from SAM-BA Monitor by entering a V# command.

What toolchain are you using to build AT91Bootstrap?

Regards

[cajjed]

I like your suggestion, much faster method of testing the at91bootstrap build. So far all the different configuration/code hack options I have tried by replacing the SD card boot.bin result in just RomBOOT response and I can not get any response from V#. I know that my clock uses a 24 MHz crystal instead of the 12 MHz that the xplained board uses. I have tried to change that in code but probably don't have it correct yet. Is there a minimalist build, almost like a hello world, that removes most of the options so I can just focus on getting any kind of initial response?

And I am using gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf...

[blue_z]

I know that my clock uses a 24 MHz crystal instead of the 12 MHz that the xplained board uses. I have tried to change that in code but probably don't have it correct yet.

Yes, reveal salient information at your leisurely convenience.
Then I can also advise you to perform tasks guaranteed to fail because of these unknown differences.
It's so much more fun and challenging to work with as little information as possible.

Is there a minimalist build, almost like a hello world, that removes most of the options so I can just focus on getting any kind of initial response?

There's the SoftPack, but IMO it would be an unnecessary detour.
AT91Bootstrap can be configured to remove selected code, and/or main.c and your board file for hw_init() (do you have a custom directory under board/ for your board?) can be temporarily hacked with #if 0 ... #endif blocks.
Until you have a complete list of fundamental HW differences between your board and Atmel reference boards and the necessary code changes, do not "assume that [you] would at least see something even if [you] had some configuration errors."

AT91Bootstrap cannot produce visible output from display_banner() until hw_init() has successfully been performed.
There may be superfluous code such as one_wire_hw_init() and HDMI_Qt1070_workaround() that needs to be removed, but all of the clock/PLL and PIO configurations must be accurate for your board.
The configuration & source code for the U-Boot SPL could be one resource for such information.

And I am using gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf...

That is an officially-tested toolchain, and it does build a working binary for a NAND boot but test loaded from SDcard:

Code: Select all

RomBOOT


AT91Bootstrap 3.8.11 (Thu Oct 18 xx:xx:xx xDT 2018)

1-Wire: Loading 1-Wire information ...
1-Wire: ROM Searching ... Done, 3 1-Wire chips found

1-Wire: BoardName | [Revid] | VendorName
  #0  SAMA5D36-CM [EE5]      FLEX
  #1  SAMA5D3x-MB [CC3]      FLEX
  #2  SAMA5D3x-DM [BB2]      FLEX

1-Wire: Board sn: 0x481244e revision: 0x6a8824

NAND: ONFI flash detected
NAND: Manufacturer ID: 0x2c Chip ID: 0xda
NAND: Page Bytes: 2048, Spare Bytes: 64
NAND: ECC Correctability Bits: 4, ECC Sector Bytes: 512
NAND: Disable On-Die ECC
NAND: Initialize PMECC params, cap: 4, sector: 512
NAND: Image: Copy 0xa0000 bytes from 0x40000 to 0x26f00000
NAND: Done to load image
<debug_uart> 
...

[cajjed]

Thanks again for the information, as I learn I share. Initial I had made the false assumption that down at the at91bootstrap level the settings for the sama5d3_xplained would be the same as my custom board. That is clearly not the case and so, as you suggested, I am currently diving into the old U-boot code to try and determine the proper code configuration options. I like your suggestion of editing out code that is not needed to just get up and started.

And I have created a board configuration under contrib that I copied from an existing sama5d3 board.

[cajjed]

So I wanted to just validate that I had basic ability to communicate with my board using at91bootstrap. Since I couldn't get a "hello world" type program to work I decided to just try pulling a pin down, since by default it is input pull-up and thus shows high.

Code: Select all

static void at91_test_pin_init(void)
{
	/* Configure test pins */
	const struct pio_desc test_pins[] = {
		{"TST1", AT91C_PIN_PB(14), 0, PIO_DEFAULT, PIO_OUTPUT},
		{"TST2", AT91C_PIN_PB(15), 0, PIO_DEFAULT, PIO_OUTPUT},
		{(char *)0, 0, 0, PIO_DEFAULT, PIO_PERIPH_A},
	};
	
	/*  Configure the test pins */
	pmc_enable_periph_clock(AT91C_ID_PIOB);
	pio_configure(test_pins);
}

If you just take the sama5d3_xplain example and make your own board in contrib (as explained in the at91bootstrap README) then just put at91_test_pin_init() as the first thing in hw_init() in the .c file. Now I know that my boot.bin on my SD card is running and I can use the test pins to help me locate my problem, at least that is the plan.