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

That is unexpected. Your boot log looks like everything is correct. It looks similar to if you had no sdcard plugged in at all. Even if you flashed the sdcard incorrectly, I would still expect to see the mmc show up.

Example of successfully probed sdcard

mmc0: new high speed SDHC card at address aaaa
mmcblk0: mmc0:aaaa SU04G 3.69 GiB 
 mmcblk0: p1

Based on your log, I'd say most likely either the sdcard is broken somehow or there is a hardware issue.

If this is a custom baseboard without the card detect hooked up. Then this could also happen.

For an example of disabling card detect and/or the read-only pin see baseboard_hfm.c:
baseboard_hfm.c:

static int baseboard_mmc_get_ro(int index)
{
    // Assume always rw
    return 0; 
}

static int baseboard_mmc_get_cd(int index)
{
    // Assume always present
    return true;
}

I use the standard devkit. When I had problems with the SD card (for example, bad partition), I got these messages:

** Bad partition 1 **
Wrong Image Format for bootm command
ERROR: can't get kernel image!

Vadym Kolesnyk wrote in RE: Discussion: Kernel hangs on "Waiting for root device ...:

I use the standard devkit. When I had problems with the SD card (for example, bad partition), I got these messages:
[...]
I get the same when the card is not connected at all.

Okay, so the above message is what you get if u-boot can't find the sdcard and/or the kernel image on the sdcard. According to your log, u-boot finds the sdcard and loads the kernel. Then when the kernel starts booting, it cannot find the sdcard. Have you modified the kernel?

Have you successfully booted this devkit before? If so what changed since then?

Sorry if I have described my problem not clearly. Yes, I booted this devkit successfully with my sd card before (about a month ago). Nobody except me worked with this devkit. The kernel is without any changes from my side. I use the default mityomap-full.tgz version from the MDK folder. Uboot also did not reconfigure in any way.

Today I've tried to set up another two SD cards to exclude possible card-relief problems. I did all strongly according to the wiki manual mentioned before. But still no effect.

I understand the only possible solution is to reset radically devkit somehow, but why this strange bug may have happened? There was no outside interference. The devkit just wasn't turned on for a month.

Thanks for the update.

Did you grab the mityomap-full.tgz file from MDK_2014-01-13? I just want to follow the same steps and make sure it still works on my end.

Did you grab the mityomap-full.tgz file from MDK_2014-01-13? I just want to follow the same steps and make sure it still works on my end.

Looking at your log, your kernel build date matches the 2014 MDK so I'm going to assume yes.

Can you md5sum the mityomap-full.tgz and make sure it matches "38903bff19adc905ca8a07f8c44bb5c6"?

I attached my boot log and the instructions I ran from the wiki for reference. I'm pretty sure you got the instructions correct otherwise u-boot wouldn't have been able to load the kernel image.

$ md5sum /home/tools/mitydsp-l138/MDK_2014-01-13/fs/mityomap-full.tgz 
38903bff19adc905ca8a07f8c44bb5c6  /home/tools/mitydsp-l138/MDK_2014-01-13/fs/mityomap-full.tgz

$ sudo mkfs.ext3 -L "rootfs" /dev/sdd1 
mke2fs 1.45.5 (07-Jan-2020)
/dev/sdd1 contains a vfat file system labelled 'boot'
Proceed anyway? (y,N) y
Creating filesystem with 1940224 4k blocks and 485760 inodes
Filesystem UUID: c60609c2-4475-4246-a75c-47784717f194
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done 

sudo mount /dev/sdd1 /mnt
cd /mnt
$ sudo tar xzvf /home/tools/mitydsp-l138/MDK_2014-01-13/fs/mityomap-full.tgz 
...
$ ll
total 80
drwxr-sr-x 18 root root  4096 Aug  9  2012 ./
drwxr-sr-x  1 root root   310 Oct 14 13:56 ../
drwxr-xr-x  2 root root  4096 Aug  9  2012 bin/
drwxr-sr-x  2 root root  4096 Aug  9  2012 boot/
drwxr-sr-x  3 root root  4096 Jun  6  2012 dev/
drwxr-xr-x 34 root root  4096 Aug  9  2012 etc/
drwxr-sr-x  3 root root  4096 Aug  9  2012 home/
drwxr-xr-x  6 root root  4096 Aug  9  2012 lib/
drwx------  2 root root 16384 Apr  3 15:56 lost+found/
drwxr-sr-x 10 root root  4096 Aug  9  2012 media/
drwxr-sr-x  3 root root  4096 Aug  9  2012 mnt/
drwxr-sr-x  2 root root  4096 Jun  6  2012 proc/
drwxr-sr-x  2 root root  4096 Jun  6  2012 run/
drwxr-xr-x  2 root root  4096 Aug  9  2012 sbin/
drwxr-sr-x  2 root root  4096 Jun  6  2012 sys/
drwxrwsrwt  2 root root  4096 Jun  6  2012 tmp/
drwx--S--- 10 root root  4096 Jun  6  2012 usr/
drwxr-xr-x 12 root root  4096 Aug  9  2012 var/  
$ cd /
$ sudo umount /mnt 

I understand the only possible solution is to reset radically devkit somehow, but why this strange bug may have happened? There was no outside interference. The devkit just wasn't turned on for a month.

Yeah, this is unexpected.

Yes, the md5 sum and all installation process outputs are equal.

So, I tried to set up a newly-bought SD card today. Kernel initialization hung again, but this time, I did not turn it off after that and left it for a while (not intentionally). After about half an hour, I discovered this, and it turned out that the kernel was loaded successfully! I don’t know what affected this time: the fact that the card was totally new or that I had waited long enough. I didn’t seem to be in a hurry to turn it off before and waited about five minutes each time. Also, I should point out that now repetitive launches are complete in a habitual span.

Sorry that puzzled you.

Vadym Kolesnyk wrote in RE: Discussion: Kernel hangs on "Waiting for root device ...:

Yes, the md5 sum and all installation process outputs are equal.

Okay that is good

So, I tried to set up a newly-bought SD card today. Kernel initialization hung again, but this time, I did not turn it off after that and left it for a while (not intentionally). After about half an hour, I discovered this, and it turned out that the kernel was loaded successfully! I don’t know what affected this time: the fact that the card was totally new or that I had waited long enough. I didn’t seem to be in a hurry to turn it off before and waited about five minutes each time. Also, I should point out that now repetitive launches are complete in a habitual span.

The next thing we should try is reprogramming u-boot and the ubl. Since we've tried several SD cards and they all act the same, we should make sure that u-boot on the SOM nor isn't the problem. Follow the steps in the below link using the 2018 dead programming files linked in the guide. Make sure also to do the config set steps at the end.

Note: If you want to skip to trying the config set steps just as a quick test, there is a chance it could help.

https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Reprogramming_the_Bootloader

Sorry that puzzled you.

Haha no, that's alright. I meant to reassure you that this is not expected behavior.

Hello, I'm sorry for the delay. I have reprogrammed u-boot as you advised. Loading from a "guilty" SD card is as fast as before, with no freezes. The only problem that returns is that I cannot establish an ethernet connection again (for ssh and package installation/updates). It is quite similar to https://support.criticallink.com/redmine/boards/10/topics/6256, so it may be better to discuss it there.

ADDRCONF(NETDEV_UP): eth0: link is not ready