Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Your u-boot and kernel partitions don't seem to match. Also asuming the u-boot partitions scheme is the correct one, if you intend to boot from your "rootfs" partition in linux you should change mtdblock0 to mtdblock1 after fixing the linux partitioning. The nand partitions are setup here: http://wanda/git/?p=linux-davinci.git;a=blob;f=arch/arm/mach-davinci/board-mityomapl138.c;h=c98144005f84983dc3d14600f1bc394553382230;hb=refs/heads/mitydsp-linux-v3.2#l379

or you can try to figure out why your mtdparts bootarg didn't work. https://www.denx.de/wiki/DULG/BootTimeConfigurationOfMTDPartitions

U-Boot > mtdparts
device nand0 <nand>, # parts = 3
 #: name                size            offset          mask_flags
 0: userfs              0x00e00000      0x00000000      0
 1: rootfs              0x08000000      0x00e00000      0
 2: unused              0x17200000      0x08e00000      0

Creating 2 MTD partitions on "davinci_nand.1":
0x000000000000-0x000008000000 : "rootfs" 
0x000008000000-0x000020000000 : "homefs" 

Hi Jonathan,

Your u-boot and kernel partitions don't seem to match.

I changed the file board-mityomapl138.c and rebuilt the kernel. The kernel gets the partitions right this time around.

or you can try to figure out why your mtdparts bootarg didn't work

My CONFIG_MTD_CMDLINE_PARTS kernel configuration option was already on, so why the kernel ignored my bootarg is beyond me.

My boot log is attached below.

Thanks again,
Okan

MityOMAPL138: Read Factory Config Failed: -110

This line is very concerning. It appears you have erased or corrupted the modules factory config which is likely causing the kernel to think it has the wrong nand device.

You can reconfigure the factoryconfig in u-boot. Make sure you use the modules serial number, part number, fpga type, and mac address. They should be on the barcode on the module.

U-Boot > factoryconfig set
MAC Address  : 00:50:C2:E6:70:B5
Serial Number :111209
Part Number   :L138-DG-225-RI
FPGA Type     :2
U-Boot > factoryconfig save
I2C Factory Configuration Block Saved
Configuration Saved

If you can tell me what those are as well it might help.

But this is our custom board. What should I enter in those fields?

Okan Çalış wrote:

But this is our custom board. What should I enter in those fields?

This is the factory config for the SOM. It has to be set to the values from the barcode on the SOM.

Turns out that the custom board doesn't even have a factoryconfig command. The two boards appear to have different versions of U-Boot installed.

In the Critical Link's board, I get:

OMAP-L138/AM-1808/AM-1810 initialization passed!
Configuring 256MB mDDR
                      Booting TI User Boot Loader
        UBL Version: 1.65:2.28.1 BuiltJul 11 2011 12:49:53
        UBL Flashtype: SPI
Starting SPI Memory Copy...
Valid magicnum, 0x55424CBB, found at offset 0x00010000.
   DONE
Jumping to entry point at 0xC1080000.

U-Boot 2009.11 (Jan 13 2014 - 11:14:02)

I2C:   ready
DRAM:  128 MB
NAND:  512 MiB
MMC:   davinci: 0
In:    serial
Out:   serial
Err:   serial
Error - Checksum on MityDSP-L138 Config Block Checksum Invalid
You must set the config to FLASH to make permanent
ARM    Clock : 300000000 Hz
DDR    Clock : 150000000 Hz
EMIFA  CLock : 100000000 Hz
DSP    Clock : 300000000 Hz
ASYNC3 Clock : 150000000 Hz
Enet  config : 2
MMC 0 Enable : 0
Resetting ethernet phy
Net:   Ethernet PHY: GENERIC @ 0x03 [0x8]

Hit any key to stop autoboot:  0
U-Boot > print ver
ver=U-Boot 2009.11 (Jan 13 2014 - 11:14:02)
U-Boot > factoryconfig
Factory Configuration:
Config Version : 1.1
MAC Address    : 70:B3:D5:B5:1D:93
Serial Number  : 15013848
FPGA Type      : 4 [XC6SLX45]
Part Number    : L138-FI-236-RL

On the other hand, on our custom board, I get:

OMAP-L138 LCDK initialization passed!
Booting TI User Boot Loader
        UBL Version: 1.65
        UBL Flashtype: NAND
