[U-Boot] mx28evk_config integration

[Marek Vasut]

> Hi Stephan,
> 
> > Of course you can post patches ! Any fix is always high appreciated !
> 
> I figured patches on a different repo were a bit 'unusual', but I'll clean
> up my work and submit my patch soon.
> 
> > Exactly which kernel version ? Do you tried with mainline kernel ? The
> > board is officially supported in mainline. Can you test with a 3.2+
> > kernel ?
> 
> 'Any' version; The FreeScale supplied version 2.6.35.3-571 that came with
> the board, but also a community version 3.1.6. The strange thing is that
> the exact same uImage files of both these Kernels work perfectly fine when
> loaded by the ancient FreeScale supplied U-Boot 2009.08, so there must be
> some difference in the hand-over.
> 
> The Kernel stops booting after the message:
> mxs_cpu_init: cpufreq init finished
> (Full log included below)
> With the JTAG debugger attached, it will report SIGABRT somewhere in
> emi_set_rate. I realize that the message above is printed _after_ this
> function has run successfully, hence with the JTAG debugger attached it
> doesn't get that far. But for now I'd like to disregard that as a
> difference in cache contents.
> 
> Function mxs_cpu_init relocates function mxs_ram_freq_scale to SRAM and
> calls it. (I've noticed that the arguments are still in SDRAM, but the
> function seems to take care of copying those to SRAM itself) Function
> mxs_ram_freq_scale configures the SDRAM clock and after that it all stops.
> With the debugger it stops immediately, when running freely it still gets
> around to printing the message. I suppose without debugger there's still
> enough code in cache to do that.
> 
> So there must be something wrong with SDRAM configuration. But this Kernel
> runs on this board when it's loaded by an older version of U-Boot. So I
> figured it assumes an underlying clock configuration that's no longer
> corresponds with the way the newer U-Boot configures the clocks. And
> that's where I'm puzzling now.
> 
> These guys:
> http://imxcommunity.org/group/imx28andimx28evk/forum/topics/kernel-executio
> n-stops-at?xg_source=activity (Still stuck with the ancient U-Boot version
> and ditto Kernel) report a similar symptom with mis-configured SDRAM, so I
> think I'm heading in the right way.
> 
> I'll pull Kernel version 3.2.1 now and see how that works, though I'd
> really like to understand the problem before considering it 'solved'.
> 
> Cheers,
> 
> 	Robert.
> 
> Log:
> ====
> U-Boot 2011.12-svn319 (Jan 11 2012 - 12:54:24)
> 
> Freescale i.MX28 family
> I2C:   ready
> DRAM:  128 MiB
> WARNING: Caches not enabled
> NAND:  1024 MiB
> MMC:   MXS MMC: 0
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC0
> Warning: failed to set MAC address
> , FEC1
> Warning: failed to set MAC address
> 
> Hit any key to stop autoboot:  0
> Using FEC0 device
> TFTP from server 192.168.72.80; our IP address is 192.168.72.111
> Filename 'uImage'.
> Load address: 0x42000000
> Loading: T
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> ##########################
> done
> Bytes transferred = 2461264 (258e50 hex)
> ## Booting kernel from Legacy Image at 42000000 ...
>    Image Name:   linux-2.6.35.3-571-gcca29a0490
>    Created:      2012-01-03  20:42:29 UTC
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    2461200 Bytes = 2.3 MiB
>    Load Address: 40008000
>    Entry Point:  40008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
> Linux version 2.6.35.3-571-gcca29a0490 Micro GC FuMo-svn300
> (robert at macpro-ubuntu) (gcc version 4.4.4 (4.4.4_09.06.2012 CPU:
> ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Freescale MX28EVK board
> Memory policy: ECC disabled, Data cache writeback
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
> Kernel command line: console=ttyAMA0,115200n8
> ip=192.168.72.111::192.168.72.1:255.255.255.0:::none root=/dev/nfs nfsro/
> PID hash table entries: 512 (order: -1, 2048 bytes)
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 128MB = 128MB total
> Memory: 124676k/124676k available, 6396k reserved, 0K highmem
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     DMA     : 0xfde00000 - 0xffe00000   (  32 MB)
>     vmalloc : 0xc8800000 - 0xf0000000   ( 632 MB)
>     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
>     modules : 0xbf000000 - 0xc0000000   (  16 MB)
>       .text : 0xc002b000 - 0xc04a8000   (4596 kB)
>       .init : 0xc0008000 - 0xc002b000   ( 140 kB)
>       .data : 0xc04a8000 - 0xc04dda60   ( 215 kB)
>        .bss : 0xc04ddae0 - 0xc0524274   ( 282 kB)
> SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> Hierarchical RCU implementation.
>         RCU-based detection of stalled CPUs is disabled.
>         Verbose stalled-CPUs detection is disabled.
> NR_IRQS:288
> Console: colour dummy device 80x30
> console [ttyAMA0] enabled
> Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496)
> pid_max: default: 32768 minimum: 301
> Security Framework initialized
> SELinux:  Initializing.
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> regulator: core version 0.5
> NET: Registered protocol family 16
> regulator: vddd: 800 <--> 1575 mV at 1500 mV fast normal
> regulator: vdddbo: 800 <--> 1575 mV fast normal
> regulator: vdda: 1500 <--> 2275 mV at 1800 mV fast normal
> vddio = 3380000, val=10
> regulator: vddio: 2880 <--> 3680 mV at 3380 mV fast normal
> regulator: overall_current: fast normal
> regulator: vbus5v:
> regulator: mxs-duart-1: fast normal
> regulator: mxs-bl-1: fast normal
> regulator: mxs-i2c-1: fast normal
> regulator: mmc_ssp-1: fast normal
> regulator: mmc_ssp-2: fast normal
> regulator: charger-1: fast normal
> regulator: power-test-1: fast normal
> regulator: cpufreq-1: fast normal
> i.MX IRAM pool: 124 KB at 0xc8820000
> usb DR wakeup device is registered
> IMX usb wakeup probe
> audit: cannot initialize inotify handle
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Advanced Linux Sound Architecture Driver Version 1.0.23.
> Switching to clocksource mxs clock source
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> Bus freq driver module loaded
> IMX usb wakeup probe
> usb h1 wakeup device is registered
> mxs_cpu_init: cpufreq init finished

Looks like CPUfreq+usb is doing something eerie ... Fabio, can you look into it?

M