On Fri, Nov 8, 2019 at 11:59 AM Bartosz Golaszewski brgl@bgdev.pl wrote:
pt., 8 lis 2019 o 18:33 Bartosz Golaszewski bgolaszewski@baylibre.com napisał(a):
pt., 8 lis 2019 o 17:14 Adam Ford aford173@gmail.com napisał(a):
On Fri, Nov 8, 2019 at 9:50 AM Bartosz Golaszewski bgolaszewski@baylibre.com wrote:
pt., 25 paź 2019 o 18:10 Bartosz Golaszewski brgl@bgdev.pl napisał(a):
czw., 26 wrz 2019 o 01:21 Faiz Abbas faiz_abbas@ti.com napisał(a):
Hi,
On 29/07/19 12:28 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski bgolaszewski@baylibre.com > > Enable CONFIG_SPL_DM and enable the driver model for serial by defining > an appropriate device in the board file for da850-lcdk. >
This breaks booting from MMC on omapl138_lcdk. You didn't add a U_BOOT_DEVICE for the mmc node.
Thanks, Faiz
Just letting you know I haven't forgotten about this. I finally got some time to work on it this week, but it turned out to be non-trivial, as for some reason the set_cmd mmc callback is not being properly assigned in SPL with driver-model and I couldn't find out why so far. Next week I'm at ELCE, but I'll be back at it on Thursday. I'm not sure if you want to revert the offending patch for now or this can wait for another week?
Best regards, Bartosz Golaszewski
I've been working on this some more this week and noticed that in SPL for some reason the bind function of the mmc driver is not called (despite the driver being probed fine), but so far I've been unable to figure out why exactly. This is the reason for the failure as the mmc is not properly setup but the mmc core thinks it is and tries using it.
I've tried both using a U_BOOT_DEVICE() defined in the board file or adding the mmc node to arch/arm/dts/da850-lcdk-u-boot.dtsi.
Adam: you know davinci's SPL pretty well - do you have any suggestions?
I am not sure that I know it well. It's just one of several TI platforms that I support for Logic PD.
Two thoughts I had: There are aliases setup for various peripherals but I am not seeing one for mmc0 = &mmc1. I a not sure if it will help or not but it is different I see.
I'm having the same problem even when I'm defining the device using U_BOOT_DEVICE() in the relevant board file.
There is also a function void board_boot_order (u32 *spl_boot_list) which can force the system to boot from a given device (ie, MMC1). It's an optional function, but it's a quick and dirty option to try.
Thanks, I'll take a look at that.
It's still the same, no matter what order I specify here.
One thing that bothers me is: if I manually call mmc_bind() from probe instead of the bind() callback, it fails with ENOMEM on memory allocation when creating the block device. I'm wondering if it has something to do with the simple malloc we're using now.
Over the weekend, I sent a series of patches. One of them, [1], was to increase the size of the available RAM before relocation. I believe i doubled the amount from 1k to 2k.
Can you see if the ENMOM error still exists?
[1] - https://patchwork.ozlabs.org/patch/1192574/
adam
Bart
What are the jumper settings to boot from SD, I have an lcdk I can try when I have some time. It's not an official board I can support, but I can tinker when I'm off the clock.
When looking at the board with the ethernet port in the upper-right corner the jumpers should be like this:
---^----You can flash the .ais image onto an SD card with the following command:
dd if=u-boot.ais of=<sdcard> seek=117 bs=512 conv=fsyncThanks! Bart