Starting NAND Copy...
Valid magicnum, 0x55424CBB, found in block 0x00000006.
   DONE
Jumping to entry point at 0xC1080000.
NAND:  512 MiB
MMC:   davinci: 0
In:    serial
Out:   serial
Err:   serial
Net:   DaVinci-EMAC
Hit any key to stop autoboot:  0 
Using DaVinci-EMAC device
host 10.10.27.45 is alive
U-Boot > print ver
ver=U-Boot 2017.05-rc1-00044-gc3b7cfe-dirty (Apr 08 2017 - 20:35:07 +0300)
U-Boot > factoryconfig
Unknown command 'factoryconfig' - try 'help'

I remember my colleagues had to rebuild U-Boot for the custom board so that it could work with the hardware differences (such as different PHY identity, and different UART port).

This is the factory config for the SOM. It has to be set to the values from the barcode on the SOM.

I still don't get why I should enter the values from the SoM's barcode into the custom board's U-Boot, by the way. Moreover, the factoryconfig of the industrial IO board doesn't match anything on its barcode anyway.

Is your custom board using a MityDSP-L138, or have you designed a custom board using the OMAP-L138 and not the module?

If you have done a custom carrier card and are still using a MityDSP-L138, then there are multiple things going on here.

Everything related to factory config as well as the UBL relate to the MODULE, not the CARRIER CARD. There is a sticker on the back side of the module that provides a module serial number, part number (which indicates the amount of RAM and NAND installed on the module), as well as an ethernet MAC address which may be used for network drivers.

The boot process for the OMAPL138 has multiple stages:

1. ROM bootloader. For the MityDSP-L138, this will load the UBL into internal SRAM from SPI NOR.
2. User Boot Loader (UBL). This reads the factory configuration data from a local I2C PROM on the module to determine the memory option / size, sets up the local power supply core voltages via a local PMIC and configures the DDR. Then it loads u-Boot from SPI NOR into DDR. That is what is printing out the "Configuring 256MB mDDR" message.
3. U-Boot. This allows accessing different boot media to load the kernel / filesystem, etc.
4. OS

This is also covered on this wiki page.

Critical Link provides (at factory and in the MDK) a custom UBL to properly configure the DDR (on the module) based on the factory configuration data. It looks like you are using the LCDK UBL. I am amazed that the DDR is working at all. The configuration of the LCDK hardware from TI may not match the MityDSP-L138 module at all, and may be setup for the wrong amount of DDR, etc. You need to use the UBL supplied by Critical Link to ensure proper operation of the module DDR. I think you need to sort that out, or ensure that the DDR configuration settings match what we need for the module in your copy of the UBL.

If you want to customize U-Boot, that is OK, but you if you don't use the variant from our git repository you won't have the commands to adjust / view the factory configuration data in the local I2C prom, and if you are using the kernel from our support site there may be issues handing off some of the pin-mux configuration. However, if you are using the kernel from the LCDK, this is probably OK as that kernel doesn't use these fields.

-Mike

U-Boot > print ver
ver=U-Boot 2017.05-rc1-00044-gc3b7cfe-dirty (Apr 08 2017 - 20:35:07 +0300)

This is definitely not a version of u-boot that we support. Which could explain all the ECC errors you get in the kernel when you try to read from nand. If this u-boot you are using is not configuring the ECC for the nand to match the ECC the kernel is using then it won't work.

Hi,

I couldn't reply sooner because I've been handling some other kernel-related problems by using NFS as a temporary solution.

The custom board is rather similar to Critical Link's MityDsp-L138F in terms of included peripherals etc, but it doesn't contain the SoM itself. Sorry if I misled you.

The Ångström kernel v.3.2 supplied by Critical Link works fine on our custom board while exporting it and the filesystem through NFS; however, if I try booting it from the NAND flash, I get the aforementioned ECC errors. Should I have used TI's Linux kernel instead?

They provide a Linux kernel within the Multi-Core Software Development Kit (MCSDK), which is called Linux PSP 3.3 and contains the Arago kernel. I don't quite understand the difference between Ångström and Arago; are those utterly different distributions of Linux, or is either of them the subset of the other?

Thanks again,
Okan

Okan Çalış wrote:

