* Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Anton Vorontsov @ 2010-09-09 11:41 UTC (permalink / raw)
To: Roy Zang
Cc: B07421, dedekind1, B25806, linuxppc-dev, linux-mtd, akpm, dwmw2,
B11780
In-Reply-To: <1284027632-32573-3-git-send-email-tie-fei.zang@freescale.com>
On Thu, Sep 09, 2010 at 06:20:32PM +0800, Roy Zang wrote:
[...]
> /**
> + * fsl_lbc_addr - convert the base address
> + * @addr_base: base address of the memory bank
> + *
> + * This function converts a base address of lbc into the right format for the BR
> + * registers. If the SOC has eLBC then it returns 32bit physical address else
> + * it returns 34bit physical address for local bus(Example: MPC8641).
> + */
It returns 34bit physical address encoded in a 32 bit word,
right? Because, IIRC, 'unsigned int' is always 32 bit.
Worth mentioning this fact.
> +unsigned int fsl_lbc_addr(phys_addr_t addr_base)
> +{
> + void *dev;
struct device_node *np;
> + int compatible;
> +
> + dev = fsl_lbc_ctrl_dev->dev->of_node;
> + compatible = of_device_is_compatible(dev, "fsl,elbc");
> +
> + if (compatible)
> + return addr_base & 0xffff8000;
> + else
> + return (addr_base & 0x0ffff8000ull)
> + | ((addr_base & 0x300000000ull) >> 19);
> +}
> +EXPORT_SYMBOL(fsl_lbc_addr);
Almost perfect. I'm not sure if 'unsigned int' is technically
correct return type for this function though. I guess it should
be u32.
Also, the function may be a bit more understandable and shorter:
u32 fsl_lbc_addr(phys_addr_t addr)
{
struct device_node *np = fsl_lbc_ctrl_dev->dev->of_node;
u32 addrl = addr & 0xffff8000;
if (of_device_is_compatible(np, "fsl,elbc"))
return addrl;
return addrl | ((addr & 0x300000000ull) >> 19);
}
EXPORT_SYMBOL(fsl_lbc_addr);
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/3 v2][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Anton Vorontsov @ 2010-09-09 11:53 UTC (permalink / raw)
To: Roy Zang
Cc: B07421, dedekind1, B25806, linuxppc-dev, linux-mtd, akpm, dwmw2,
B11780
In-Reply-To: <1284027632-32573-1-git-send-email-tie-fei.zang@freescale.com>
Just a few cosmetic nits for this patch...
On Thu, Sep 09, 2010 at 06:20:30PM +0800, Roy Zang wrote:
[...]
> @@ -94,22 +73,26 @@ int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm *upm)
> {
> int bank;
> __be32 br;
> + struct fsl_lbc_regs __iomem *lbc;
>
> bank = fsl_lbc_find(addr_base);
> if (bank < 0)
> return bank;
>
> - br = in_be32(&fsl_lbc_regs->bank[bank].br);
> + if (!fsl_lbc_ctrl_dev || !fsl_lbc_ctrl_dev->regs)
> + return -ENODEV;
I'd add an empty line here.
> + lbc = fsl_lbc_ctrl_dev->regs;
> + br = in_be32(&lbc->bank[bank].br);
>
> switch (br & BR_MSEL) {
> case BR_MS_UPMA:
> - upm->mxmr = &fsl_lbc_regs->mamr;
> + upm->mxmr = &lbc->mamr;
> break;
> case BR_MS_UPMB:
> - upm->mxmr = &fsl_lbc_regs->mbmr;
> + upm->mxmr = &lbc->mbmr;
> break;
> case BR_MS_UPMC:
> - upm->mxmr = &fsl_lbc_regs->mcmr;
> + upm->mxmr = &lbc->mcmr;
> break;
> default:
> return -EINVAL;
> @@ -143,14 +126,18 @@ EXPORT_SYMBOL(fsl_upm_find);
> * thus UPM pattern actually executed. Note that mar usage depends on the
> * pre-programmed AMX bits in the UPM RAM.
> */
> +
> int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32 mar)
> {
> int ret = 0;
> unsigned long flags;
>
> + if (!fsl_lbc_ctrl_dev || !fsl_lbc_ctrl_dev->regs)
> + return -ENODEV;
> +
> spin_lock_irqsave(&fsl_lbc_lock, flags);
>
> - out_be32(&fsl_lbc_regs->mar, mar);
> + out_be32(&fsl_lbc_ctrl_dev->regs->mar, mar);
>
> switch (upm->width) {
> case 8:
> @@ -172,3 +159,188 @@ int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32 mar)
> return ret;
> }
> EXPORT_SYMBOL(fsl_upm_run_pattern);
> +
> +static int __devinit fsl_lbc_ctrl_init(struct fsl_lbc_ctrl *ctrl)
> +{
> + struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> +
> + /* clear event registers */
> + setbits32(&lbc->ltesr, LTESR_CLEAR);
> + out_be32(&lbc->lteatr, 0);
> + out_be32(&lbc->ltear, 0);
> + out_be32(&lbc->lteccr, LTECCR_CLEAR);
> + out_be32(&lbc->ltedr, LTEDR_ENABLE);
> +
> + /* Enable interrupts for any detected events */
> + out_be32(&lbc->lteir, LTEIR_ENABLE);
> +
> + return 0;
> +}
> +
> +static int __devexit fsl_lbc_ctrl_remove(struct platform_device *ofdev)
> +{
> + struct fsl_lbc_ctrl *ctrl = dev_get_drvdata(&ofdev->dev);
> +
> + if (ctrl->irq)
> + free_irq(ctrl->irq, ctrl);
> +
> + if (ctrl->regs)
> + iounmap(ctrl->regs);
> +
> + dev_set_drvdata(&ofdev->dev, NULL);
> +
> + kfree(ctrl);
> +
> + return 0;
> +}
> +
> +/*
> + * NOTE: This interrupt is used to report localbus events of various kinds,
> + * such as transaction errors on the chipselects.
> + */
> +
> +static irqreturn_t fsl_lbc_ctrl_irq(int irqno, void *data)
> +{
> + struct fsl_lbc_ctrl *ctrl = data;
> + struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> + u32 status;
> +
> + status = in_be32(&lbc->ltesr);
> +
> + if (status) {
You could save indentation and improve readability by writing
status = in_be32(&lbc->ltesr);
if (!status)
return IRQ_NONE;
...the rest of the function...
I understand that you just move the code around though.
> + out_be32(&lbc->ltesr, LTESR_CLEAR);
> + out_be32(&lbc->lteatr, 0);
> + out_be32(&lbc->ltear, 0);
> + ctrl->irq_status = status;
> +
> + if (status & LTESR_BM)
> + dev_err(ctrl->dev, "Local bus monitor time-out: "
> + "LTESR 0x%08X\n", status);
> + if (status & LTESR_WP)
> + dev_err(ctrl->dev, "Write protect error: "
> + "LTESR 0x%08X\n", status);
> + if (status & LTESR_ATMW)
> + dev_err(ctrl->dev, "Atomic write error: "
> + "LTESR 0x%08X\n", status);
> + if (status & LTESR_ATMR)
> + dev_err(ctrl->dev, "Atomic read error: "
> + "LTESR 0x%08X\n", status);
> + if (status & LTESR_CS)
> + dev_err(ctrl->dev, "Chip select error: "
> + "LTESR 0x%08X\n", status);
> + if (status & LTESR_UPM)
> + ;
> + if (status & LTESR_FCT) {
> + dev_err(ctrl->dev, "FCM command time-out: "
> + "LTESR 0x%08X\n", status);
> + smp_wmb();
> + wake_up(&ctrl->irq_wait);
> + }
> + if (status & LTESR_PAR) {
> + dev_err(ctrl->dev, "Parity or Uncorrectable ECC error: "
> + "LTESR 0x%08X\n", status);
> + smp_wmb();
> + wake_up(&ctrl->irq_wait);
> + }
> + if (status & LTESR_CC) {
> + smp_wmb();
> + wake_up(&ctrl->irq_wait);
> + }
> + if (status & ~LTESR_MASK)
> + dev_err(ctrl->dev, "Unknown error: "
> + "LTESR 0x%08X\n", status);
> +
> + return IRQ_HANDLED;
> + }
> +
> + return IRQ_NONE;
> +}
> +
> +/*
> + * fsl_lbc_ctrl_probe
> + *
> + * called by device layer when it finds a device matching
> + * one our driver can handled. This code allocates all of
> + * the resources needed for the controller only. The
> + * resources for the NAND banks themselves are allocated
> + * in the chip probe function.
> +*/
> +
> +static int __devinit fsl_lbc_ctrl_probe(struct platform_device *ofdev,
> + const struct of_device_id *match)
> +{
> + int ret;
> +
> + if (!ofdev->dev.of_node) {
> + dev_err(&ofdev->dev, "Device OF-Node is NULL");
> + return -EFAULT;
> + }
> + fsl_lbc_ctrl_dev = kzalloc(sizeof(*fsl_lbc_ctrl_dev), GFP_KERNEL);
> + if (!fsl_lbc_ctrl_dev)
> + return -ENOMEM;
> +
> + dev_set_drvdata(&ofdev->dev, fsl_lbc_ctrl_dev);
> +
> + spin_lock_init(&fsl_lbc_ctrl_dev->lock);
> + init_waitqueue_head(&fsl_lbc_ctrl_dev->irq_wait);
> +
> + fsl_lbc_ctrl_dev->regs = of_iomap(ofdev->dev.of_node, 0);
> + if (!fsl_lbc_ctrl_dev->regs) {
> + dev_err(&ofdev->dev, "failed to get memory region\n");
> + ret = -ENODEV;
> + goto err;
> + }
> +
> + fsl_lbc_ctrl_dev->irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
> + if (fsl_lbc_ctrl_dev->irq == NO_IRQ) {
> + dev_err(&ofdev->dev, "failed to get irq resource\n");
> + ret = -ENODEV;
> + goto err;
> + }
> +
> + fsl_lbc_ctrl_dev->dev = &ofdev->dev;
> +
> + ret = fsl_lbc_ctrl_init(fsl_lbc_ctrl_dev);
> + if (ret < 0)
> + goto err;
> +
> + ret = request_irq(fsl_lbc_ctrl_dev->irq, fsl_lbc_ctrl_irq, 0,
> + "fsl-lbc", fsl_lbc_ctrl_dev);
> + if (ret != 0) {
> + dev_err(&ofdev->dev, "failed to install irq (%d)\n",
> + fsl_lbc_ctrl_dev->irq);
> + ret = fsl_lbc_ctrl_dev->irq;
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + iounmap(fsl_lbc_ctrl_dev->regs);
> + kfree(fsl_lbc_ctrl_dev);
> + return ret;
> +}
> +
> +static const struct of_device_id fsl_lbc_match[] = {
> + { .compatible = "fsl,elbc", },
> + { .compatible = "fsl,pq3-localbus", },
> + { .compatible = "fsl,pq2-localbus", },
> + { .compatible = "fsl,pq2pro-localbus", },
> + {},
> +};
You need linux/mod_devicetable.h for this.
> +
> +static struct of_platform_driver fsl_lbc_ctrl_driver = {
Need linux/of_platform.h for this.
But you actually don't need of_platform_driver, as for the
new code you can use platform_driver (and thus
linux/platform_device.h).
> + .driver = {
> + .name = "fsl-lbc",
> + .of_match_table = fsl_lbc_match,
> + },
> + .probe = fsl_lbc_ctrl_probe,
> +};
> +
> +static int __init fsl_lbc_init(void)
> +{
> + return of_register_platform_driver(&fsl_lbc_ctrl_driver);
> +}
> +
No need for this empty line.
> +module_init(fsl_lbc_init);
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: pci_request_regions() failure
From: Ravi Gupta @ 2010-09-09 12:37 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <4C88AF1E.8010608@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]
Hi Tiejun,
Thanks for the reply.
Omm.
>
> Often we always disable this pref windows so please disable this window.
> Try use
> the following ways to clear PCI_PREF_MEMORY_BASE and PCI_PREF_MEMORY_LIMIT.
> ------
> pci_write_config_word(dev, PCI_PREF_MEMORY_BASE, 0);
> pci_write_config_word(dev, PCI_PREF_MEMORY_LIMIT, 0);
>
>
I have a little confusion about what you said. You said I should disable
prefetched window corresponds to PCI Bridge to [bus 02-ff], the dmesgs shows
that it is already disabled.
pci 0001:01:00.0: PCI bridge to [bus 02-ff]
pci 0001:01:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
*pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff pref]
(disabled)*
Is it something that I am not getting right or you have miss read something?
If it is problem with me, then what should be the O/P in case when I disable
the prefetch window (by issuing pci_write_config_word(dev,
PCI_PREF_MEMORY_BASE, 0); and pci_write_config_word(dev,
PCI_PREF_MEMORY_LIMIT, 0); function calls)? And also, I will be really
thankful to you if you also tell me the function in which I should place
there function calls as I am new to linux device driver programming.
Regards,
Ravi
[-- Attachment #2: Type: text/html, Size: 1638 bytes --]
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Ira W. Snyder @ 2010-09-09 16:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <1284001096.6515.33.camel@pasglop>
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.
Ira
^ permalink raw reply
* RE: Combining defconfigs for 44x based boards
From: Tirumala Marri @ 2010-09-09 16:49 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20100909063601.03CCE1506AA@gemini.denx.de>
>
> We already have arch/powerpc/configs/ppc40x_defconfig and
> arch/powerpc/configs/ppc44x_defconfig in mainline.
>
> What's wrong with using these?
[Marri] Great we already have it. We should remove the defconfigs under
44x then ?
Regards,
Marri
^ permalink raw reply
* Re: How to define an I2C-to-SPI bridge device ?
From: Grant Likely @ 2010-09-09 17:06 UTC (permalink / raw)
To: André Schwarz; +Cc: LinuxPPC List, DevTreeDiscuss
In-Reply-To: <1283502979.17812.22.camel@swa-m460>
On Fri, Sep 03, 2010 at 10:36:19AM +0200, André Schwarz wrote:
> Hi,
>
> 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 ?
>
> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
> I2C slave or an SPI host driver ?
Both! The driver would get probed from the i2c bus, and it would
create and register an spi master. If the spi bus registration
includes a pointer to the device tree node, then the child nodes will
automatically be registered as spi_devices.
The dts is also fairly straight forward:
i2c-bus: i2c@80001000 {
compatible = <blah>;
#address-cells = <1>;
#size-cells = <0>;
spi-bus: spi@28{
compatible = "nxp,sc18is602";
#address-cells = <1>;
#size-cells = <0x28>;
reg = <0>;
spi-device@0 {
compatible = <blah>;
reg = <0>;
};
spi-device@1 {
compatible = <blah>;
reg = <1>;
};
spi-device@2 {
compatible = <blah>;
reg = <2>;
};
};
};
Cheers,
g.
>
>
> Any help is welcome.
>
>
> --
> Mit freundlichen Grüßen / Best regards
>
> André Schwarz
>
> ___________________________________________
>
> MATRIX VISION GmbH
> - Entwicklung / Development -
> Talstraße 16
> D-71570 Oppenweiler
>
> Fon: ++49-07191-9432-420
> Fax: ++49-07191-9432-288
> eMail: andre.schwarz@matrix-vision.de
> web: www.matrix-vision.de
>
>
> 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
^ permalink raw reply
* Re: Combining defconfigs for 44x based boards
From: Sean MacLennan @ 2010-09-09 17:09 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <56886bb653a2198b7a5bdcf5f38d4a98@mail.gmail.com>
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.
Cheers,
Sean
^ permalink raw reply
* 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
* [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
* [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
* 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
* 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 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: 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: 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 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 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: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: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: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 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: 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: 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 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: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
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