Mity CPU Platforms » MitySOM-335x (ARM Cortex-A8 Based Products)

It does look like SPI was not enabled in the new u-boot config. Checkout the differences in include/configs/mityarm35x.h between the new and old. This was done since u-boot doesn't need access to any spi devices so we left it up to linux to enable the device. You could enable the spi in the u-boot config and see if that helps.

Hey Jonathan,
Do I only need the "#define CONFIG_SPI"? I've tried that along with (from the original mityarm35x.h)
the following no luck:

/* SPI support */
#ifdef CONFIG_SPI
#define BOARD_LATE_INIT
#define CONFIG_OMAP3_SPI
#define CONFIG_MTD_DEVICE
#define CONFIG_SPI_FLASH
#define CONFIG_SPI_FLASH_STMICRO
#define CONFIG_CMD_SF
#define CONFIG_SF_DEFAULT_SPEED (10000000)
#define CONFIG_CMD_SPI
#endif

I'll have to keep digging.

Thanks,
John C.

It's possible or even probable that name of the pound defines changed in this version. You can check the Readme to see if they are listed otherwise might need to grep for them.

Also take notice that at the end of the config there is a include. Those may have some spi defines setup and just need to be enabled.

Hey Jonathan,
Looking at your release without any of my mods, serial NOR was removed (no sf commands.) Was there
anything specific as to why it was removed? When I enable the SPI, I do get the sf commands back but they
are unstable (There are a lot of differences between u-boots when it comes to SPI (CONFIG_AM335X vs.
CONFIG_AM33XX.) Has there been any testing of SPI on this latest u-boot for the 335x module?
Thanks,
John C.

No since booting from the spi nor on our SoMs doesn't work and I wasn't aware of anyone using the nor, I didn't look into getting it functioning in u-boot. Do you use the spi nor?

Looking at board/ti/am335x/board.c it looks like TI attaches their nor to the gpmc bus which might explain why the spi drivers in u-boot aren't fully functional.

We had originally set up to boot out of SPI NOR and on occasion do use that ability for
manufacturing testing. The biggest thing at this point is trying to resolve why we have
a SPI bus dependency on the old u-boot.

I think I found the problem. The memory address 0x481A0000 refers to McSPI1 and only spi0 is enabled in the u-boot.

In the following file in the enable_basic_clocks function:
arch/arm/cpu/armv7/am33xx/clock_am33xx.c

You should be able to copy the spi0 entry and change to spi1 to enable McSPI1 clock.

Thanks. Let me take a look and if it works.

I'm testing this change right now and am going to push a commit if it works.

Committed change.
http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=commit;h=bc7833792442421a60e74ef2dc871429b34448fe

Tested in u-boot.

U-Boot# md 0x481A0000
481a0000: 40300a0b 00000009 00000000 00000000    ..0@............
481a0010: 00000008 00000000 00000000 00000000    ................
481a0020: 00000000 00000000 00000000 00000000    ................
481a0030: 00000000 00000000 00000000 00000000    ................
481a0040: 00000000 00000000 00000000 00000000    ................
481a0050: 00000000 00000000 00000000 00000000    ................
481a0060: 00000000 00000000 00000000 00000000    ................
481a0070: 00000000 00000000 00000000 00000000    ................
481a0080: 00000000 00000000 00000000 00000000    ................
481a0090: 00000000 00000000 00000000 00000000    ................
481a00a0: 00000000 00000000 00000000 00000000    ................
481a00b0: 00000000 00000000 00000000 00000000    ................
481a00c0: 00000000 00000000 00000000 00000000    ................
481a00d0: 00000000 00000000 00000000 00000000    ................
481a00e0: 00000000 00000000 00000000 00000000    ................
481a00f0: 00000000 00000000 00000000 00000000    ................

Command previously caused a panic.

Following your lead and my hardware engineers suggestion we did a temporary check and set 0x44E00050
(CM_PER_SPI1_CLKCTRL Register)to a 0x2 (it was a zero) to enable the SPI1 clock. Our system came up
and is running. I'll try and fix this in my build. We did notice the sf command no longer crashes
the system, but still does not work.

Jonathan,
I checked with manufacturing and they do use the command in verification
of basic communication with the SPI flash. So would it be possible to get the
sf command into the main line again? My testing shows that with the definitions
for SPI, the basic functions are being called correctly. So maybe just a
clocking setup?
Thanks,
John C.

U-Boot# sf probe 0:0
SF: Unsupported flash IDs: manuf ff, jedec ffff, ext_jedec ffff
Failed to initialize SPI flash at 0:0
U-Boot# sf probe 1:0
SF: Unsupported flash IDs: manuf ff, jedec ffff, ext_jedec ffff
Failed to initialize SPI flash at 1:0
U-Boot#

Just pushed a fix for this.
http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=commit;h=82762ccda7286bcc7a72b51b087b3ad6742d8a5f

U-Boot SPL 2013.10-00040-g82762cc (Jul 09 2014 - 17:08:52)
MitySOM335x profile 1 - Model No: 3359-GX-226-RL Serial No: 124492
Old factory config found, configuring for 256 MB DDR2
Configuring for 256 MB DDR2 @ 266MHz
Critical Link AM335X Dev Kit -- NAND Page size = 2048k booting from dev 8
reading u-boot.img
reading u-boot.img

U-Boot 2013.10-00040-g82762cc (Jul 09 2014 - 17:08:52)

AM335X-GP rev 0
I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  Using 2k bch8 layout
ECC Mode = 2 lo = 56/0
256 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Net:   cpsw:1 is connected to cpsw.  Reconnecting to cpsw
cpsw
Hit any key to stop autoboot:  0

U-Boot# sf probe
SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
U-Boot# run mmc_load_uimage
reading uImage
3705432 bytes read in 391 ms (9 MiB/s)
U-Boot# sf update $kloadaddr 0 390000
3735552 bytes written, 0 bytes skipped in 68.391s, speed 55928 B/s
U-Boot# sf read $kloadaddr 0 390000
SF: 3735552 bytes @ 0x0 Read: OK

Hey Johnathan,
Testing out the new spi bus changes seem fine. I do have two quick questions:

1) The original code I wrote spit out the device ID as:
-------------------------
U-Boot# sf probe 0:0;
SF: Detected N25Q00AA with page size 64 KiB, total 128 MiB
-------------------------
The new code is:
U-Boot# sf probe 0:0;
SF: Detected N25Q1024 with page size 256 Bytes, erase size 4 KiB, total 128 MiB
SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR
-------------------------
Did they change the nomenclature of the CHIP Id's? I used a very specific one for
a Micron manufacturer ID 20h, Memory Type BAh, and Manufacturer Memory Capacity 21h (1Gb).

