[U-Boot] mx28evk_config integration

[U-Boot] mx28evk_config integration

[Robert Deliën]

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.

[U-Boot] mx28evk_config integration

[Fabio Estevam]

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

[U-Boot] mx28evk_config integration

[Stefano Babic]

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

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] mx28evk_config integration

[Robert Deliën]

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-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

[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

[U-Boot] mx28evk_config integration

[Robert Deliën]

> 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.

[U-Boot] mx28evk_config integration

[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 !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] mx28evk_config integration

[Marek Vasut]

> 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

[U-Boot] mx28evk_config integration

[Fabio Estevam]

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

[U-Boot] mx28evk_config integration

[Robert Deliën]

> 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.

[U-Boot] mx28evk_config integration

[Robert Deliën]

>> 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.