[U-Boot] Newbie SPL question for socfpga_sockit
George Broz
brozgeo at gmail.com
Thu Apr 7 03:42:22 CEST 2016
On 6 April 2016 at 03:43, Marek Vasut <marex at denx.de> wrote:
> On 04/06/2016 03:17 AM, George Broz wrote:
>> On 5 April 2016 at 17:45, Marek Vasut <marex at denx.de> wrote:
>>> On 04/06/2016 02:31 AM, George Broz wrote:
>>>> On 5 April 2016 at 15:03, Marek Vasut <marex at denx.de> wrote:
>>>>> On 04/05/2016 10:33 AM, Phil Reid wrote:
>>>>>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>>>>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>>>>>
>>>>>>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>>>>>>> I am
>>>>>>>>>> not using any Altera tools when I build.
>>>>>>>>>>
>>>>>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>>>>>> $make u-boot-with-spl.sfp
>>>>>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>>>>>
>>>>>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>>>>>>>>
>>>>>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>>>>>
>>>>>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dinh
>>>>>>>>>
>>>>>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>>>>>> have, disabling dcache fixed that.
>>>>>>>>>
>>>>>>>>> I am starting to wonder whether we're hitting some corner case here.
>>>>>>>>> Maybe we should eventually try and trace all the register reads and
>>>>>>>>> writes generated by the DDR calibration code both in old and new SPL
>>>>>>>>> and make a diff to see if something really did change.
>>>>>>>>>
>>>>>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>>>>>>>>
>>>>>>>>
>>>>>>>> My SoC is:
>>>>>>>>
>>>>>>>> 5CSEMA4U23C6N
>>>>>>>> CACAU1525A
>>>>>>>>
>>>>>>>> DRAMs are:
>>>>>>>>
>>>>>>>> ISSI 1510
>>>>>>>> IS43TR16256A
>>>>>>>> 15HBL K080
>>>>>>>> P4482100QER2 TWN
>>>>>>>
>>>>>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>>>>>> desk because this is creepy.
>>>>>>>
>>>>>>>
>>>>>> FYI
>>>>>>
>>>>>> I've just spend some time trying to update the spl / uboot / kernel &
>>>>>> rootfs image on our
>>>>>> Altera socdk to use for some software testing / development.
>>>>>> Unfortunately it fails in the mem calibration process with the latest
>>>>>> uboot most of the time.
>>>>>> And when it does boot somtimes fails loading uboot fomr the mmc.
>>>>>
>>>>> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>>>>>
>>>>> [1]
>>>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>>>>
>>>> I downloaded a "snapshot" from the above link producing,
>>>> u-boot-socfpga-1931be2.tar.gz
>>>>
>>>> When I try to build for sockit or de0_nano_soc I get:
>>>>
>>>> CC drivers/mmc/mmc-uclass.o
>>>> CC drivers/mmc/dw_mmc.o
>>>> CC drivers/mmc/mmc.o
>>>> CC drivers/mmc/socfpga_dw_mmc.o
>>>> drivers/mmc/socfpga_dw_mmc.c:9:28: fatal error: asm/arch/dwmmc.h: No
>>>> such file or directory
>>>> #include <asm/arch/dwmmc.h>
>>>> ^
>>>> compilation terminated.
>>>> make[1]: *** [drivers/mmc/socfpga_dw_mmc.o] Error 1
>>>> make: *** [drivers/mmc] Error 2
>>>
>>> Thanks for spotting this. Did you try the most basic of basic approaches:
>>>
>>> diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
>>> index 43a7e7e..097db81 100644
>>> --- a/drivers/mmc/socfpga_dw_mmc.c
>>> +++ b/drivers/mmc/socfpga_dw_mmc.c
>>> @@ -6,7 +6,6 @@
>>>
>>> #include <common.h>
>>> #include <asm/arch/clock_manager.h>
>>> -#include <asm/arch/dwmmc.h>
>>> #include <asm/arch/system_manager.h>
>>> #include <dm.h>
>>> #include <dwmmc.h>
>>>
>>> The git tree is updated now.
>>
>> It compiles and it works!
>>
>> On sockit:
>>
>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
>> drivers/ddr/altera/sequencer.c: Calibration complete
>> Trying to boot from MMC1
>>
>> First time that an SPL built from a recent version has run successfully
>> on that board.
>>
>> Will try it out on de0 tomorrow morning...
>
> This is great news, thanks!
This patch also fixes the intermittent SDRAM calibration failures on my
de0_nano_soc board. Thanks so much!
Now with up-to-date versions of SPL and image... I have some
USB questions/news/observations:
When using an OTG cable between USB port and mass storage
device, the de0_nano_soc board is able to detect and access some USB
sticks. The detection with these is almost immediate from when 'usb start'
is entered. If the same (working) USB stick is used with a non-OTG cable,
I get the timeout messages from before:
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
and this is true even if I add 'dr_mode = "host" ' to the dts for usb1
of the de0
(and rebuild/reload). The older SPL/image that ships from the Terasic factory
detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
What is the correct "expected" behavior here?? Is an OTG cable required or
not?
Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
I have a Kingston stick and the sequence goes like this:
=> usb reset
resetting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices...
<<< 1 minute, 41 seconds pass before >>>
... Device NOT ready
Request Sense returned 00 00 00
<<< then another 24 seconds pass before >>>
2 USB Device(s) found
It was able to read some information about the stick:
=> usb info
:
2: Mass Storage, USB Revision 2.0
- Kingston DataTraveler SE9 0014857749E5ECB0173000D3
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor: 0x0930 Product 0x6545 Version 1.0
Configuration: 1
- Interfaces: 1 Bus Powered 200mA
Interface: 0
- Alternate Setting 0, Endpoints: 2
- Class Mass Storage, Transp. SCSI, Bulk only
- Endpoint 1 In Bulk MaxPacket 512
- Endpoint 2 Out Bulk MaxPacket 512
BUT, the stick cannot be accessed otherwise, for example:
=> usb part 0
## Unknown partition table type 0
Is there any feature of the USB stick that would indicate
whether or not it is "compatible" with u-boot?
Thanks again for the calibration fix! Let me
know if there is something else I can test!
Best regards,
--George Broz
>
> Best regards,
> Marek Vasut
More information about the U-Boot
mailing list