[U-Boot] chiliSOM: USB bug

[U-Boot] chiliSOM: USB bug

[sdrb]

Hi,

I use Grinn's chiliSOM and very old U-boot 2014.07 on it. Unfortunately 
the newest u-boot doesn't run SPL properly - so I'm forced to use 
2014.07 version.

I noticed that there is some problem with USB maintenance. As far as I 
know the chiliSOM is TI AM335x compatible system so it uses Mentor USB 
OTG controller.

The problem occures when I'm trying to use following sequence of commands:

# usb start
# usb stop
# usb start

and after the second "usb start" I get error:

[2018-04-06 08:13:42.600] U-Boot# usb start
[2018-04-06 08:13:44.162] (Re)start USB...
[2018-04-06 08:13:44.164] USB0:   scanning bus 0 for devices... 5 USB 
Device(s) found
[2018-04-06 08:13:50.872]        scanning usb for storage devices... 0 
Storage Device(s) found
[2018-04-06 08:13:50.881] U-Boot# usb stop
[2018-04-06 08:13:55.514] stopping USB..
[2018-04-06 08:13:55.521] U-Boot# usb start
[2018-04-06 08:14:01.962] (Re)start USB...
[2018-04-06 08:14:01.964] USB0:   lowlevel init failed
[2018-04-06 08:14:16.730] USB error: all controllers failed lowlevel init
[2018-04-06 08:14:16.734] U-Boot#

I dig a little the code and I noticed that there is some line which 
breaks up things.
The problem is in proc musb_generic_disable() where there is zeroed 
DEVCTL register.
Seems like zeroing breaks somehow Mentor USB because after it it not 
possible to turn USB host mode.

I tried to solve the problem with push MUSB into suspend mode, then zero 
DEVCTL and then resume MUSB, but still no success.
So I decided to remove this line from my code and now it seems to work. 
I mean now USB is working fine:

[2018-04-06 08:15:44.290] U-Boot# usb start
[2018-04-06 08:15:45.787] (Re)start USB...
[2018-04-06 08:15:45.790] USB0:   scanning bus 0 for devices... 5 USB 
Device(s) found
[2018-04-06 08:15:52.489]        scanning usb for storage devices... 0 
Storage Device(s) found
[2018-04-06 08:15:52.495] U-Boot# usb stop
[2018-04-06 08:15:54.835] stopping USB..
[2018-04-06 08:15:54.837] U-Boot# usb start
[2018-04-06 08:17:03.323] (Re)start USB...
[2018-04-06 08:17:03.325] USB0:   scanning bus 0 for devices... 5 USB 
Device(s) found
[2018-04-06 08:17:09.864]        scanning usb for storage devices... 0 
Storage Device(s) found
[2018-04-06 08:17:09.871] U-Boot#


I know that my u-boot version 2014.07 is quite old, but the proc 
musb_generic_disable() in newest version is the same so probably the 
problem also still occures on other boards.

Anyone can verify or confirm that? I'd like to know if this is not 
specific to my board with chiliSOM.
I removed zeroing of DEVCTL register but maybe there is some better 
solution?

Any thoughts?

WK


commit 22447924ca27d3332698d3976f3e5e653bf893cc
Author: Witold Kowolik <sdrb@onet.eu>
Date:   Wed Apr 11 07:49:42 2018 +0200

     ARM: am335x: chiliSOM: Temporary workaround for Mentor OTG USB in 
host mode

     Signed-off-by: Witold Kowolik <sdrb@onet.eu>

diff --git a/drivers/usb/musb-new/musb_core.c 
b/drivers/usb/musb-new/musb_core.c
index 79e118ef85..2be2bd6081 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -977,7 +977,7 @@ static void musb_generic_disable(struct musb *musb)
  	musb_writew(mbase, MUSB_INTRRXE, 0);

  	/* off */
-	musb_writeb(mbase, MUSB_DEVCTL, 0);
+	/* musb_writeb(mbase, MUSB_DEVCTL, 0); */

  	/*  flush pending interrupts */
  	temp = musb_readb(mbase, MUSB_INTRUSB);

[U-Boot] chiliSOM: USB bug

[Marcin Niestroj]

Hi Witold,

On 11.04.2018 08:18, sdrb wrote:
> Hi,
> 
> I use Grinn's chiliSOM and very old U-boot 2014.07 on it. Unfortunately 
> the newest u-boot doesn't run SPL properly - so I'm forced to use 
> 2014.07 version.

