[U-Boot] mx28evk_config integration
Hi Stefano,
Can I post a patch for your u-boot-imx tree with my integration of extra subsystems for the mx28evk board, or should I wait until your work on mx28evk_config is in the mainline?
By the way, I have the stranges issue with both your mx28evk_config, Marek's m28evk_config and my combined version: When I'm booting a Kernel that works perfectly well with the old FreeScale 2009.08 U-boot, the Kernel just hang during the boot process. It seems like something goes wrong in emi_set_rate in the Kernel. If you could point me into the right direction, I'd really appreciate it.
Robert.
On Thu, Jan 12, 2012 at 8:07 PM, Robert Deliën robert@delien.nl wrote:
Hi Stefano,
Can I post a patch for your u-boot-imx tree with my integration of extra subsystems for the mx28evk board, or should I wait until your work on mx28evk_config is in the mainline?
I think it is OK if you post patches against Stefano's imx tree.
By the way, I have the stranges issue with both your mx28evk_config, Marek's m28evk_config and my combined version: When I'm booting a Kernel that works perfectly well with the old FreeScale 2009.08 U-boot, the Kernel just hang during the boot process. It seems like something goes wrong in emi_set_rate in the Kernel. If you could point me into the right direction, I'd really appreciate it.
Which kernel version are you using? Please post the full U-boot and kernel output messages.
Regards,
Fabio Estevam
On 12/01/2012 23:07, Robert Deliën wrote:
Hi Stefano,
Hi Robert,
Can I post a patch for your u-boot-imx tree with my integration of extra subsystems for the mx28evk board, or should I wait until your work on mx28evk_config is in the mainline?
Of course you can post patches ! Any fix is always high appreciated !
By the way, I have the stranges issue with both your mx28evk_config, Marek's m28evk_config and my combined version: When I'm booting a Kernel that works perfectly well with the old FreeScale 2009.08 U-boot, the Kernel just hang during the boot process. It seems like something goes wrong in emi_set_rate in the Kernel. If you could point me into the right direction, I'd really appreciate it.
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 ?
Best regards, Stefano Babic
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-execution... (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@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@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
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@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@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
Looks like CPUfreq+usb is doing something eerie ... Fabio, can you look into it?
I've Kernel 3.2.1 and it works. So I've made a clean-built of my 3.1.6 and works too. No idea why it failed before, but I'm going to disregard that for now. I think it's safe to conclude that the problem is an incompatibility between the FreeScale supplied 2.6.35.3-571 Kernel and the current version of U-Boot.
Unfortunately we cannot step up to another Kernel because we need the FreeScale power supply driver for our battery and that's not yet supported in later Kernel versions.
Robert.
On 13/01/2012 13:56, Robert Deliën wrote:
Looks like CPUfreq+usb is doing something eerie ... Fabio, can you look into it?
I've Kernel 3.2.1 and it works. So I've made a clean-built of my 3.1.6 and works too. No idea why it failed before, but I'm going to disregard that for now. I think it's safe to conclude that the problem is an incompatibility between the FreeScale supplied 2.6.35.3-571 Kernel and the current version of U-Boot.
This is possible, but both are not mainlined..
Unfortunately we cannot step up to another Kernel because we need the FreeScale power supply driver for our battery and that's not yet supported in later Kernel versions.
However, the logical approach is to port the power supply driver to the current kernel, and also to push it to mainline !
Best regards, Stefano Babic
On 13/01/2012 13:56, Robert Deliën wrote:
Looks like CPUfreq+usb is doing something eerie ... Fabio, can you look into it?
I've Kernel 3.2.1 and it works. So I've made a clean-built of my 3.1.6 and works too. No idea why it failed before, but I'm going to disregard that for now. I think it's safe to conclude that the problem is an incompatibility between the FreeScale supplied 2.6.35.3-571 Kernel and the current version of U-Boot.
This is possible, but both are not mainlined..
Unfortunately we cannot step up to another Kernel because we need the FreeScale power supply driver for our battery and that's not yet supported in later Kernel versions.
However, the logical approach is to port the power supply driver to the current kernel, and also to push it to mainline !
Which indeed should be a simple task
Best regards, Stefano Babic
Hi Robert,
On Fri, Jan 13, 2012 at 11:06 AM, Stefano Babic sbabic@denx.de wrote:
Unfortunately we cannot step up to another Kernel because we need the FreeScale power supply driver for our battery and that's not yet supported in later Kernel versions.
However, the logical approach is to port the power supply driver to the current kernel, and also to push it to mainline !
I agree with Stefano and Marek that pushing the missing part of the power supply driver to mainline is the best way to proceed.
About the 2.6.35 cpufreq bug you see: I remember to see a patch for it. Let me locate it and I will point it to you.
Or simply try to disable cpufreq if you need a quick workaround for 2.6.35.
Regards,
Fabio Estevam
About the 2.6.35 cpufreq bug you see: I remember to see a patch for it. Let me locate it and I will point it to you.
If there's anything you can remember, please throw it at me: Anything is useful.
Or simply try to disable cpufreq if you need a quick workaround for 2.6.35.
I'll try that next. What we need is fairly simple. No advanced frequency scaling or anything like that. We only need the battery to take over in case of a black- out, so we can unmount the file systems and go down gracefully.
Robert.
I've Kernel 3.2.1 and it works. So I've made a clean-built of my 3.1.6 and works too. No idea why it failed before, but I'm going to disregard that for now. I think it's safe to conclude that the problem is an incompatibility between the FreeScale supplied 2.6.35.3-571 Kernel and the current version of U-Boot.
This is possible, but both are not mainlined..
Well, the current version of U-Boot is, obviously ;-). But indeed, the FreeScale supplied 2.6.35.3-571 Kernel is not. And there's no doubt that this is a bug in the FreeScale Kernel that wasn't triggered before because their U-Boot configured the clocks differently.
Unfortunately we cannot step up to another Kernel because we need the FreeScale power supply driver for our battery and that's not yet supported in later Kernel versions.
However, the logical approach is to port the power supply driver to the current kernel, and also to push it to mainline !
I fully agree. But that driver … it's scaring me! It's make out of - I kid you not - 12 files, containing well over 6000 lines of code. They had to give it it's own directory in .../drivers/power, something no other power driver ever needed.
Robert.
participants (4)
-
Fabio Estevam -
Marek Vasut -
Robert Deliën -
Stefano Babic