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

Tom,

Could you include the full boot log of the working and the broken boots?

Actually 3 logs. The two sd card boot logs and the nand boot log with the new kernel.

Thanks for the reply- of course now the symptoms have changed. The bad boot now stops waiting for the file system partition. Although at least this gives me something to work with and track down I've attached the 3 logs in case you see anything obvious.

Thanks again for your help.

Tom

Looking at the logs here are a few things I see.

• On the sd card boots, you are still loading u-boot from the nand. This is okay as long as you know its happening and aren't lost when you try to update the u-boot on the sd card and it doesn't get loaded. This can be changed by changing the bootcfg pins.
  

  nand_spl_load_image: loading 4096 bytes from 100000 to 80800000
  

• Our default u-boot env bootcmd tries to configure the dvi chip on our devkit. It probably doesn't exist on your board. No harm is caused by this error.
  

  i2c_write: error waiting for addr ACK (status=0x116)
  Error writing the chip.
  i2c_write: error waiting for addr ACK (status=0x116)
  Error writing the chip.
  

• Kernel commandline. The only difference thats not related to nand vs mmc is the "noinitrd" option. Not sure if its needed or not.
  http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re52.html
  Bad Sd boot
  

  [    0.000000] Kernel command line: console=ttyO0,115200n8 video=da8xx:bpp=16 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait ip=none
  

  
  Good nand boot
  

  [    0.000000] Kernel command line: console=ttyO0,115200n8 root=ubi0:rootfs rw ubi.mtd=7,4096 noinitrd rootfstype=ubifs rootwait=1 ip=none
  

• The failed boot kernel never discovers the mmc0 device. This could be a pinmux error in the kernel or not setting up the mmc0 bus correctly.
  Good sd boot
  

  [    1.627563] mmc0: new high speed SDHC card at address 59b4
  [    1.736145] mmcblk0: mmc0:59b4 SDC   14.9 GiB
  [    1.843322]  mmcblk0: p1 p2 p3
  

• The mmc0 initialization was moved later in the boot process. In my experience when we did this the mmc0 boot broke.
  Good sd boot
  

  [    0.091857] baseboard_init [Alstom NVSP2]...
  [    0.093414]  omap_hsmmc.0: alias fck already exists
  

  
  Bad sd boot
  

  [    0.550048] baseboard_init_late [Alstom NVSP2]...
  [    0.550292]  omap_hsmmc.0: alias fck already exists
  

Tom, one more question: are you running this on a Critical Link Development Board or your own custom baseboard?

This is a custom board- I did move the init of mmc back to the early init stage as a test and the file system came up and booted successfully. So that was indeed the issue. Now I have another problem I need to solve. Our goal is to have this kernel run on both our old board and new board. The problem is the pin mux is different on the 2 boards with respect to the sd card. We have an FPGA that tells us the board type but that does not get initialized until later- which is why we moved the init of the mmc to be later so we could initialize it based on the board type. The mmc core scans in a deferred work_queue which is probably why it doesn't have enough time (or perhaps doesn't even get a chance to run) to find it again after it is initialized. I don't expect an answer for this- just a little background....I'll start digging in and see what I can do.

Thanks again for your help.
Tom

Actually I do have a question- do you have a pointer to documentation that tells me how to build an SD card image from scratch? I went looking for this at the beginning of this process and could not find anything.

Thanks again.

Tom,

We are working on a yocto filesystem release which allows you to build a new yocto based filesystem from source. Would you be interested in this?

Tom Tatakis wrote:

This is a custom board- I did move the init of mmc back to the early init stage as a test and the file system came up and booted successfully. So that was indeed the issue.

Okay thats good.

Now I have another problem I need to solve. Our goal is to have this kernel run on both our old board and new board. The problem is the pin mux is different on the 2 boards with respect to the sd card. We have an FPGA that tells us the board type but that does not get initialized until later- which is why we moved the init of the mmc to be later so we could initialize it based on the board type. The mmc core scans in a deferred work_queue which is probably why it doesn't have enough time (or perhaps doesn't even get a chance to run) to find it again after it is initialized. I don't expect an answer for this- just a little background....I'll start digging in and see what I can do.

Looks like you've already made it a bit farther than I did when I was looking at it. I am very interested in what you find.