What are your problems exactly with SPL? What version of chiliSOM does
you board have? Mainline u-boot with SPL runs successfully on
chiliboard 1.1 (containing chiliSOM 2.2).

> 
> I noticed that there is some problem with USB maintenance. As far as I 
> know the chiliSOM is TI AM335x compatible system so it uses Mentor USB 
> OTG controller.
> 
> The problem occures when I'm trying to use following sequence of commands:
> 
> # usb start
> # usb stop
> # usb start

See output of commands issued on u-boot 2018.03:

=> usb start
starting USB...
USB0:   scanning bus 0 for devices... 1 USB Device(s) found
        scanning usb for storage devices... Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
0 Storage Device(s) found
=> usb stop
stopping USB..
=> usb start
starting USB...
USB0:   scanning bus 0 for devices... 1 USB Device(s) found
        scanning usb for storage devices... Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
0 Storage Device(s) found

Did you try to connect other USB devices? Is that issue connected
USB device dependent?

Regards,
Marcin

> 
> and after the second "usb start" I get error:
> 
> [2018-04-06 08:13:42.600] U-Boot# usb start
> [2018-04-06 08:13:44.162] (Re)start USB...
> [2018-04-06 08:13:44.164] USB0:   scanning bus 0 for devices... 5 USB 
> Device(s) found
> [2018-04-06 08:13:50.872]        scanning usb for storage devices... 0 
> Storage Device(s) found
> [2018-04-06 08:13:50.881] U-Boot# usb stop
> [2018-04-06 08:13:55.514] stopping USB..
> [2018-04-06 08:13:55.521] U-Boot# usb start
> [2018-04-06 08:14:01.962] (Re)start USB...
> [2018-04-06 08:14:01.964] USB0:   lowlevel init failed
> [2018-04-06 08:14:16.730] USB error: all controllers failed lowlevel init
> [2018-04-06 08:14:16.734] U-Boot#
> 
> I dig a little the code and I noticed that there is some line which 
> breaks up things.
> The problem is in proc musb_generic_disable() where there is zeroed 
> DEVCTL register.
> Seems like zeroing breaks somehow Mentor USB because after it it not 
> possible to turn USB host mode.
> 
> I tried to solve the problem with push MUSB into suspend mode, then zero 
> DEVCTL and then resume MUSB, but still no success.
> So I decided to remove this line from my code and now it seems to work. 
> I mean now USB is working fine:
> 
> [2018-04-06 08:15:44.290] U-Boot# usb start
> [2018-04-06 08:15:45.787] (Re)start USB...
> [2018-04-06 08:15:45.790] USB0:   scanning bus 0 for devices... 5 USB 
> Device(s) found
> [2018-04-06 08:15:52.489]        scanning usb for storage devices... 0 
> Storage Device(s) found
> [2018-04-06 08:15:52.495] U-Boot# usb stop
> [2018-04-06 08:15:54.835] stopping USB..
> [2018-04-06 08:15:54.837] U-Boot# usb start
> [2018-04-06 08:17:03.323] (Re)start USB...
> [2018-04-06 08:17:03.325] USB0:   scanning bus 0 for devices... 5 USB 
> Device(s) found
> [2018-04-06 08:17:09.864]        scanning usb for storage devices... 0 
> Storage Device(s) found
> [2018-04-06 08:17:09.871] U-Boot#
> 
> 
> I know that my u-boot version 2014.07 is quite old, but the proc 
> musb_generic_disable() in newest version is the same so probably the 
> problem also still occures on other boards.
> 
> Anyone can verify or confirm that? I'd like to know if this is not 
> specific to my board with chiliSOM.
> I removed zeroing of DEVCTL register but maybe there is some better 
> solution?
> 
> Any thoughts?
> 
> WK
> 
> 
> commit 22447924ca27d3332698d3976f3e5e653bf893cc
> Author: Witold Kowolik <sdrb@onet.eu>
> Date:   Wed Apr 11 07:49:42 2018 +0200
> 
>      ARM: am335x: chiliSOM: Temporary workaround for Mentor OTG USB in 
> host mode
> 
>      Signed-off-by: Witold Kowolik <sdrb@onet.eu>
> 
> diff --git a/drivers/usb/musb-new/musb_core.c 
> b/drivers/usb/musb-new/musb_core.c
> index 79e118ef85..2be2bd6081 100644
> --- a/drivers/usb/musb-new/musb_core.c
> +++ b/drivers/usb/musb-new/musb_core.c
> @@ -977,7 +977,7 @@ static void musb_generic_disable(struct musb *musb)
>       musb_writew(mbase, MUSB_INTRRXE, 0);
> 
>       /* off */
> -    musb_writeb(mbase, MUSB_DEVCTL, 0);
> +    /* musb_writeb(mbase, MUSB_DEVCTL, 0); */
> 
>       /*  flush pending interrupts */
>       temp = musb_readb(mbase, MUSB_INTRUSB);
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

