[U-Boot] chiliSOM: USB bug

Thu Apr 12 08:28:10 UTC 2018

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ł