SAM9X60 DDR2 SIP Boot Issue

[mikucukyilmaz]

Hello,
We are using SAM9X60D5M 64MB SIP. Our device stuck after the "Done to load image" message. We tried to boot by using SD Card and NAND Flash and they both stuck at the same point.

• We compiled buildroot with sam9x60ek_headless_defconfig.
• Changed AT91Bootstrap config to "sam9x60_ddr2_sip_ebsd_uboot_defconfig" with "CONFIG_RAM_64MB=y".
• U-Boot config is "sam9x60ek_mmc_defconfig"
  
  This is the output for the SD Card boot. We usually except
  <debug_uart> & U-Boot header after that point but nothing happens.

This is the output when we tried to boot from NAND Flash. We put debug messages starts with "->" to see if AT91Bootstrap stuck at some point but it runs through "JUMP_ADDR".

RomBOOT

 ba_offset = 0xb ...

Dump DDRAMC Registers:
@address: 0x0 0x4 0x8 0xc
0xffffe800: 0x10 0x300618 0xc00139 0x2223c339
0xffffe810: 0x2c81715 0x92382 0x33338 0x10000
0xffffe820: 0x16 0x50008 0x0 0x0
0xffffe830: 0x6 0x787907 0x0 0x0
0xffffe840: 0x0 0x0 0x0 0x0
0xffffe850: 0x0 0x0 0x0 0x2
0xffffe860: 0x11 0xffff0000 0xffff0000 0xffff0000
0xffffe870: 0xffff0000 0xffff0000 0xffff0000 0xffff0000
0xffffe880: 0xffff0000 0x0 0x0 0x2a00002
0xffffe890: 0x0 0x0 0x0 0x0
0xffffe8a0: 0x0 0x0 0x0 0x0
0xffffe8b0: 0x0 0x0 0x1 0x0
0xffffe8c0: 0x0 0x0 0x0 0x1
0xffffe8d0: 0x0 0x0 0x0 0x0
0xffffe8e0: 0x0 0x0 0x200e008 0x200
0xffffe8f0: 0x484d5044 0x44524320 0x0 0x325
0xffffe900: 0x0 0x0 0x4030404 0x0
0xffffe910: 0x1f1f 0x0 0x4b04b02 0x0
0xffffe920: 0x0 0x0 0xf00 0xe00
0xffffe930: 0x1000 0xf00 0x0 0x0
0xffffe940: 0x0 0x0 0x14 0x14
0xffffe950: 0x0 0x0 0x0 0x0


AT91Bootstrap 3.10.2-00016-g8dbcb0b-dirty (2021-02-18 21:32:25)

NAND: ONFI flash detected
NAND: Manufacturer ID: 0x2c Chip ID: 0xdc
NAND: Page Bytes: 4096, Spare Bytes: 224
NAND: ECC Correctability Bits: 8, ECC Sector Bytes: 512
NAND: Disable On-Die ECC
PMECC: version is: 0x102
PMECC: page_size: 4096, oob_size: 224, pmecc_cap: 8, sector_size: 512
NAND: Initialize PMECC params, cap: 8, sector: 512
NAND: Image: Copy 0xc0000 bytes from 0x40000 to 0x23f00000
NAND: Done to load image
->after load image done
->JUMP_ADDR

We also ordered D1G 128MB version of SAM9X60 to test. Do we missing a point?

[ehristev]

Hi,

This usually happens because the External RAM is corrupted. The DDR2 I mean.
This is a consequence of possible bad initialization of the external RAM controller.

Eugen

[ehristev]

Could you try an older version of the AT91Bootstrap, for example 3.9.3 ?
And let me know if you see any difference.
Thanks

[mikucukyilmaz]

I compiled at91bootstrap with version 3.9.3. Changed boot.bin with the new compiled at91bootstrap binary. Sadly cannot see any difference. You can see the output below.
In the sam-ba cli there are lowlevel and extram applets. In the preset table of sam-ba documentation W9751G6KB (DDR2 Ram used by SIP Module) is preset 16. When we try to run sam-ba command below we get an error status 15 but couldn't figure it out what is it.

PS D:\Projects\Tools\sam-ba_3.5> .\sam-ba.exe -p serial:COM11 -d sam9x60 -a lowlevel:0
Opening serial port 'COM11'
Connection opened.
Connection closed.