-- 
Marcin Niestroj

[U-Boot] chiliSOM: USB bug

[sdrb]

Hi Marcin,

Marcin Niestroj wrote:
> Hi Witold,
> 
> On 11.04.2018 08:18, sdrb wrote:
>> Hi,
>>
>> I use Grinn's chiliSOM and very old U-boot 2014.07 on it. 
>> Unfortunately the newest u-boot doesn't run SPL properly - so I'm 
>> forced to use 2014.07 version.
> 
> What are your problems exactly with SPL? What version of chiliSOM does
> you board have? Mainline u-boot with SPL runs successfully on
> chiliboard 1.1 (containing chiliSOM 2.2).

I've got ChiliSOM 2.2 version.
I don't use chiliboard - I've got only chiliSOM 2.2 integrated in our 
carrying board.


The problem is that SPL is not starting as good as in 2014.07 version. I 
mean - firmware shows only a few 'C' letters and then it hungs in some 
infinite loop:

CCCCCCCCCCCCCCC

but when at that moment I press Reset button it starts but unfortunately 
something is going wrong because it restarts:

U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
+0200)
Trying to boot from MMC1
CCCCCCCC
U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
+0200)
Trying to boot from MMC1
CCCCCCCC
U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
+0200)
Trying to boot from MMC1
CCCCCCCC
U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
+0200)
Trying to boot from MMC1

So - to run newest u-boot I need to power-on board and then press reset.


I dig a litte in source of latest uboot and noticed that the last 
procedure which is invoked in SPL is jump_to_image_no_args().
This proc tries to go to 0x80800000 addr and then reset appears.
But before it tries to go into this addr it successfully reads 
u-boot.img file. So rather the problem is in invocation of TPL than in SPL.

I wonder why the u-boot.img file is only 389392 bytes long while in old 
u-boot it was 1.7 MB.

Additionally - I see no device tree source file for chilisom in git repo 
but the configuration file mention it in CONFIG_DEFAULT_FDT_FILE.

Do we use the same u-boot repo? I use this one: 
http://git.denx.de/u-boot.git

and master branch.

Maybe I did something wrong?

>> I noticed that there is some problem with USB maintenance. As far as I 
>> know the chiliSOM is TI AM335x compatible system so it uses Mentor USB 
>> OTG controller.
>>
>> The problem occures when I'm trying to use following sequence of 
>> commands:
>>
>> # usb start
>> # usb stop
>> # usb start
> 
> See output of commands issued on u-boot 2018.03:
> 
> => usb start
> starting USB...
> USB0:   scanning bus 0 for devices... 1 USB Device(s) found
>         scanning usb for storage devices... Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> 0 Storage Device(s) found
> => usb stop
> stopping USB..
> => usb start
> starting USB...
> USB0:   scanning bus 0 for devices... 1 USB Device(s) found
>         scanning usb for storage devices... Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> 0 Storage Device(s) found
> 
> Did you try to connect other USB devices? Is that issue connected
> USB device dependent?

We've got two USB 1.1 hubs integrated on board - so I cannot switch them 
off. I'm connecting USB device to one of it ports. I see no any 
dependency between any connected USB device and the problem.

Regards,
WK

[U-Boot] chiliSOM: USB bug

[Marcin Niestrój]

On 12.04.2018 06:37, sdrb wrote:
> Hi Marcin,
> 
> Marcin Niestroj wrote:
>> Hi Witold,
>>
>> On 11.04.2018 08:18, sdrb wrote:
>>> Hi,
>>>
>>> I use Grinn's chiliSOM and very old U-boot 2014.07 on it. 
>>> Unfortunately the newest u-boot doesn't run SPL properly - so I'm 
>>> forced to use 2014.07 version.
>>
>> What are your problems exactly with SPL? What version of chiliSOM does
>> you board have? Mainline u-boot with SPL runs successfully on
>> chiliboard 1.1 (containing chiliSOM 2.2).
> 
> I've got ChiliSOM 2.2 version.
> I don't use chiliboard - I've got only chiliSOM 2.2 integrated in our 
> carrying board.
> 
> 
> The problem is that SPL is not starting as good as in 2014.07 version. I 
> mean - firmware shows only a few 'C' letters and then it hungs in some 
> infinite loop:
> 
> CCCCCCCCCCCCCCC
> 
> but when at that moment I press Reset button it starts but unfortunately 
> something is going wrong because it restarts:
> 
> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
> +0200)
> Trying to boot from MMC1
> CCCCCCCC
> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
> +0200)
> Trying to boot from MMC1
> CCCCCCCC
> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
> +0200)
> Trying to boot from MMC1
> CCCCCCCC
> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
> +0200)
> Trying to boot from MMC1
> 
> So - to run newest u-boot I need to power-on board and then press reset.

Could you describe what is you BOOT[4:0] configuration? And you want to
boot from MMC1, right?
If you are booting u-boot 2014.07 version, do you still see CCCCC on the 
beginning?

I have noticed something else on chiliboard. Device is normally powered
on with no problems (after plugging in USB cable for example). But after
it powers off (to RTC only), then I push power button to wakeup device,
it shows CCCCCCC in infinite loop. To recover from this state I need
to plug out SD card and plug it in once again. Then device boots
correctly. Thought this is hardware issue and didn't have enough
time to look at that.
I wonder if both issues have the same root cause...

> 
> 
> I dig a litte in source of latest uboot and noticed that the last 
> procedure which is invoked in SPL is jump_to_image_no_args().
> This proc tries to go to 0x80800000 addr and then reset appears.
> But before it tries to go into this addr it successfully reads 
> u-boot.img file. So rather the problem is in invocation of TPL than in SPL.
> 
> I wonder why the u-boot.img file is only 389392 bytes long while in old 
> u-boot it was 1.7 MB.
> 
> Additionally - I see no device tree source file for chilisom in git repo 
> but the configuration file mention it in CONFIG_DEFAULT_FDT_FILE.

This configuration sets name of dts file to be used with Linux kernel.

> 
> Do we use the same u-boot repo? I use this one: 
> http://git.denx.de/u-boot.git
> 
> and master branch.

Yes, I use the same repo and branch.

> 
> Maybe I did something wrong?
> 
>>> I noticed that there is some problem with USB maintenance. As far as 
>>> I know the chiliSOM is TI AM335x compatible system so it uses Mentor 
>>> USB OTG controller.
>>>
>>> The problem occures when I'm trying to use following sequence of 
>>> commands:
>>>
>>> # usb start
>>> # usb stop
>>> # usb start
>>
>> See output of commands issued on u-boot 2018.03:
>>
>> => usb start
>> starting USB...
>> USB0:   scanning bus 0 for devices... 1 USB Device(s) found
>>         scanning usb for storage devices... Device NOT ready
>>     Request Sense returned 02 3A 00
>> Device NOT ready
>>     Request Sense returned 02 3A 00
>> Device NOT ready
>>     Request Sense returned 02 3A 00
>> Device NOT ready
>>     Request Sense returned 02 3A 00
>> 0 Storage Device(s) found
>> => usb stop
>> stopping USB..
>> => usb start
>> starting USB...
>> USB0:   scanning bus 0 for devices... 1 USB Device(s) found
>>         scanning usb for storage devices... Device NOT ready
>>     Request Sense returned 02 3A 00
>> Device NOT ready
>>     Request Sense returned 02 3A 00
>> Device NOT ready
>>     Request Sense returned 02 3A 00
>> Device NOT ready
>>     Request Sense returned 02 3A 00
>> 0 Storage Device(s) found
>>
>> Did you try to connect other USB devices? Is that issue connected
>> USB device dependent?
> 
> We've got two USB 1.1 hubs integrated on board - so I cannot switch them 
> off. I'm connecting USB device to one of it ports. I see no any 
> dependency between any connected USB device and the problem.
> 
> Regards,
> WK

-- 
MARCIN NIESTRÓJ
	Grinn sp. z o.o. <http://grinn-global.com>
Embedded Software Developer

	
LinkedIn <https://www.linkedin.com/company/grinn> 	Twitter
<https://twitter.com/GrinnInt> 	YouTube
<https://www.youtube.com/channel/UCiiEEK1yzyeMSeku06RFXPQ>

