[meta-freescale] linux-congatec (fido) silent after Starting kernel ...

[Leon Woestenberg]

I could start the built u-boot from (u)SD card using the not-really-public
registers.

# setting for BOOT_CFG1, this select USDHC2 (Congatec on-module uSD)
mw.l 0x020d8040 0x2850
mw.l 0x020d8044 0x10000000
reset

# setting for BOOT_CFG1, this select USDHC4 (Congatec carrier board SD slot)
mw.l 0x020d8040 0x3850
mw.l 0x020d8044 0x10000000
reset

As 'bmode' was not available on my pre-installed u-boot, I used this
convenience command to boot u-boot from the SD card:

setenv sd 'mw.l 0x020d8040 0x3850; mw.l 0x020d8044 0x10000000; reset'


However, although the newer u-boot 2013.04 supports the DTB now, I'm still
getting stuck after the kernel starts.
Any further ideas?

Thanks,

Leon.


conga-QMX6 U-Boot > run sd
resetting ...


U-Boot 2013.04 QMX6Rx20 (May 19 2015 - 13:34:17)

CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
CPU:   Temperature 32 C, calibration data: 0x56b4d469
Reset cause: POR
Board: conga-QMX6
I2C:   ready
DRAM:  1 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
SF: Detected SST25VF032B with page size 4 KiB, total 4 MiB
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:    serial
Out:   serial
Err:   serial
PFUZE100 Rev. [10/21] detected
Net:   configure Atheros AR8035 Ethernet Phy at address 6
FEC
Warning: FEC using MAC address from net device

Normal Boot
Hit any key to stop autoboot:  0
U-Boot > run bootcmd_net
Using FEC device
TFTP from server 192.168.1.9; our IP address is 192.168.1.103
Filename 'cgtqmx6/uImage.dtb'.
Load address: 0x10780000
Loading: ####
     6.6 MiB/s
done
Bytes transferred = 48083 (bbd3 hex)
Using FEC device
TFTP from server 192.168.1.9; our IP address is 192.168.1.103
Filename 'cgtqmx6/uImage'.
Load address: 0x10800000
Loading: #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     ##############################################
     6.9 MiB/s
done
Bytes transferred = 5432656 (52e550 hex)
## Booting kernel from Legacy Image at 10800000 ...
   Image Name:   Linux-3.10.53-1.1.1_qmx6+g9f56bf
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5432592 Bytes = 5.2 MiB
   Load Address: 10008000
   Entry Point:  10008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 10780000
   Booting using the fdt blob at 0x10780000
   Loading Kernel Image ... OK
OK
switch to ldo_bypass mode!
   Loading Device Tree to 4f543000, end 4f551bd2 ... OK

Starting kernel ...









On Wed, May 20, 2015 at 10:47 PM, Leon Woestenberg <
leon.woestenberg at gmail.com> wrote:

> Reading that patch comment more clearly, I now understand that both u-boot
> and the SoC do in fact interpret the registers, because the SoC ignores it
> for SPL type boot.
>
> With that, I will try to boot the .sdcard image generated by the
> fsl-community-bsp-platform tomorrow.
>
> Thanks,
>
> Leon.
>
> On Wed, May 20, 2015 at 10:43 PM, Leon Woestenberg <
> leon.woestenberg at gmail.com> wrote:
>
>> Hi Otavio,
>>
>>
>> On Wed, May 20, 2015 at 10:32 PM, Otavio Salvador <
>> otavio at ossystems.com.br> wrote:
>>
>>> On Wed, May 20, 2015 at 5:27 PM, Leon Woestenberg
>>> <leon.woestenberg at gmail.com> wrote:
>>> ...
>>> > Can anybody provide more insight here?
>>> ...
>>>
>>> yes. This is mostly what bmode in new U-Boot versions does. The
>>> 0x10000000 can be seen at:
>>>
>>>
>>> https://github.com/Freescale/u-boot-fslc/blob/patches-2015.04/arch/arm/cpu/armv7/mx6/soc.c#L478
>>>
>>
>> Thanks. So these registers are interpreted by the SoC itself and not by
>> u-boot on subsequent warm-reset?
>>
>> I found some explanation of these "secret" registers here:
>>
>> https://patchwork.ozlabs.org/patch/404723/
>>
>>
>> Regards,
>> --
>> Leon
>>
>
>
>
> --
> Leon
>



-- 
Leon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20150521/cd2f4fbc/attachment-0001.html>