PS D:\Projects\Tools\sam-ba_3.5> .\sam-ba.exe -p serial:COM11 -d sam9x60 -a extram:16
Opening serial port 'COM11'
Connection opened.
D:/Projects/Tools/sam-ba_3.5/qml/SAMBA/Applet.qml:247: Error: Could not initialize applet (status: 15)
Connection closed.

RomBOOT

 ba_offset = 0xb ...

Dump DDRAMC Registers:
@address: 0x0 0x4 0x8 0xc
0xffffe800: 0x10 0x300618 0xd00139 0x2223c339
0xffffe810: 0x2c82927 0x92482 0x33338 0x10000
0xffffe820: 0x16 0x50008 0x0 0x0
0xffffe830: 0x6 0x787907 0x0 0x0
0xffffe840: 0x0 0x0 0x0 0x0
0xffffe850: 0x0 0x0 0x0 0x2
0xffffe860: 0x11 0xffff0000 0xffff0000 0xffff0000
0xffffe870: 0xffff0000 0xffff0000 0xffff0000 0xffff0000
0xffffe880: 0xffff0000 0x0 0x0 0x2a00002
0xffffe890: 0x0 0x0 0x0 0x0
0xffffe8a0: 0x0 0x0 0x0 0x0
0xffffe8b0: 0x0 0x0 0x1 0x0
0xffffe8c0: 0x0 0x0 0x0 0x1
0xffffe8d0: 0x0 0x0 0x0 0x0
0xffffe8e0: 0x0 0x0 0x200e008 0x200
0xffffe8f0: 0x484d5044 0x44524320 0x0 0x325
0xffffe900: 0x0 0x0 0x4030404 0x0
0xffffe910: 0x1f1f 0x0 0x4904a01 0x0
0xffffe920: 0x0 0x0 0xe00 0xf00
0xffffe930: 0xf00 0xf00 0x0 0x0
0xffffe940: 0x0 0x0 0x13 0x14
0xffffe950: 0x0 0x0 0x0 0x0


AT91Bootstrap 3.9.3 (Mon Feb 22 14:22:30 +03 2021)

SD/MMC: Image: Read file u-boot.bin to 0x23f00000
MMC: ADMA supported
mmc_verify_operating_condition
SDHC: Timeout waiting for command complete
SD: Card Capacity: High or Extended
sd card identified with CID = 0x3534453 0x4c313647 0x8061e80d 0xe0105ff
sdcard_identification success
SD: Specification Version 3.0X
SD/MMC: Done to load image

[ehristev]

Unfortunately I do not have a sam9x60 sip board at my disposal, but maybe @noglitch can help.

[mikucukyilmaz]

As i can see 64MB DDR2 timings&config added with commit 9ac634f on 3 December 2020. If I use the prebuilt SD Card image from linux4sam.com same thing also happens.
This is not the appropriate section but in u-boot-at91 we are using sam9x60ek_mmc config as I mentioned above. But I suspect that ram configuration sam9x60ek_mmc_defconfig not compatible with the 64MB SIP Module.
I changed to sections below for 64MB sip but didn't help.
In https://github.com/linux4sam/u-boot-at91/blob/master/include/configs/sam9x60ek.h
#define CONFIG_SYS_SDRAM_SIZE 0x10000000 /* 256 megs */
https://github.com/linux4sam/u-boot-at91/blob/master/configs/sam9x60ek_mmc_defconfig
CONFIG_NR_DRAM_BANKS=8 CONFIG_BOOTARGS="mem=256M console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait"

[ehristev]

In your case, U-boot does not even start, so, regardless of what configuration you have in u-boot, things are bad before it.
Because AT91Bootstrap initializes the external RAM, U-boot is agnostic of the external RAM, except it's size. U-boot will attempt to relocate it's code somewhere else during boot, but, in your case, you do not even get there. You should at least see the which comes before relocation

[mikucukyilmaz]

Sorry for my mistake I totally forget to switch the external clock source. It boots without a problem now.

[ehristev]

This is very interesting, that AT91bootstrap works up to that point without switching to the external clock.
I would expect that it would fail much sooner.
It is likely then, that the internal oscillator feeding the main clock is either imprecise, or at a different frequency that makes the external RAM controller confused.
Thank you for letting us know of your findings

[mikucukyilmaz]

I also expect it to fail sooner never thought about the clock configuration. This is an oscillator that I used is similar to evk one.
https://www.digikey.com/en/products/detail/microchip-technology/DSC1001CI5-024.0000/4835409
Also in the EVK board has an external oscillator as a clock source but that option comes disabled. So I didn't read it correctly and thought it was the right option :)