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 mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