GRINN sp. z o.o
Wagonowa 2
53-609 Wrocław 	tel. +48 71 716 40 99
fax +48 71 716 41 53
www.grinn-global.com <http://grinn-global.com/> 	KRS: 0000230049
NIP: 8992730302
REGON: 020047322 	Sąd Rejonowy we Wrocławiu
VI Wydział Gospodarczy
Kapitał zakładowy: 125.000,00 zł

[U-Boot] chiliSOM: USB bug

[sdrb]

Marcin Niestrój wrote:
> 
> 
> On 12.04.2018 06:37, sdrb wrote:
>> Hi Marcin,
>>
>> Marcin Niestroj wrote:
>>> Hi Witold,
>>>
>>> On 11.04.2018 08:18, sdrb wrote:
>>>> Hi,
>>>>
>>>> I use Grinn's chiliSOM and very old U-boot 2014.07 on it. 
>>>> Unfortunately the newest u-boot doesn't run SPL properly - so I'm 
>>>> forced to use 2014.07 version.
>>>
>>> What are your problems exactly with SPL? What version of chiliSOM does
>>> you board have? Mainline u-boot with SPL runs successfully on
>>> chiliboard 1.1 (containing chiliSOM 2.2).
>>
>> I've got ChiliSOM 2.2 version.
>> I don't use chiliboard - I've got only chiliSOM 2.2 integrated in our 
>> carrying board.
>>
>>
>> The problem is that SPL is not starting as good as in 2014.07 version. 
>> I mean - firmware shows only a few 'C' letters and then it hungs in 
>> some infinite loop:
>>
>> CCCCCCCCCCCCCCC
>>
>> but when at that moment I press Reset button it starts but 
>> unfortunately something is going wrong because it restarts:
>>
>> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
>> +0200)
>> Trying to boot from MMC1
>> CCCCCCCC
>> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
>> +0200)
>> Trying to boot from MMC1
>> CCCCCCCC
>> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
>> +0200)
>> Trying to boot from MMC1
>> CCCCCCCC
>> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 
>> +0200)
>> Trying to boot from MMC1
>>
>> So - to run newest u-boot I need to power-on board and then press reset.
> 
> Could you describe what is you BOOT[4:0] configuration? And you want to
> boot from MMC1, right?

If I read the BOOT[4:0] properly it is: 0011.
I want to boot from SD card.

> If you are booting u-boot 2014.07 version, do you still see CCCCC on the 
> beginning?

Yes

> I have noticed something else on chiliboard. Device is normally powered
> on with no problems (after plugging in USB cable for example). But after
> it powers off (to RTC only), then I push power button to wakeup device,
> it shows CCCCCCC in infinite loop. To recover from this state I need
> to plug out SD card and plug it in once again. Then device boots
> correctly. Thought this is hardware issue and didn't have enough
> time to look at that.
> I wonder if both issues have the same root cause...

I have also noticed that sometimes the whole system is not starting 
properly and still shows 'C' letters. And yes - I also replug SD card or 
turn off the power to fix the problem.

>> I dig a litte in source of latest uboot and noticed that the last 
>> procedure which is invoked in SPL is jump_to_image_no_args().
>> This proc tries to go to 0x80800000 addr and then reset appears.
>> But before it tries to go into this addr it successfully reads 
>> u-boot.img file. So rather the problem is in invocation of TPL than in 
>> SPL.
>>
>> I wonder why the u-boot.img file is only 389392 bytes long while in 
>> old u-boot it was 1.7 MB.
>>
>> Additionally - I see no device tree source file for chilisom in git 
>> repo but the configuration file mention it in CONFIG_DEFAULT_FDT_FILE.
> 
> This configuration sets name of dts file to be used with Linux kernel.
> 

Ok, I thought that u-boot uses it for its own purposes.

Regards,
WK

[U-Boot] chiliSOM: USB bug

[Marcin Niestroj]

On 12.04.2018 11:09, sdrb wrote:
> Marcin Niestrój wrote:
>>
 >> <snip>
>>
>> Could you describe what is you BOOT[4:0] configuration? And you want to
>> boot from MMC1, right?
> 
> If I read the BOOT[4:0] properly it is: 0011.
> I want to boot from SD card.

Please provide these 5 pins (including 4 and 0) configuration.

-- 
Marcin Niestroj

[U-Boot] chiliSOM: USB bug

[sdrb]

