From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Marcin_Niestr=c3=b3j?= Date: Thu, 12 Apr 2018 10:28:10 +0200 Subject: [U-Boot] chiliSOM: USB bug In-Reply-To: References: <9ce549aa-79a9-81e4-b569-b9a5d574850d@onet.eu> <4c2b8ff1-0b8f-85ea-f4bc-f5d51105d5c7@grinn-global.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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. Embedded Software Developer LinkedIn Twitter YouTube 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 KRS: 0000230049 NIP: 8992730302 REGON: 020047322 Sąd Rejonowy we Wrocławiu VI Wydział Gospodarczy Kapitał zakładowy: 125.000,00 zł