Hi,

I couldn't reply sooner because I've been handling some other kernel-related problems by using NFS as a temporary solution.

The custom board is rather similar to Critical Link's MityDsp-L138F in terms of included peripherals etc, but it doesn't contain the SoM itself. Sorry if I misled you.

The Ångström kernel v.3.2 supplied by Critical Link works fine on our custom board while exporting it and the filesystem through NFS; however, if I try booting it from the NAND flash, I get the aforementioned ECC errors. Should I have used TI's Linux kernel instead?

The kernel and u-boot both have to use the same ECC strength. You can possibly use our kernel if you can figure out how to configure the nand correctly but I don't think we can be of much help here.

They provide a Linux kernel within the Multi-Core Software Development Kit (MCSDK), which is called Linux PSP 3.3 and contains the Arago kernel. I don't quite understand the difference between Ångström and Arago; are those utterly different distributions of Linux, or is either of them the subset of the other?

https://www.yoctoproject.org/product/angstrom-distribution
http://arago-project.org/wiki/index.php/Main_Page
Its a bit tricky, both are distributions created by or for TI processors. If I understand it correctly Arago used to use Angstrom but has moved to using Yocto now. Again its unclear.

Hi Jonathan, thanks for your reply.

The kernel and u-boot both have to use the same ECC strength.

I'm afraid I have no idea what an ECC strength is. I've read this documentation, but I can't say it made anything clear.

You can possibly use our kernel if you can figure out how to configure the nand correctly but I don't think we can be of much help here.

• da850_lcdk
• da850_omapl138
• tisdk_omapl138-lcdk
• da8xx_omapl
• ...

Which one am I supposed to choose? Also, there is a "Critical Link Industrial IO board" option in the System Type menu; should it be selected?
(I've never built a kernel for a custom board before.)

The U-Boot on the custom board was compiled by my colleagues who had been working on this board before I started. They must have modified the U-Boot version for the LCDK, so that the U-Boot would work despite different UART and Ethernet configuration. But I can't select LCDK because when I do, there are lots of irrelevant settings in the board configuration file, such as LED pins.

With your version of Linux kernel, I exactly know how to modify the necessary configurations, and the result works on the custom board through NFS. I just don't know how to do those things without knowing which default to start from.

What would you suggest?
Okan

Okan Çalış wrote:

Hi Jonathan, thanks for your reply.

The kernel and u-boot both have to use the same ECC strength.

I'm afraid I have no idea what an ECC strength is. I've read this documentation, but I can't say it made anything clear.

I suggest you do some research into nand and ECC. This might be a good starting place.
http://www.linux-mtd.infradead.org/doc/nand.html

You can possibly use our kernel if you can figure out how to configure the nand correctly but I don't think we can be of much help here.

As you must have noticed, I'm a newby on this area, so I'm quite confused and don't know how I should proceed. I tried rebuilding a kernel for OMAP-L138 by using TI's MCSDK, but there are too many options:

• da850_lcdk
• da850_omapl138
• tisdk_omapl138-lcdk
• da8xx_omapl
• ...

We are not familiar with the TI MCSDK. We provide our own SDK for our SOMs.

Which one am I supposed to choose? Also, there is a "Critical Link Industrial IO board" option in the System Type menu; should it be selected?
(I've never built a kernel for a custom board before.)

If you were using our board then selecting that option would work.

The U-Boot on the custom board was compiled by my colleagues who had been working on this board before I started. They must have modified the U-Boot version for the LCDK, so that the U-Boot would work despite different UART and Ethernet configuration. But I can't select LCDK because when I do, there are lots of irrelevant settings in the board configuration file, such as LED pins.

With your version of Linux kernel, I exactly know how to modify the necessary configurations, and the result works on the custom board through NFS. I just don't know how to do those things without knowing which default to start from.

Since we know very little about your custom board and since it's not using our SOM. It makes it very hard to help. I suggest that if you want Critical Link to provide further assistance to get the nand working on your custom board then contact the services sales team and we can work out a small service contract.
https://www.criticallink.com/contact/

Hi,

I solved this problem by writing the JFFS2 image to the NAND partition via the MTD Utilities in Linux, instead of U-Boot. Now, I can boot up Linux properly with the file system.

Thanks for your help.