[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