2) Where did they hide the boot countdown time? It used to be the CONFIG_BOOTDELAY define
in the mityarm335x.h file.

Thanks,
John C.

1) I'm not sure why its detecting it differently. Maybe the newer u-boot has a more specific driver for this chip?

Also from the README

                CONFIG_SPI_FLASH_BAR            Ban/Extended Addr Reg

                Define this option to use the Bank addr/Extended addr
                support on SPI flashes which has size > 16Mbytes.

2) Checkout the README file for information on most CONFIG_ defines. It looks like it still exists. And it appears that its being set in the ti_armv7_common.h config file. Its included in the ti_am335x_common.h config file which we include.

To override without an warning message simply put

#undef CONFIG_BOOTDELAY 
#define CONFIG_BOOTDELAY 0

I added the CONFIG_SPI_FLASH_BAR define to mityarm335x.h and the warning is goes away on the "sf probe" command.
I added the #UNDEF and then "#define CONFIG_BOOTDELAY 3" to mityarm335x.h, and this now works.
The "sf erase" command seems to take longer, but works on shorter erases, but seems to have an issue with one
of our old commands:
---------------------------------
U-Boot# sf probe 0:0;
SF: Detected N25Q1024 with page size 256 Bytes, erase size 4 KiB, total 128 MiB
U-Boot# sf erase 0 0x01000000
SF: 16777216 bytes @ 0x0 Erased: ERROR
---------------------------------
I will try it again without the CONFIG_SPI_FLASH_BAR define.

Just to clarify, the detection of the N25Q00AA flash was put in by me. I followed previous nomenclatures of
using the specific chip name. The new code using N25Q1024 seems like it is outputting a generic term/name,
and not a specific chip. I could change it in the u-boot, but I'm not sure if the intention is to use generic
names instead of specific.

Thanks.

It may be perfectly fine with the generic name then.

Try changing the spi clock speed and see if you get different results. I found with the nor on our SoM the erase seemed faster when run at 1Mhz but the write was much faster at 48Mhz. I currently have it default to 48Mhz. You can specify the speed in the sf probe command. Also you can use the sf update command to erase then write a new image. This seemed to work better than doing the erase then write seperately. Not sure why though.

I took out the CONFIG_SPI_FLASH_BAR define and it now seem to pass the long erase command.

-----------------------------------
U-Boot# sf probe 0:0
SF: Detected N25Q1024 with page size 256 Bytes, erase size 4 KiB, total 128 MiB
SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR
U-Boot# sf erase 0 0x01000000
SF: 16777216 bytes @ 0x0 Erased: OK
U-Boot#
-----------------------------------

I then put CONFIG_SPI_FLASH_BAR back in and slowed the clock to 1000000 and it worked:
-----------------------------------
U-Boot# sf probe 0:0
SF: Detected N25Q1024 with page size 256 Bytes, erase size 4 KiB, total 128 MiB
U-Boot# sf erase 0 0x01000000
SF: 16777216 bytes @ 0x0 Erased: OK
U-Boot#
-----------------------------------

Did you notice any time difference with the slower speed?

Also make sure your Nor chip supports 48Mhz on the spi bus.

Yes the Micron N25Q00AA does support the 48Mhz clock. The sf erase still seems longer
but I'll need to time it get get more specific. I did notice that the mityarm335x.h
file was missing "#define CONFIG_SPI" as I though it was needed for the sf command.

Pretty sure I found "#define CONFIG_SPI" in one of the ti_ config files that get included.

Ok,
I knew it had to be in there somewhere, was just a bit confused
as the original mityarm335x.h had a nice section in the file for all
that.
Thanks,
John C.

Yeah by using the ti_ 335x include files I was hoping to greatly simplify our config file. Hopefully it hasn't caused more confusion then it needed to.