Marcin Niestroj wrote:
> 
> 
> On 12.04.2018 11:09, sdrb wrote:
>> Marcin Niestrój wrote:
>>>
>  >> <snip>
>>>
>>> Could you describe what is you BOOT[4:0] configuration? And you want to
>>> boot from MMC1, right?
>>
>> If I read the BOOT[4:0] properly it is: 0011.
>> I want to boot from SD card.
> 
> Please provide these 5 pins (including 4 and 0) configuration.
> 

Sorry for misprint - SYSBOOT[4:0] pins are as follows: 00011.

Regards,
WK

[U-Boot] chiliSOM: USB bug

[Marcin Niestroj]

On 12.04.2018 13:35, sdrb wrote:
> Marcin Niestroj wrote:
>>
>>
>> On 12.04.2018 11:09, sdrb wrote:
>>> Marcin Niestrój wrote:
>>>>
>>  >> <snip>
>>>>
>>>> Could you describe what is you BOOT[4:0] configuration? And you want to
>>>> boot from MMC1, right?
>>>
>>> If I read the BOOT[4:0] properly it is: 0011.
>>> I want to boot from SD card.
>>
>> Please provide these 5 pins (including 4 and 0) configuration.
>>
> 
> Sorry for misprint - SYSBOOT[4:0] pins are as follows: 00011.

Unfortunately I can't reproduce this issue on my side with chiliboard.
It's hard to tell what could be the problem when using you board.
What RAM vendor is on chiliSOM you have on your board? Maybe there
DDR is not initialized with proper timing? Don't have other ideas for
now.

> 
> Regards,
> WK
> 

-- 
Marcin Niestroj

[U-Boot] chiliSOM: USB bug

[sdrb]

Marcin Niestroj wrote:
> 
> On 12.04.2018 13:35, sdrb wrote:
>> Marcin Niestroj wrote:
>>>
>>>
>>> On 12.04.2018 11:09, sdrb wrote:
>>>> Marcin Niestrój wrote:
>>>>>
>>>  >> <snip>
>>>>>
>>>>> Could you describe what is you BOOT[4:0] configuration? And you 
>>>>> want to
>>>>> boot from MMC1, right?
>>>>
>>>> If I read the BOOT[4:0] properly it is: 0011.
>>>> I want to boot from SD card.
>>>
>>> Please provide these 5 pins (including 4 and 0) configuration.
>>>
>>
>> Sorry for misprint - SYSBOOT[4:0] pins are as follows: 00011.
> 
> Unfortunately I can't reproduce this issue on my side with chiliboard.
> It's hard to tell what could be the problem when using you board.
> What RAM vendor is on chiliSOM you have on your board? Maybe there
> DDR is not initialized with proper timing? Don't have other ideas for
> now.
> 

If I identified properly the chip it is Samsung.

[U-Boot] chiliSOM: USB bug

[Marcin Niestroj]

On 13.04.2018 11:12, sdrb wrote:
> Marcin Niestroj wrote:
>>
>> On 12.04.2018 13:35, sdrb wrote:
>>> Marcin Niestroj wrote:
>>>>
>>>>
>>>> On 12.04.2018 11:09, sdrb wrote:
>>>>> Marcin Niestrój wrote:
>>>>>>
>>>>  >> <snip>
>>>>>>
>>>>>> Could you describe what is you BOOT[4:0] configuration? And you 
>>>>>> want to
>>>>>> boot from MMC1, right?
>>>>>
>>>>> If I read the BOOT[4:0] properly it is: 0011.
>>>>> I want to boot from SD card.
>>>>
>>>> Please provide these 5 pins (including 4 and 0) configuration.
>>>>
>>>
>>> Sorry for misprint - SYSBOOT[4:0] pins are as follows: 00011.
>>
>> Unfortunately I can't reproduce this issue on my side with chiliboard.
>> It's hard to tell what could be the problem when using you board.
>> What RAM vendor is on chiliSOM you have on your board? Maybe there
>> DDR is not initialized with proper timing? Don't have other ideas for
>> now.
>>
> 
> If I identified properly the chip it is Samsung.
> 

We had an issue with Samsung DDR on chiliSOM with one of our clients
and his board. We have used a workaround patch to sleep between
DDR initialization and copying u-boot.img to RAM. If there was no delay,
then RAM memory was in undefined behavior, resulting in very strange
runtime errors. We used u-boot 2014.07 back then.

However I see that commit 69b918b65d11 ("am33xx,ddr3: fix ddr3 sdram
configuration") already addresses this issue, but in a different way
than we did back then.

So I have no idea now what goes wrong in your case.

-- 
Marcin Niestroj