SAMA5D27-SOM1 not booting from SDCard ?

[Niino]

Hello,

I have a custom board with the SAMA5D27-SOM1 mounted, the schematic is a lot based on the kit (SAMA5D27-SOM1-EK), with less peripherals.

According to the documentation, I understood that the SOM, by default, starts up with ROMBoot, then tries to boot from SDMMC1 followed by SDMMC0 and if none of these twos is bootable it launches the SAM-BA monitor. Am I understanding this right, is this som following the MRL C Parts Booting procedures ?

Where is the ROMBoot code saved? Within the chip or on the embedded QSPI flash ?

I then tried to use SAM-BA with a j-link through jtag, and I keep getting the same error:

Error: Unspported device

After searching in the source code of SAM-BA this error can occur from 2 situations:
1) J-Link cant find the proper core

2) It can't find the core ID

So i'm not sure if the SOM is just broken after a bad manipulation, or if I'm missing something, if you need more info don't be afraid to ask!

Thanks in advance,
Regards

[blue_z]

I have a custom board with the SAMA5D27-SOM1 mounted,
...
So i'm not sure if the SOM is just broken after a bad manipulation,

Anything is possible, but that's not the most probable.
Instead your custom board should be suspect for every issue that you mention, since you neglect to mention any other testing besides these failures.

According to the documentation, I understood that the SOM, by default, starts up with ROMBoot, then tries to boot from SDMMC1 followed by SDMMC0 and if none of these twos is bootable it launches the SAM-BA monitor. Am I understanding this right, is this som following the MRL C Parts Booting procedures ?

That's the default behavior, assuming that the BSC_CR is zero.

Where is the ROMBoot code saved? Within the chip or on the embedded QSPI flash ?

The SoC datasheet clearly states in the second line of section 16 that "the ROM code is a boot program contained in the embedded ROM."
Flash memory, by its very definition (i.e. it's erasable and writable) is not ROM.

... or if I'm missing something,

What basic tests (e.g. with an oscilloscope) have you performed on your custom board?
Have you checked for output (i.e. the "RomBOOT" text) on the DBGU port (the console defaults to UART1 IOSet1)?

Regards

[Niino]

Hello blue_z, thanks for your answer.

What basic tests (e.g. with an oscilloscope) have you performed on your custom board?

I forgot to mention some of the tests indeed, my bad. I mainly tested Alimentations in global, and if there was activity on different pins of the SD Card, there was one "weird", in my knowledge, behaviour on the SD CLK it's sometimes going from 3.3V to 0V then 1.8V and then 3.3V again. I now did the same measurement on the Evaluation kit and the result was the same. So i guess it's normal.

Have you checked for output (i.e. the "RomBOOT" text) on the DBGU port (the console defaults to UART1 IOSet1)?

Thanks for this info, seems like I missed the DBGU port part. The RomBOOT text is showing up. If I add an SD Card it starts the AT91Bootstrap and then gets stuck. (This SD Card works perfectly fine on the EK).

AT91Bootstrap log:

AT91Bootstrap 3.8.10-00017-gadeb745 (Die Jun 12 14:18:28 CEST 2018)

SD/MMC: Image: Read file u-boot.bin to 0x23f00000
SD: Card Capacity: High or Extended
SD: Specification Version 3.0X
SDHC: Error detected in status
SDHC: Error detected in status
SDHC: Error detected in status
SDHC: Error detected in status
SDHC: Error detected in status
SDHC: Error detected in status
SDHC: Error detected in status
SD/MMC: Done to load image

I did the same test by changing the boot.bin with an AT91Bootstrap with max log level, this is the output:

RomBOOT
ba_offset = 0xb ...

Dump DDRAMC Registers:
@address: 0x0 0x4 0x8 0xc
0xf000c000: 0x10 0x300511 0xd00139 0x22239337
0xf000c010: 0x2c81716 0x82482 0x33338 0x10000
0xf000c020: 0x16 0x50008 0x0 0x0
0xf000c030: 0x6 0xf6504 0x0 0x0
0xf000c040: 0x0 0x0 0x0 0x0
0xf000c050: 0x0 0x0 0x0 0x1
0xf000c060: 0x0 0x0 0x0 0x0
0xf000c070: 0x0 0x0 0x0 0x0
0xf000c080: 0x0 0x0 0x0 0x0
0xf000c090: 0x0 0x0 0x0 0x0
0xf000c0a0: 0x0 0x0 0x0 0x0
0xf000c0b0: 0x0 0x0 0x1 0x0
0xf000c0c0: 0x0 0x0 0x0 0x0
0xf000c0d0: 0x0 0x0 0x0 0x0
0xf000c0e0: 0x0 0x0 0x0 0x4000
0xf000c0f0: 0x484d5044 0x44524320 0x0 0x20301
0xf000c100: 0x0 0x0 0x4040404 0x3030303
0xf000c110: 0x0 0x1 0x4004102 0x0
0xf000c120: 0x0 0x0 0xc00 0xc00
0xf000c130: 0xc00 0xc00 0xd00 0xd00
0xf000c140: 0xd00 0xd00 0x10 0x10
0xf000c150: 0x10 0x10 0xf 0x0


AT91Bootstrap 3.8.10-00017-gadeb745 (Don Jun 14 11:32:21 CEST 2018)

All interrupts redirected to AIC
SD/MMC: Image: Read file u-boot.bin to 0x23f00000
SD: Card Capacity: High or Extended
SD: Specification Version 3.0X
SDHC: Error detected in status
SDHC: Error detected in status
SDHC: Error detected in status
SDHC: Error detected in status
SD/MMC: Done to load image

Regards

[blue_z]

Looks like you need to update to the very latest version of AT91Bootstrap from github, as there was a commit dated 6 days ago for SDcard that was applied last night.
At the very least the console output will be more informative. Instead of just "SDHC: Error detected in status", the normal and error status values will be reported.

Regards

[Niino]

Thanks a lot for your help ! We found the issue, it was in the routing of the SD card signals, they had too much length diffrencies.

The JTAG issue is not yet fixed, but we couldn't investigate a lot more but it isn't a problem for now.

Regards

[iguffick]

The default fuse configuration does not enable JTAG.
To enable JTAG you'll need to use Sam-ba to set the FUSE or BUREG (using the UART or USB).
Once enabled with Sam-ba, reset and try to connect with JTAG.
Make sure you don't boot anything else, or that may also disable the JTAG. You can use the boot disable if your boot memory contains a bootable program.

Regards,
Ian.