From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Fri, 13 Jan 2012 13:49:27 +0100 Subject: [U-Boot] mx28evk_config integration In-Reply-To: <5A6714A2-479A-4D24-BFC6-4A3236C4C4F8@delien.nl> References: <68CF423E-FBC3-4E40-91BB-737C36E8CB73@Delien.nl> <4F0FE8B0.20905@denx.de> <5A6714A2-479A-4D24-BFC6-4A3236C4C4F8@delien.nl> Message-ID: <201201131349.27511.marek.vasut@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > 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 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