* Re: [PATCH] ppc64: increase TREEWORDS value in ppc64
From: Simon Horman @ 2010-09-10 1:43 UTC (permalink / raw)
To: Neil Horman; +Cc: linuxppc-dev, kexec, vgoyal
In-Reply-To: <20100909202711.GA22581@hmsreliant.think-freely.org>
[ Repost with correct kexec ML address ]
[ CCed linuxppc-dev ]
On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote:
> hey-
> Got a segfault recently on ppc64 kexec with a system with 256Gb of ram.
> Tracked it back to running over the end of the device tree buffer that we have
> allocated. I can't find any docs on how big the device tree can legally be, so
> for now I figure just upping its size is sufficient. Confirmed that this fixed
> the segfault.
Thanks Neil, though it would be nice to know what the limit actually is.
I'll hold off on applying this for a few days to see of the PPC people
have any comments on that.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
>
> fs2dt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> diff --git a/kexec/arch/ppc/fs2dt.c b/kexec/arch/ppc/fs2dt.c
> index 238a3f2..2f0f937 100644
> --- a/kexec/arch/ppc/fs2dt.c
> +++ b/kexec/arch/ppc/fs2dt.c
> @@ -33,7 +33,7 @@
>
> #define MAXPATH 1024 /* max path name length */
> #define NAMESPACE 16384 /* max bytes for property names */
> -#define TREEWORDS 65536 /* max 32 bit words for properties */
> +#define TREEWORDS 131070 /* max 32 bit words for properties */
> #define MEMRESERVE 256 /* max number of reserved memory blks */
> #define MAX_MEMORY_RANGES 1024
> #define COMMAND_LINE_SIZE 512 /* from kernel */
^ permalink raw reply
* Re: [PATCH] ppc64: increase TREEWORDS value in ppc64
From: Simon Horman @ 2010-09-10 1:41 UTC (permalink / raw)
To: Neil Horman; +Cc: linuxppc-dev, vgoyal, kexec
In-Reply-To: <20100909202711.GA22581@hmsreliant.think-freely.org>
[ CCed linuxppc-dev ]
On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote:
> hey-
> Got a segfault recently on ppc64 kexec with a system with 256Gb of ram.
> Tracked it back to running over the end of the device tree buffer that we have
> allocated. I can't find any docs on how big the device tree can legally be, so
> for now I figure just upping its size is sufficient. Confirmed that this fixed
> the segfault.
Thanks Neil, though it would be nice to know what the limit actually is.
I'll hold off on applying this for a few days to see of the ppc people
have any comments on that.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
>
> fs2dt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> diff --git a/kexec/arch/ppc/fs2dt.c b/kexec/arch/ppc/fs2dt.c
> index 238a3f2..2f0f937 100644
> --- a/kexec/arch/ppc/fs2dt.c
> +++ b/kexec/arch/ppc/fs2dt.c
> @@ -33,7 +33,7 @@
>
> #define MAXPATH 1024 /* max path name length */
> #define NAMESPACE 16384 /* max bytes for property names */
> -#define TREEWORDS 65536 /* max 32 bit words for properties */
> +#define TREEWORDS 131070 /* max 32 bit words for properties */
> #define MEMRESERVE 256 /* max number of reserved memory blks */
> #define MAX_MEMORY_RANGES 1024
> #define COMMAND_LINE_SIZE 512 /* from kernel */
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 22:49 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <20100909173735.503c4cc0@schlenkerla.am.freescale.net>
On Thu, 2010-09-09 at 17:37 -0500, Scott Wood wrote:
>
> Wolfgang was just defending it on the U-Boot list the past couple
> days... seems like the main thing in its favor is the CRC, especially
> as a final check before reflashing an image.
Right, then fwd my 2 cents:
Makes sense to have a wrapper like that for flashing, but
- It could/should contain an ELF
- u-boot should be capable to just load/boot the ELF, not everybody
uses flashable images (netboot anyone ? espectially when debugging) and
it's really a burden to do the wrapping all the time. In addition, we
just see how it can actually hurt due to losing information such as the
BSS size.
Cheers,
Ben.
^ permalink raw reply
* Re: Combining defconfigs for 44x based boards
From: Stephen Rothwell @ 2010-09-09 22:42 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev, Wolfgang Denk, Sean MacLennan
In-Reply-To: <69da3260c595cc3870a9ff1eee9a7898@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
Hi,
On Thu, 9 Sep 2010 15:17:10 -0700 Tirumala Marri <tmarri@apm.com> wrote:
>
> [Marri]That is kind of true. Can we create new defconfigs then ?
> I am trying to check-in new defconfig.
Just make sure that it is minimal by using "make savedefconfig". This
will create a file "defconfig" in the current directory which should have
the minimal amount of stuff in it to reproduce the current .config.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Scott Wood @ 2010-09-09 22:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <1284070433.6515.39.camel@pasglop>
On Fri, 10 Sep 2010 08:13:53 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > > I would have expected uboot to warn (the kernel ELF header contains
> > the
> > > BSS size) but apparently that isn't the case.
> >
> > U-Boot doesn't use ELF files with Linux, so it has no idea where the
> > BSS is. uImage is just a wrapper around a flat binary.
>
> Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
> time it grows the ability to load ELF or to at least stick an ELF in a
> uImage...
It actually can load an ELF file, but it doesn't currently support
passing a device tree to it (only argc/argv text arguments, or some
vxworks stuff).
> I've never understood the reasoning for that uImage wrapper
> thingy. Definitely causes more problems than it solves in my experience.
Wolfgang was just defending it on the U-Boot list the past couple
days... seems like the main thing in its favor is the CRC, especially
as a final check before reflashing an image.
-Scott
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Scott Wood @ 2010-09-09 22:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <1284069534.6515.36.camel@pasglop>
On Fri, 10 Sep 2010 07:58:54 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> I would have expected uboot to warn (the kernel ELF header contains the
> BSS size) but apparently that isn't the case.
U-Boot doesn't use ELF files with Linux, so it has no idea where the
BSS is. uImage is just a wrapper around a flat binary.
-Scott
^ permalink raw reply
* RE: Combining defconfigs for 44x based boards
From: Tirumala Marri @ 2010-09-09 22:17 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <20100909130954.265adb37@lappy.seanm.ca>
> On Thu, 9 Sep 2010 09:49:14 -0700
> Tirumala Marri <tmarri@apm.com> wrote:
>
> > [Marri] Great we already have it. We should remove the defconfigs
> > under 44x then ?
>
> I'd rather we didn't. I thought Linus' beef was over the churn in the
> defconfigs, not the fact that they exist. The 44x defconfigs change
> very rarely.
[Marri]That is kind of true. Can we create new defconfigs then ?
I am trying to check-in new defconfig.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 22:16 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <1284070433.6515.39.camel@pasglop>
On Fri, 2010-09-10 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > > I would have expected uboot to warn (the kernel ELF header contains
> > the
> > > BSS size) but apparently that isn't the case.
> >
> > U-Boot doesn't use ELF files with Linux, so it has no idea where the
> > BSS is. uImage is just a wrapper around a flat binary.
>
> Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
> time it grows the ability to load ELF or to at least stick an ELF in a
> uImage... I've never understood the reasoning for that uImage wrapper
> thingy. Definitely causes more problems than it solves in my experience.
Note that with ePAPR we know the top of mapped memory on entry, so
in theory, if the bootloader is fully ePAPR compliant we -could- detect
that case and move the FDT up to after the .dts before we clear the
bss... do we care enough tho ?
Even if we aren't totally ePAPR compliant, we could still try to move
it, if we hit the end of memory well... we won't do more damage than we
already did by by overwriting the dts in the first place.
Cheers,
Ben.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 22:13 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <20100909171116.1b9b6e44@schlenkerla.am.freescale.net>
On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > I would have expected uboot to warn (the kernel ELF header contains
> the
> > BSS size) but apparently that isn't the case.
>
> U-Boot doesn't use ELF files with Linux, so it has no idea where the
> BSS is. uImage is just a wrapper around a flat binary.
Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
time it grows the ability to load ELF or to at least stick an ELF in a
uImage... I've never understood the reasoning for that uImage wrapper
thingy. Definitely causes more problems than it solves in my experience.
Ben.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 22:01 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev, Timur Tabi
In-Reply-To: <20100909193642.GD3496@ovro.caltech.edu>
On Thu, 2010-09-09 at 12:36 -0700, Ira W. Snyder wrote:
> On Thu, Sep 09, 2010 at 02:10:59PM -0500, Timur Tabi wrote:
> > On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
> >
> > > Single stepping through the initial assembly portion of kernel startup
> > > shows that the FDT gets clobbered during the function early_init(). This
> > > trace is reproduced below.
> >
> > Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two
> > config options are related.
> >
>
> Yes, I have had it enabled the whole time.
>
> As noted in another email, it appears that U-Boot puts the FDT in such a
> place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
> option expands the BSS by a large amount, which causes the error. It
> isn't directly lockdep related.
>
> I don't know if this is a U-Boot problem or a Linux problem. I have no
> idea how to fix the bug.
Definitely a u-boot problem. There must be a way to set where the fdt
goes somewhere.
Cheers,
Ben.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 21:58 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <20100909162306.GA3496@ovro.caltech.edu>
> I have succeeded in getting the debugger to break early on during boot.
> I have it set to break at start_here, in arch/powerpc/kernel/head_32.S.
>
> My U-Boot bootloader indicates that the fdt is being loaded to address
> 0x7f8000, which translates to VA 0xc07f8000. See this output:
>
> Booting using the fdt blob at 0x2269f1c
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 0fea0000, end 0ff76699 ... OK
> Loading Device Tree to 007f8000, end 007ff78f ... OK
>
> As soon an the debugger hit the start_here breakpoint, I ran the
> following command. It should dump out the flat device tree to a file,
> which I can then analyze:
>
> (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f
>
> On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree
> in fdt.bin. I see the stuff I would expect.
>
> On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin.
> So clearly something is overwriting the fdt.
>
> However, note that this happens *before* lockdep_init() runs. Grepping
> for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing.
> I'm not sure exactly how this is related to lockdep.
>
> Some more suggestions for things to try would be great. For now, I'm
> going to try getting the debugger to break near the end of U-Boot, to
> see if the memory is overwritten there, and not in Linux.
I suspect your uboot setup. The one thing lockdep does is massively
increase the amount of kernel bss. I suspect you are just overlapping DT
and bss and hence wiping out the DT when clearing the bss.
I would have expected uboot to warn (the kernel ELF header contains the
BSS size) but apparently that isn't the case.
Cheers,
Ben.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Timur Tabi @ 2010-09-09 21:19 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Kumar Gala, linuxppc-dev
In-Reply-To: <20100909205507.GG3496@ovro.caltech.edu>
Ira W. Snyder wrote:
> I have no idea how to determine this.
>
> The code that caused the problem runs so early in boot that the MMU is
> not running yet. Looking through the tiny bit of code, it appears that
> it just uses whatever the bootloader set up for it. It hasn't gotten to
> the initial_bats function yet.
I just spoke to Kumar, and he said that the 8MB is just historical. We ran
into the same exact problem that you ran into, except it was with a normal
kernel, so we changed 8MB to 16MB on our 85xx boards, but we never went back
and made the same change to 83xx boards.
So it should be safe to change CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB on all
83xx systems. However, U-Boot does not verify that CONFIG_SYS_BOOTMAPSZ <=
the actual amount of RAM in the system, so we need to make sure that
CONFIG_SYS_BOOTMAPSZ isn't increased on any board that actually did ship
with only 8MB of RAM. My guess is that no such board exists, but I will get
confirmation.
However, this comment for CONFIG_SYS_BOOTMAPSZ still bothers me:
/*
* For booting Linux, the board info and command line data
* have to be in the first 8 MB of memory, since this is
* the maximum mapped by the Linux kernel during initialization.
*/
This same comment says 16MB on 85xx systems, so I don't think the statement
about "maximum mapped by the Linux kernel" is really true. Maybe someone
else can shed some light on this.
> I think the MPC8349EA would be a 603 CPU, meaning that we could increase
> CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM).
Except that I'm still not sure what CONFIG_SYS_BOOTMAPSZ really means. I
was under the impression that CONFIG_MAX_MEM_MAPPED is the actual value of
the size of the mapping that U-Boot creates for the kernel. When the kernel
initializes the MMU for its own purposes, does it limit anything to 16MB? I
seriously doubt it.
> You'll see that your patch now relocated the FDT. It didn't cause any
> problems. I'll post to the thread on the U-Boot ML.
Yes, please. I need someone to confirm that he tested my patch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Ira W. Snyder @ 2010-09-09 20:55 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4C89454F.8070701@freescale.com>
On Thu, Sep 09, 2010 at 03:36:31PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > That did it!
>
> Yea!
>
> > I'm using include/configs/MPC8349EMDS.h. On that board,
> > CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
> > the kernel now boots.
>
> Ah, yes. I believe the reason that is the case is because some of those
> boards were shipped with only 8MB of RAM.
>
> > I'll make a post to the U-Boot list asking if this should be boosted for
> > MPC8349EMDS (and others?). It is easy to build a kernel that overruns
> > this limit. Other than debugging options, my kernel is fairly minimal,
> > only a few drivers are built in.
>
> I think we should first determine if the kernel boot map limit really is
> 16MB. If it's more than that, then we should consider making it match.
> Assuming, of course, that the U-Boot code can handle a situation where
> CONFIG_SYS_BOOTMAPSZ is larger than the actual amount of RAM.
>
I have no idea how to determine this.
The code that caused the problem runs so early in boot that the MMU is
not running yet. Looking through the tiny bit of code, it appears that
it just uses whatever the bootloader set up for it. It hasn't gotten to
the initial_bats function yet.
The comment in initial_bats (arch/powerpc/kernel/head_32.S) says:
/*
* On 601, we use 3 BATs to map up to 24M of RAM at _PAGE_OFFSET
* (we keep one for debugging) and on others, we use one 256M BAT.
*/
I think the MPC8349EA would be a 603 CPU, meaning that we could increase
CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM).
> > I'm using your always-relocate-fdt patch. Your patch made no difference
> > to the FDT location. U-Boot with and without your patch bo
>
> My patch only does something if the FDT is already located inside the boot
> map. Since you were expanding the size of the boot map, there's a chance
> that the FDT was located between 8MB and 16MB, and if so, my patch would
> have made a difference.
>
Yep, you're exactly correct. I tried loading my FIT image to a lower
address (0xa00000 == 10MB), both with and without your patch:
Without your patch (vanilla U-Boot):
Verifying Hash Integrity ... crc32+ OK
Booting using the fdt blob at 0xc6a278
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
With your patch:
Verifying Hash Integrity ... crc32+ OK
Booting using the fdt blob at 0xc42d6c
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 00ff8000, end 00fff84f ... OK
You'll see that your patch now relocated the FDT. It didn't cause any
problems. I'll post to the thread on the U-Boot ML.
[ dropped mingo and peterz from the CC list, they're not powerpc people ]
Thanks,
Ira
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Timur Tabi @ 2010-09-09 20:36 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <20100909203142.GF3496@ovro.caltech.edu>
Ira W. Snyder wrote:
> That did it!
Yea!
> I'm using include/configs/MPC8349EMDS.h. On that board,
> CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
> the kernel now boots.
Ah, yes. I believe the reason that is the case is because some of those
boards were shipped with only 8MB of RAM.
> I'll make a post to the U-Boot list asking if this should be boosted for
> MPC8349EMDS (and others?). It is easy to build a kernel that overruns
> this limit. Other than debugging options, my kernel is fairly minimal,
> only a few drivers are built in.
I think we should first determine if the kernel boot map limit really is
16MB. If it's more than that, then we should consider making it match.
Assuming, of course, that the U-Boot code can handle a situation where
CONFIG_SYS_BOOTMAPSZ is larger than the actual amount of RAM.
> I'm using your always-relocate-fdt patch. Your patch made no difference
> to the FDT location. U-Boot with and without your patch bo
My patch only does something if the FDT is already located inside the boot
map. Since you were expanding the size of the boot map, there's a chance
that the FDT was located between 8MB and 16MB, and if so, my patch would
have made a difference.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Ira W. Snyder @ 2010-09-09 20:31 UTC (permalink / raw)
To: Timur Tabi; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <4C893FDD.1000507@freescale.com>
On Thu, Sep 09, 2010 at 03:13:17PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > That easily overruns the location where U-Boot puts the FDT. Is this a
> > U-Boot bug, meaning I should post this information on the U-Boot
> > mailing list?
>
> Possibly.
>
> I am under the impression that the memory in the boot block that contains
> the FDT is marked as "reserved" in the device tree, so that the kernel
> doesn't overwrite it. However, that obviously isn't helpful if we haven't
> parsed the device tree yet.
>
> What concerns me is this in U-Boot:
>
> /*
> * For booting Linux, the board info and command line data
> * have to be in the first 16 MB of memory, since this is
> * the maximum mapped by the Linux kernel during initialization.
> */
> #define CONFIG_SYS_BOOTMAPSZ (16 << 20) /* Initial Memory map for Linux*/
>
> If the 16MB mapping limit is true, then does this mean that the Linux's BSS
> is larger than the memory that is mapped? If so, that means that Linux
> can't even access all of its BSS at this point. Somehow, I doubt that.
>
> Can you try increasing the size of CONFIG_SYS_BOOTMAPSZ? Combined with my
> always-relocate-fdt, I think this will force the FDT to be placed higher in
> memory.
>
That did it!
I'm using include/configs/MPC8349EMDS.h. On that board,
CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
the kernel now boots.
I'll make a post to the U-Boot list asking if this should be boosted for
MPC8349EMDS (and others?). It is easy to build a kernel that overruns
this limit. Other than debugging options, my kernel is fairly minimal,
only a few drivers are built in.
I'm using your always-relocate-fdt patch. Your patch made no difference
to the FDT location. U-Boot with and without your patch both work fine,
as soon as I boosted CONFIG_SYS_BOOTMAPSZ to 16MB.
With your patch:
Booting using the fdt blob at 0x226a278
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 00ff8000, end 00fff78f ... OK
Without your patch:
Booting using the fdt blob at 0x226a278
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 00ff8000, end 00fff78f ... OK
Thanks,
Ira
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Timur Tabi @ 2010-09-09 20:13 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <20100909200606.GE3496@ovro.caltech.edu>
Ira W. Snyder wrote:
> That easily overruns the location where U-Boot puts the FDT. Is this a
> U-Boot bug, meaning I should post this information on the U-Boot
> mailing list?
Possibly.
I am under the impression that the memory in the boot block that contains
the FDT is marked as "reserved" in the device tree, so that the kernel
doesn't overwrite it. However, that obviously isn't helpful if we haven't
parsed the device tree yet.
What concerns me is this in U-Boot:
/*
* For booting Linux, the board info and command line data
* have to be in the first 16 MB of memory, since this is
* the maximum mapped by the Linux kernel during initialization.
*/
#define CONFIG_SYS_BOOTMAPSZ (16 << 20) /* Initial Memory map for Linux*/
If the 16MB mapping limit is true, then does this mean that the Linux's BSS
is larger than the memory that is mapped? If so, that means that Linux
can't even access all of its BSS at this point. Somehow, I doubt that.
Can you try increasing the size of CONFIG_SYS_BOOTMAPSZ? Combined with my
always-relocate-fdt, I think this will force the FDT to be placed higher in
memory.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Ira W. Snyder @ 2010-09-09 20:06 UTC (permalink / raw)
To: Timur Tabi; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <4C893842.6090009@freescale.com>
On Thu, Sep 09, 2010 at 02:40:50PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > As noted in another email, it appears that U-Boot puts the FDT in such a
> > place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
> > option expands the BSS by a large amount, which causes the error. It
> > isn't directly lockdep related.
> >
> > I don't know if this is a U-Boot problem or a Linux problem. I have no
> > idea how to fix the bug.
>
> I wonder if this patch that I wrote for U-Boot will fix the problem:
>
> http://lists.denx.de/pipermail/u-boot/2010-May/071822.html
>
Nope, I tried it and it doesn't fix the problem. It relocates the FDT to
exactly the same address as before the patch.
I think the problem is that the U-Boot loader doesn't take into account
the Linux kernel's BSS size, and puts the FDT too close.
Here is the relevant U-Boot output after applying your patch. It was not
changed from the previous output.
Booting using the fdt blob at 0x226a278
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 007f8000, end 007ff78f ... OK
My ramdisk is right near the end of RAM. This board has 256MB of RAM.
0x0ff75699 / 1024 / 1024 == 255.4586
The FDT is just before the 8MB boundary:
0x007ff78f / 1024 / 1024 == 7.9979
My uncompressed vmlinux.bin.gz is ~3.5MB:
iws@rena ~/devel/correlator/fit-image $ zcat vmlinux.bin.gz > vmlinux.bin
iws@rena ~/devel/correlator/fit-image $ du -b vmlinux.bin
3573068 vmlinux.bin
As posted in my other email, Linux's BSS is ~5.2MB:
(gdb) print __bss_start
$23 = 0xc0369000 <Address 0xc0369000 out of bounds>
(gdb) print __bss_stop
$25 = 0xc08a0c48 <Address 0xc08a0c48 out of bounds>
(0xc08a0c48 - 0xc0369000) / 1024 / 1024 == 5.21784210205078125
Total (code + BSS): 3573068 + 5471304 == 9044372 (~8.62MB)
That easily overruns the location where U-Boot puts the FDT. Is this a
U-Boot bug, meaning I should post this information on the U-Boot
mailing list?
Thanks,
Ira
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Timur Tabi @ 2010-09-09 19:40 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <20100909193642.GD3496@ovro.caltech.edu>
Ira W. Snyder wrote:
> As noted in another email, it appears that U-Boot puts the FDT in such a
> place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
> option expands the BSS by a large amount, which causes the error. It
> isn't directly lockdep related.
>
> I don't know if this is a U-Boot problem or a Linux problem. I have no
> idea how to fix the bug.
I wonder if this patch that I wrote for U-Boot will fix the problem:
http://lists.denx.de/pipermail/u-boot/2010-May/071822.html
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Ira W. Snyder @ 2010-09-09 19:36 UTC (permalink / raw)
To: Timur Tabi; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <AANLkTinFu+dttvBA2qyXFxQGOTRpmWeuvmHj40BFKNCm@mail.gmail.com>
On Thu, Sep 09, 2010 at 02:10:59PM -0500, Timur Tabi wrote:
> On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
>
> > Single stepping through the initial assembly portion of kernel startup
> > shows that the FDT gets clobbered during the function early_init(). This
> > trace is reproduced below.
>
> Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two
> config options are related.
>
Yes, I have had it enabled the whole time.
As noted in another email, it appears that U-Boot puts the FDT in such a
place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
option expands the BSS by a large amount, which causes the error. It
isn't directly lockdep related.
I don't know if this is a U-Boot problem or a Linux problem. I have no
idea how to fix the bug.
Thanks,
Ira
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Ira W. Snyder @ 2010-09-09 19:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt, peterz, mingo, linuxppc-dev
In-Reply-To: <20100909184446.GB3496@ovro.caltech.edu>
[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]
On Thu, Sep 09, 2010 at 11:44:46AM -0700, Ira W. Snyder wrote:
[ snip a bunch of info: summary below ]
>
> I've also found that setting a breakpoint at 0x0 stops right when the
> Linux kernel starts, at symbol _start. AFAIK, the MMU is not yet
> enabled, so I have to subtract 0xc0000000 from all addresses.
>
> Single stepping through the initial assembly portion of kernel startup
> shows that the FDT gets clobbered during the function early_init(). This
> trace is reproduced below.
>
> For whatever reason, even when single stepping, the debugger absolutely
> refuses to enter the early_init function.
>
> Misc Information:
> 1) 0xd00dfeed is an FDT magic number
> 2) 0x7f8000 is the physical address of the FDT in memory
>
I have gotten the debugger to enter early_init(). I had to remove the
__init annotation on the function. I guess the debugger doesn't cope
with the extra sections that Linux uses.
(gdb) target remote bdi2k:2001
Remote debugging using bdi2k:2001
0xfc0034e8 in ?? ()
(gdb) info break
Num Type Disp Enb Address What
1 hw breakpoint keep y 0x00000000 /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
breakpoint already hit 1 time
(gdb) continue
Continuing.
Breakpoint 1, _stext () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
72 nop /* used by __secondary_hold on prep (mtx) and chrp smp */
Current language: auto; currently asm
(gdb) s
73 nop /* used by __secondary_hold on prep (mtx) and chrp smp */
(gdb) s
74 nop
(gdb) s
__start () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:113
113 cmpwi 0,r5,0
(gdb) s
114 beq 1f
(gdb) s
142 1: mr r31,r3 /* save parameters */
(gdb) s
143 mr r30,r4
(gdb) s
144 li r24,0 /* cpu # */
(gdb) s
151 bl early_init
(gdb) s
early_init (dt_ptr=8355840) at /home/iws/devel/linux-2.6/arch/powerpc/kernel/setup_32.c:82
82 {
Current language: auto; currently c
(gdb) s
88 memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
(gdb) print /x *0x7f8000
$22 = 0xd00dfeed
(gdb) n
82 {
(gdb) n
88 memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
(gdb) print __bss_start
$23 = 0xc0369000 <Address 0xc0369000 out of bounds>
(gdb) print __bss_stop
$25 = 0xc08a0c48 <Address 0xc08a0c48 out of bounds>
(gdb) print /x *0x7f8000
$26 = 0xd00dfeed
(gdb) n
83 unsigned long offset = reloc_offset();
(gdb) print /x *0x7f8000
$27 = 0xd00dfeed
(gdb) n
88 memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
(gdb) print /x *0x7f8000
$28 = 0xd00dfeed
(gdb) n
55 DEF_PCI_AC_NORET(memset_io, (PCI_IO_ADDR a, int c, unsigned long n),
(gdb) print /x *0x7f8000
$29 = 0xd00dfeed
(gdb) n
95 spec = identify_cpu(offset, mfspr(SPRN_PVR));
(gdb) print /x *0x7f8000
$30 = 0x0
This shows that the memset_io() in early_init() is zeroing the FDT. It
appears that CONFIG_PROVE_LOCKING increases the BSS size significantly,
and that's what is causing the true error. It isn't a lockdep problem,
it is a "the BSS is too big" problem.
Unfortunately, I'm now at a loss on how to fix this. Why does the
bootloader put the FDT so close to the kernel? Is this a bootloader
problem? Is it a configuration problem on my part?
I'm booting with a FIT image. The source file is inlined below. By
U-Boot bootm command is trivial:
dhcp 2000000 carma.itb ; bootm 2000000
Thanks,
Ira
[-- Attachment #2: carma.its --]
[-- Type: text/plain, Size: 1148 bytes --]
/*
* U-boot uImage source file with CARMA kernel, ramdisk, and FDT blob
*
* Compile with:
* $ mkimage -f carma.its carma.itb
*/
/dts-v1/;
/ {
description = "CARMA kernel, ramdisk, and FDT blob";
#address-cells = <1>;
images {
kernel@1 {
description = "Linux 2.6.36rc3";
data = /incbin/("./vmlinux.bin.gz");
type = "kernel";
arch = "ppc";
os = "linux";
compression = "gzip";
load = <0x0>;
entry = <0x0>;
hash@1 {
algo = "md5";
};
hash@2 {
algo = "sha1";
};
};
ramdisk@1 {
description = "CARMA PPC Generic Ramdisk";
data = /incbin/("./initramfs-generic-ppc.cpio.gz");
type = "ramdisk";
arch = "ppc";
os = "linux";
compression = "gzip";
load = <0x0>;
hash@1 {
algo = "sha1";
};
};
fdt@1 {
description = "CARMA FDT";
data = /incbin/("./carma.dtb");
type = "flat_dt";
arch = "ppc";
compression = "none";
hash@1 {
algo = "crc32";
};
};
};
configurations {
default = "config@1";
config@1 {
description = "CARMA 2.6.36rc3 configuration";
kernel = "kernel@1";
ramdisk = "ramdisk@1";
fdt = "fdt@1";
};
};
};
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Timur Tabi @ 2010-09-09 19:10 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <20100909184446.GB3496@ovro.caltech.edu>
On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
> Single stepping through the initial assembly portion of kernel startup
> shows that the FDT gets clobbered during the function early_init(). This
> trace is reproduced below.
Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two
config options are related.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Ira W. Snyder @ 2010-09-09 18:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt, peterz, mingo, linuxppc-dev
In-Reply-To: <20100909162306.GA3496@ovro.caltech.edu>
On Thu, Sep 09, 2010 at 09:23:07AM -0700, Ira W. Snyder wrote:
> On Thu, Sep 09, 2010 at 12:58:16PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-09-08 at 19:52 -0700, Ira W. Snyder wrote:
> > >
> > > I will attempt to get the debugger to stop at start_kernel. I'm having
> > > trouble driving the JTAG debugger (a BDI2000). I have used Denx's
> > > guide
> > > [1] in the past, but the section on debugging the kernel itself is now
> > > missing.
> > >
> > > [1] http://www.denx.de/wiki/view/DULG/DebuggingLinuxKernel
> > >
> > > I'll keep trying.
> >
> > start_kernel might be too late...
> >
> > You can also hack thing :-) Like in the asm, before machine_init(),
> > stick something in the DABR and put a HW breakpoint with the BDI2000 on
> > the Data Access exception handler to "catch" when it faults.
> >
>
> I have succeeded in getting the debugger to break early on during boot.
> I have it set to break at start_here, in arch/powerpc/kernel/head_32.S.
>
> My U-Boot bootloader indicates that the fdt is being loaded to address
> 0x7f8000, which translates to VA 0xc07f8000. See this output:
>
> Booting using the fdt blob at 0x2269f1c
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 0fea0000, end 0ff76699 ... OK
> Loading Device Tree to 007f8000, end 007ff78f ... OK
>
> As soon an the debugger hit the start_here breakpoint, I ran the
> following command. It should dump out the flat device tree to a file,
> which I can then analyze:
>
> (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f
>
> On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree
> in fdt.bin. I see the stuff I would expect.
>
> On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin.
> So clearly something is overwriting the fdt.
>
> However, note that this happens *before* lockdep_init() runs. Grepping
> for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing.
> I'm not sure exactly how this is related to lockdep.
>
> Some more suggestions for things to try would be great. For now, I'm
> going to try getting the debugger to break near the end of U-Boot, to
> see if the memory is overwritten there, and not in Linux.
>
Here is some more information. After tracing U-Boot's execution, I've
found that U-Boot is not the problem. The FDT is correct in-memory at
the point it jumps into the kernel. I literally halted it on the
instruction before the jmp and checked.
I've also found that setting a breakpoint at 0x0 stops right when the
Linux kernel starts, at symbol _start. AFAIK, the MMU is not yet
enabled, so I have to subtract 0xc0000000 from all addresses.
Single stepping through the initial assembly portion of kernel startup
shows that the FDT gets clobbered during the function early_init(). This
trace is reproduced below.
For whatever reason, even when single stepping, the debugger absolutely
refuses to enter the early_init function.
Misc Information:
1) 0xd00dfeed is an FDT magic number
2) 0x7f8000 is the physical address of the FDT in memory
(gdb) info break
Num Type Disp Enb Address What
2 hw breakpoint keep y 0x00000000 /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
breakpoint already hit 3 times
(gdb) detach
Ending remote debugging.
(gdb) target remote bdi2k:2001
Remote debugging using bdi2k:2001
0x0ffbe760 in ?? ()
(gdb) continue
Continuing.
Breakpoint 2, _stext () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
72 nop /* used by __secondary_hold on prep (mtx) and chrp smp */
Current language: auto; currently asm
(gdb) print /x *0x7f8000
$6 = 0xd00dfeed
(gdb) s
73 nop /* used by __secondary_hold on prep (mtx) and chrp smp */
(gdb) s
74 nop
(gdb) s
__start () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:113
113 cmpwi 0,r5,0
(gdb) s
114 beq 1f
(gdb) s
142 1: mr r31,r3 /* save parameters */
(gdb) s
143 mr r30,r4
(gdb) s
144 li r24,0 /* cpu # */
(gdb) s
151 bl early_init
(gdb) print /x *0x7f8000
$7 = 0xd00dfeed
(gdb) s
__start () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:156
156 bl mmu_off
(gdb) print /x *0x7f8000
$8 = 0x0
Ira
^ permalink raw reply
* [PATCH 2/2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Timur Tabi @ 2010-09-09 18:39 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala, yorksun, linux-fbdev
In-Reply-To: <1284057597-17126-1-git-send-email-timur@freescale.com>
The Freescale P1022DS has an on-chip video controller called the DIU, and a
driver for this device already exists. Update the platform file for the
P1022DS reference board to enable the driver, and update the defconfig for
Freescale MPC85xx boards to add the driver.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
The following patch is a pre-requisite for this patch:
powerpc/85xx: add ngPIXIS FPGA device tree node to the P1022DS board
arch/powerpc/configs/mpc85xx_defconfig | 3 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 3 +
arch/powerpc/platforms/85xx/p1022_ds.c | 213 +++++++++++++++++++++++++++-
3 files changed, 217 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index c3b113b..3aeb594 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -124,6 +124,9 @@ CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
# CONFIG_HWMON is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_FB=y
+CONFIG_FB_FSL_DIU=y
+# CONFIG_VGA_CONSOLE is not set
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index a075da2..d62c801 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -126,6 +126,9 @@ CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
# CONFIG_HWMON is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_FB=y
+CONFIG_FB_FSL_DIU=y
+# CONFIG_VGA_CONSOLE is not set
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 34e0090..3340071 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -8,7 +8,6 @@
* Copyright 2010 Freescale Semiconductor, Inc.
*
* This file is taken from the Freescale P1022DS BSP, with modifications:
- * 1) No DIU support (pending rewrite of DIU code)
* 2) No AMP support
* 3) No PCI endpoint support
*
@@ -17,15 +16,216 @@
* kind, whether express or implied.
*/
+#define DEBUG
+
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <linux/memblock.h>
-
+#include <asm/div64.h>
#include <asm/mpic.h>
#include <asm/swiotlb.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
+#include <asm/fsl_guts.h>
+
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
+/*
+ * Board-specific initialization of the DIU. This code should probably be
+ * executed when the DIU is opened, rather than in arch code, but the DIU
+ * driver does not have a mechanism for this (yet).
+ *
+ * This is especially problematic on the P1022DS because the local bus (eLBC)
+ * and the DIU video signals share the same pins, which means that enabling the
+ * DIU will disable access to NOR flash.
+ */
+
+/* DIU Pixel Clock bits of the CLKDVDR Global Utilities register */
+#define CLKDVDR_PXCKEN 0x80000000
+#define CLKDVDR_PXCKINV 0x10000000
+#define CLKDVDR_PXCKDLY 0x06000000
+#define CLKDVDR_PXCLK_MASK 0x00FF0000
+
+/* Some ngPIXIS register definitions */
+#define PX_BRDCFG1_DVIEN 0x80
+#define PX_BRDCFG1_DFPEN 0x40
+#define PX_BRDCFG1_BACKLIGHT 0x20
+#define PX_BRDCFG1_DDCEN 0x10
+
+/*
+ * DIU Area Descriptor
+ *
+ * Note that we need to byte-swap the value before it's written to the AD
+ * register. So even though the registers don't look like they're in the same
+ * bit positions as they are on the MPC8610, the same value is written to the
+ * AD register on the MPC8610 and on the P1022.
+ */
+#define AD_BYTE_F 0x10000000
+#define AD_ALPHA_C_MASK 0x0E000000
+#define AD_ALPHA_C_SHIFT 25
+#define AD_BLUE_C_MASK 0x01800000
+#define AD_BLUE_C_SHIFT 23
+#define AD_GREEN_C_MASK 0x00600000
+#define AD_GREEN_C_SHIFT 21
+#define AD_RED_C_MASK 0x00180000
+#define AD_RED_C_SHIFT 19
+#define AD_PALETTE 0x00040000
+#define AD_PIXEL_S_MASK 0x00030000
+#define AD_PIXEL_S_SHIFT 16
+#define AD_COMP_3_MASK 0x0000F000
+#define AD_COMP_3_SHIFT 12
+#define AD_COMP_2_MASK 0x00000F00
+#define AD_COMP_2_SHIFT 8
+#define AD_COMP_1_MASK 0x000000F0
+#define AD_COMP_1_SHIFT 4
+#define AD_COMP_0_MASK 0x0000000F
+#define AD_COMP_0_SHIFT 0
+
+#define MAKE_AD(alpha, red, blue, green, size, c0, c1, c2, c3) \
+ cpu_to_le32(AD_BYTE_F | (alpha << AD_ALPHA_C_SHIFT) | \
+ (blue << AD_BLUE_C_SHIFT) | (green << AD_GREEN_C_SHIFT) | \
+ (red << AD_RED_C_SHIFT) | (c3 << AD_COMP_3_SHIFT) | \
+ (c2 << AD_COMP_2_SHIFT) | (c1 << AD_COMP_1_SHIFT) | \
+ (c0 << AD_COMP_0_SHIFT) | (size << AD_PIXEL_S_SHIFT))
+
+/**
+ * p1022ds_get_pixel_format: return the Area Descriptor for a given pixel depth
+ *
+ * The Area Descriptor is a 32-bit value that determine which bits in each
+ * pixel are to be used for each color.
+ */
+static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
+ int monitor_port)
+{
+ switch (bits_per_pixel) {
+ case 32:
+ /* 0x88883316 */
+ return MAKE_AD(3, 2, 0, 1, 3, 8, 8, 8, 8);
+ case 24:
+ /* 0x88082219 */
+ return MAKE_AD(4, 0, 1, 2, 2, 0, 8, 8, 8);
+ case 16:
+ /* 0x65053118 */
+ return MAKE_AD(4, 2, 1, 0, 1, 5, 6, 5, 0);
+ default:
+ pr_err("fsl-diu: unsupported pixel depth %u\n", bits_per_pixel);
+ return 0;
+ }
+}
+
+/**
+ * p1022ds_set_gamma_table: update the gamma table, if necessary
+ *
+ * On some boards, the gamma table for some ports may need to be modified.
+ * This is not the case on the P1022DS, so we do nothing.
+*/
+static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
+{
+}
+
+/**
+ * p1022ds_set_monitor_port: switch the output to a different monitor port
+ *
+ */
+static void p1022ds_set_monitor_port(int monitor_port)
+{
+ struct device_node *pixis_node;
+ u8 __iomem *brdcfg1;
+
+ pixis_node = of_find_compatible_node(NULL, NULL, "fsl,fpga-pixis");
+ if (!pixis_node) {
+ pr_err("p1022ds: missing ngPIXIS node\n");
+ return;
+ }
+
+ brdcfg1 = of_iomap(pixis_node, 0);
+ if (!brdcfg1) {
+ pr_err("p1022ds: could not map ngPIXIS registers\n");
+ return;
+ }
+ brdcfg1 += 9; /* BRDCFG1 is at offset 9 in the ngPIXIS */
+
+ switch (monitor_port) {
+ case 0: /* DVI */
+ /* Enable the DVI port, disable the DFP and the backlight */
+ clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
+ PX_BRDCFG1_DVIEN);
+ break;
+ case 1: /* Single link LVDS */
+ /* Enable the DFP port, disable the DVI and the backlight */
+ clrsetbits_8(brdcfg1, PX_BRDCFG1_DVIEN | PX_BRDCFG1_BACKLIGHT,
+ PX_BRDCFG1_DFPEN);
+ break;
+ default:
+ pr_err("p1022ds: unsupported monitor port %i\n", monitor_port);
+ }
+}
+
+/**
+ * p1022ds_set_pixel_clock: program the DIU's clock
+ *
+ * @pixclock: the wavelength, in picoseconds, of the clock
+ */
+void p1022ds_set_pixel_clock(unsigned int pixclock)
+{
+ struct device_node *guts_np = NULL;
+ struct ccsr_guts_85xx __iomem *guts;
+ unsigned long freq;
+ u64 temp;
+ u32 pxclk;
+
+ /* Map the global utilities registers. */
+ guts_np = of_find_compatible_node(NULL, NULL, "fsl,p1022-guts");
+ if (!guts_np) {
+ pr_err("p1022ds: missing global utilties device node\n");
+ return;
+ }
+
+ guts = of_iomap(guts_np, 0);
+ of_node_put(guts_np);
+ if (!guts) {
+ pr_err("p1022ds: could not map global utilties device\n");
+ return;
+ }
+
+ /* Convert pixclock from a wavelength to a frequency */
+ temp = 1000000000000ULL;
+ do_div(temp, pixclock);
+ freq = temp;
+
+ /* pixclk is the ratio of the platform clock to the pixel clock */
+ pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq);
+
+ /* Disable the pixel clock, and set it to non-inverted and no delay */
+ clrbits32(&guts->clkdvdr,
+ CLKDVDR_PXCKEN | CLKDVDR_PXCKDLY | CLKDVDR_PXCLK_MASK);
+
+ /* Enable the clock and set the pxclk */
+ setbits32(&guts->clkdvdr, CLKDVDR_PXCKEN | (pxclk << 16));
+}
+
+/**
+ * p1022ds_show_monitor_port: show the current monitor
+ *
+ * This function returns a string indicating whether the current monitor is
+ * set to DVI or LVDS.
+ */
+ssize_t p1022ds_show_monitor_port(int monitor_port, char *buf)
+{
+ return sprintf(buf, "%c0 - DVI\n%c1 - Single link LVDS\n",
+ monitor_port == 0 ? '*' : ' ', monitor_port == 1 ? '*' : ' ');
+}
+
+/**
+ * p1022ds_set_sysfs_monitor_port: set the monitor port for sysfs
+ */
+int p1022ds_set_sysfs_monitor_port(int val)
+{
+ return val < 2 ? val : 0;
+}
+
+#endif
void __init p1022_ds_pic_init(void)
{
@@ -92,6 +292,15 @@ static void __init p1022_ds_setup_arch(void)
}
#endif
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+ diu_ops.get_pixel_format = p1022ds_get_pixel_format;
+ diu_ops.set_gamma_table = p1022ds_set_gamma_table;
+ diu_ops.set_monitor_port = p1022ds_set_monitor_port;
+ diu_ops.set_pixel_clock = p1022ds_set_pixel_clock;
+ diu_ops.show_monitor_port = p1022ds_show_monitor_port;
+ diu_ops.set_sysfs_monitor_port = p1022ds_set_sysfs_monitor_port;
+#endif
+
#ifdef CONFIG_SMP
mpc85xx_smp_init();
#endif
--
1.7.2.2
^ permalink raw reply related
* [PATCH 1/2] powerpc/85xx: add ngPIXIS FPGA device tree node to the P1022DS board
From: Timur Tabi @ 2010-09-09 18:39 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala, yorksun, linux-fbdev
The device tree for Freescale's P1022DS reference board is missing the node
for the ngPIXIS FPGA.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/boot/dts/p1022ds.dts | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
index 8bcb10b..e61b42d 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -148,6 +148,15 @@
label = "reserved-nand";
};
};
+
+ board-control@3,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,fpga-pixis";
+ reg = <3 0 0x30>;
+ interrupt-parent = <&mpic>;
+ interrupts = <8 8>;
+ };
};
soc@fffe00000 {
--
1.7.2.2
^ permalink raw reply related
* Re: How to define an I2C-to-SPI bridge device ?
From: Grant Likely @ 2010-09-09 18:23 UTC (permalink / raw)
To: Andre Schwarz, Anton Vorontsov; +Cc: LinuxPPC List, DevTreeDiscuss
In-Reply-To: <4C84D334.6060008@matrix-vision.de>
"Andre Schwarz" <andre.schwarz@matrix-vision.de> wrote:
> Anton,
>
>> we're about to get new MPC8377 based hardware with various peripherals.
>>> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
>>> how to define a proper dts...
>>>
>>> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
>>> device - but how can I represent the created SPI bus ?
>> Um.. the same as the other SPI buses? I.e.
>>
>> i2c-controller { /* SOC I2C controller */
>> spi-controller { /* The I2C-to-SPI bridge */
>> spi-device@0 {
>> };
>> spi-device@1 {
>> };
>> };
>> };
>>
>ok , thanks - looks straight forward.
>Is this any more than plain definition, i.e. will this trigger any I2C
>or SPI device registration/linking ?
>>> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
>>> I2C slave or an SPI host driver ?
>> It should be an I2C driver that registers an SPI master (i.e.
>> calls spi_alloc_master() and spi_register_master()).
>hmm - ok. Will have to do it manually then ...
Yes, but this is the case for non-of drivers too. The i2c to spi device driver must always create (and trigger population of) the spi bus instance.
>
>I still wonder how to make the driver arch-generic *and* of-capable.
>Do we need a generic I2C slave driver that can be probed along with an
>"of glue driver" or should the of-binding be part of a single device
>driver ?
There is no longer any need for separate of and non-of drivers for the same hardware. Any device may have the of_node pointer in struct device set, and drivers can use the pointer as an alternative to platform_data to get information about the hardware configuration.
Just read the data out of the node in the driver's probe hook.
For i2c and (soon) spi, the core code will even register child devices for you.
g.
>
>Sorry for the dumb questions - looks like I expected a little too much
>functionality already existing.
>
>
>Regards,
>André
>
>
>MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
>Registergericht: Amtsgericht Stuttgart, HRB 271090
>Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox