[PATCH] ehci-fsl: Fix 'have_sysif_regs' detection

[Peter Tyser]

Previously a check was done on an ID register at the base of a CPU's
internal USB registers to determine if system interface regsiters were
present.  The check looked for an ID register that had the format
ID[0:5] == ~ID[8:13] as described in the MPC5121 User's Manual to
determine if a MPC5121 or MPC83xx/85xx was being used.

There are two issues with this method:
- The ID register is not defined on the MPC83xx/85xx CPUs, so its
  unclear what is being checked on them.
- Newer CPUs such as the P4080 also don't document the ID register, but
  do share the same format as the MPC5121.  Thus the previous code did
  not set 'have_sysif_regs' properly which results in the P4080 not
  properly initializing its USB ports.

Using the device tree 'compatible' node is a cleaner way to determine if
'have_sysif_regs' should be set and resolves the USB initialization issue
seen on the P4080.

Tested on a P4080-based system and compile tested on mpc512x_defconfig
with Freescale EHCI driver enabled.

Cc: Anatolij Gustschin ag...@denx.de
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
 drivers/usb/host/ehci-fsl.c  |   13 -
 drivers/usb/host/ehci-fsl.h  |3 ---
 drivers/usb/host/fsl-mph-dr-of.c |   11 ---
 3 files changed, 8 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 86e4289..5c761df 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -52,7 +52,6 @@ static int usb_hcd_fsl_probe(const struct hc_driver *driver,
struct resource *res;
int irq;
int retval;
-   unsigned int temp;
 
pr_debug(initializing FSL-SOC USB Controller\n);
 
@@ -126,18 +125,6 @@ static int usb_hcd_fsl_probe(const struct hc_driver 
*driver,
goto err3;
}
 
-   /*
-* Check if it is MPC5121 SoC, otherwise set pdata-have_sysif_regs
-* flag for 83xx or 8536 system interface registers.
-*/
-   if (pdata-big_endian_mmio)
-   temp = in_be32(hcd-regs + FSL_SOC_USB_ID);
-   else
-   temp = in_le32(hcd-regs + FSL_SOC_USB_ID);
-
-   if ((temp  ID_MSK) != (~((temp  NID_MSK)  8)  ID_MSK))
-   pdata-have_sysif_regs = 1;
-
/* Enable USB controller, 83xx or 8536 */
if (pdata-have_sysif_regs)
setbits32(hcd-regs + FSL_SOC_USB_CTRL, 0x4);
diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
index 2c83537..3fabed3 100644
--- a/drivers/usb/host/ehci-fsl.h
+++ b/drivers/usb/host/ehci-fsl.h
@@ -19,9 +19,6 @@
 #define _EHCI_FSL_H
 
 /* offsets for the non-ehci registers in the FSL SOC USB controller */
-#define FSL_SOC_USB_ID 0x0
-#define ID_MSK 0x3f
-#define NID_MSK0x3f00
 #define FSL_SOC_USB_ULPIVP 0x170
 #define FSL_SOC_USB_PORTSC10x184
 #define PORT_PTS_MSK   (330)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 574b99e..341fa81 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -262,19 +262,24 @@ static void fsl_usb2_mpc5121_exit(struct platform_device 
*pdev)
}
 }
 
-struct fsl_usb2_platform_data fsl_usb2_mpc5121_pd = {
+static struct fsl_usb2_platform_data fsl_usb2_mpc5121_pd = {
.big_endian_desc = 1,
.big_endian_mmio = 1,
.es = 1,
+   .have_sysif_regs = 0,
.le_setup_buf = 1,
.init = fsl_usb2_mpc5121_init,
.exit = fsl_usb2_mpc5121_exit,
 };
 #endif /* CONFIG_PPC_MPC512x */
 
+static struct fsl_usb2_platform_data fsl_usb2_mpc8xxx_pd = {
+   .have_sysif_regs = 1,
+};
+
 static const struct of_device_id fsl_usb2_mph_dr_of_match[] = {
-   { .compatible = fsl-usb2-mph, },
-   { .compatible = fsl-usb2-dr, },
+   { .compatible = fsl-usb2-mph, .data = fsl_usb2_mpc8xxx_pd, },
+   { .compatible = fsl-usb2-dr, .data = fsl_usb2_mpc8xxx_pd, },
 #ifdef CONFIG_PPC_MPC512x
{ .compatible = fsl,mpc5121-usb2-dr, .data = fsl_usb2_mpc5121_pd, },
 #endif
-- 
1.7.0.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] KVM: PPC: Fix SPRG get/set for Book3S and BookE

[Peter Tyser]

Previously SPRGs 4-7 were improperly read and written in
kvm_arch_vcpu_ioctl_get_regs() and kvm_arch_vcpu_ioctl_set_regs();

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
I noticed this while grepping for somthing unrelated and assume its
a typo.  Feel free to add to the patch description; I don't use KVM
so don't know what the high-level consequences of this change are.

 arch/powerpc/kvm/book3s.c |   14 --
 arch/powerpc/kvm/booke.c  |   14 --
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index e316847..5eb86c9 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -1141,9 +1141,10 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, 
struct kvm_regs *regs)
regs-sprg1 = vcpu-arch.shared-sprg1;
regs-sprg2 = vcpu-arch.shared-sprg2;
regs-sprg3 = vcpu-arch.shared-sprg3;
-   regs-sprg5 = vcpu-arch.sprg4;
-   regs-sprg6 = vcpu-arch.sprg5;
-   regs-sprg7 = vcpu-arch.sprg6;
+   regs-sprg4 = vcpu-arch.sprg4;
+   regs-sprg5 = vcpu-arch.sprg5;
+   regs-sprg6 = vcpu-arch.sprg6;
+   regs-sprg7 = vcpu-arch.sprg7;
 
for (i = 0; i  ARRAY_SIZE(regs-gpr); i++)
regs-gpr[i] = kvmppc_get_gpr(vcpu, i);
@@ -1167,9 +1168,10 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, 
struct kvm_regs *regs)
vcpu-arch.shared-sprg1 = regs-sprg1;
vcpu-arch.shared-sprg2 = regs-sprg2;
vcpu-arch.shared-sprg3 = regs-sprg3;
-   vcpu-arch.sprg5 = regs-sprg4;
-   vcpu-arch.sprg6 = regs-sprg5;
-   vcpu-arch.sprg7 = regs-sprg6;
+   vcpu-arch.sprg4 = regs-sprg4;
+   vcpu-arch.sprg5 = regs-sprg5;
+   vcpu-arch.sprg6 = regs-sprg6;
+   vcpu-arch.sprg7 = regs-sprg7;
 
for (i = 0; i  ARRAY_SIZE(regs-gpr); i++)
kvmppc_set_gpr(vcpu, i, regs-gpr[i]);
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 77575d0..ef76acb 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -546,9 +546,10 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, 
struct kvm_regs *regs)
regs-sprg1 = vcpu-arch.shared-sprg1;
regs-sprg2 = vcpu-arch.shared-sprg2;
regs-sprg3 = vcpu-arch.shared-sprg3;
-   regs-sprg5 = vcpu-arch.sprg4;
-   regs-sprg6 = vcpu-arch.sprg5;
-   regs-sprg7 = vcpu-arch.sprg6;
+   regs-sprg4 = vcpu-arch.sprg4;
+   regs-sprg5 = vcpu-arch.sprg5;
+   regs-sprg6 = vcpu-arch.sprg6;
+   regs-sprg7 = vcpu-arch.sprg7;
 
for (i = 0; i  ARRAY_SIZE(regs-gpr); i++)
regs-gpr[i] = kvmppc_get_gpr(vcpu, i);
@@ -572,9 +573,10 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, 
struct kvm_regs *regs)
vcpu-arch.shared-sprg1 = regs-sprg1;
vcpu-arch.shared-sprg2 = regs-sprg2;
vcpu-arch.shared-sprg3 = regs-sprg3;
-   vcpu-arch.sprg5 = regs-sprg4;
-   vcpu-arch.sprg6 = regs-sprg5;
-   vcpu-arch.sprg7 = regs-sprg6;
+   vcpu-arch.sprg4 = regs-sprg4;
+   vcpu-arch.sprg5 = regs-sprg5;
+   vcpu-arch.sprg6 = regs-sprg6;
+   vcpu-arch.sprg7 = regs-sprg7;
 
for (i = 0; i  ARRAY_SIZE(regs-gpr); i++)
kvmppc_set_gpr(vcpu, i, regs-gpr[i]);
-- 
1.7.0.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support

[Peter Tyser]

Hi Timur,

 +/**
 + * Global Utility Registers.
 + *
 + * Not all registers defined in this structure are available on all chips, so
 + * you are expected to know whether a given register actually exists on your
 + * chip before you access it.
 + *
 + * Also, some registers are similar on different chips but have slightly
 + * different names.  In these cases, one name is chosen to avoid extraneous
 + * #ifdefs.
 + */
 +#ifdef CONFIG_PPC_85xx
 +struct ccsr_guts_85xx {
 +#else
 +struct ccsr_guts_86xx {
 +#endif

Is there a good reason to have 2 different names for the same structure
depending on the architecture?  I'd think keeping a common ccsr_guts
name would get rid of the ifdefs above as well as in code that can be
used on both 85xx and 86xx processors down the road.

Best,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] MPC85xx: add definitions for PCI error detection soc part

[Peter Tyser]

Hi Dmitry,

On Thu, 2010-07-22 at 04:03 +0400, Dmitry Eremin-Solenikov wrote:
 Add definitions for PCI error detection device to be handled by (already
 existing) mpc85xx_edac.c driver.
 
 Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
 ---
  arch/powerpc/boot/dts/mpc8536ds.dts|7 +++
  arch/powerpc/boot/dts/mpc8536ds_36b.dts|7 +++
  arch/powerpc/boot/dts/mpc8540ads.dts   |8 
  arch/powerpc/boot/dts/mpc8541cds.dts   |   14 ++
  arch/powerpc/boot/dts/mpc8544ds.dts|7 +++
  arch/powerpc/boot/dts/mpc8548cds.dts   |   14 ++
  arch/powerpc/boot/dts/mpc8555cds.dts   |   14 ++
  arch/powerpc/boot/dts/mpc8560ads.dts   |7 +++
  arch/powerpc/boot/dts/mpc8568mds.dts   |7 +++
  arch/powerpc/boot/dts/sbc8548.dts  |7 +++
  arch/powerpc/boot/dts/sbc8560.dts  |7 +++
  arch/powerpc/boot/dts/socrates.dts |7 +++
  arch/powerpc/boot/dts/stx_gp3_8560.dts |7 +++
  arch/powerpc/boot/dts/tqm8540.dts  |   10 ++
  arch/powerpc/boot/dts/tqm8541.dts  |7 +++
  arch/powerpc/boot/dts/tqm8548-bigflash.dts |7 +++
  arch/powerpc/boot/dts/tqm8548.dts  |7 +++
  arch/powerpc/boot/dts/tqm8555.dts  |7 +++
  arch/powerpc/boot/dts/tqm8560.dts  |7 +++
  arch/powerpc/boot/dts/xpedite5200.dts  |7 +++
  arch/powerpc/boot/dts/xpedite5200_xmon.dts |7 +++
  21 files changed, 172 insertions(+), 0 deletions(-)

It looks like the dts files for the MPC8572-based boards weren't
included in this change despite patch 2/2 adding support for them.  I'd
guess some other Freescale CPUs (eg P1020, P2020, etc) could be
supported by the same driver if you are inclined to add them to this
patch series.

Best,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] MPC85xx: add definitions for PCI error detection soc part

[Peter Tyser]

  On Thu, 2010-07-22 at 04:03 +0400, Dmitry Eremin-Solenikov wrote:
  Add definitions for PCI error detection device to be handled by (already
  existing) mpc85xx_edac.c driver.
 
  Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
  ---
   arch/powerpc/boot/dts/mpc8536ds.dts|7 +++
   arch/powerpc/boot/dts/mpc8536ds_36b.dts|7 +++
   arch/powerpc/boot/dts/mpc8540ads.dts   |8 
   arch/powerpc/boot/dts/mpc8541cds.dts   |   14 ++
   arch/powerpc/boot/dts/mpc8544ds.dts|7 +++
   arch/powerpc/boot/dts/mpc8548cds.dts   |   14 ++
   arch/powerpc/boot/dts/mpc8555cds.dts   |   14 ++
   arch/powerpc/boot/dts/mpc8560ads.dts   |7 +++
   arch/powerpc/boot/dts/mpc8568mds.dts   |7 +++
   arch/powerpc/boot/dts/sbc8548.dts  |7 +++
   arch/powerpc/boot/dts/sbc8560.dts  |7 +++
   arch/powerpc/boot/dts/socrates.dts |7 +++
   arch/powerpc/boot/dts/stx_gp3_8560.dts |7 +++
   arch/powerpc/boot/dts/tqm8540.dts  |   10 ++
   arch/powerpc/boot/dts/tqm8541.dts  |7 +++
   arch/powerpc/boot/dts/tqm8548-bigflash.dts |7 +++
   arch/powerpc/boot/dts/tqm8548.dts  |7 +++
   arch/powerpc/boot/dts/tqm8555.dts  |7 +++
   arch/powerpc/boot/dts/tqm8560.dts  |7 +++
   arch/powerpc/boot/dts/xpedite5200.dts  |7 +++
   arch/powerpc/boot/dts/xpedite5200_xmon.dts |7 +++
   21 files changed, 172 insertions(+), 0 deletions(-)
 
  It looks like the dts files for the MPC8572-based boards weren't
  included in this change despite patch 2/2 adding support for them.  I'd
  guess some other Freescale CPUs (eg P1020, P2020, etc) could be
  supported by the same driver if you are inclined to add them to this
  patch series.
 
 I just did a quick search for all dts including mpc8540-pci node and added
 respective mpc85xx-pci-error node. Current MPC85xx EDAC driver doesn't
 support error handling on PCI-E busses (which MPC8572 and other CPUs
 you mentioned have). I'll maybe look into PCI-E EDAC later. Also I don't have
 access to P10xx/P20xx manuals, so support for them may require some
 more time.

Thanks for the explanation.  I noticed this because patch 2/2 adds
support for the 8572 to the mpc85xx_pci_err_of_match[] table.  Sounds
like that was the bug instead of my comment above.

Best,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/4] edac: Remove unused mpc85xx debug code

[Peter Tyser]

On Thu, 2009-11-19 at 18:42 -0600, Peter Tyser wrote:
 Some unused, unsupported debug code existed in the mpc85xx EDAC driver
 that resulted in a build failure when CONFIG_EDAC_DEBUG was defined:
 
   drivers/edac/mpc85xx_edac.c: In function 'mpc85xx_mc_err_probe':
   drivers/edac/mpc85xx_edac.c:1031: error: implicit declaration of function 
 'edac_mc_register_mcidev_debug'
   drivers/edac/mpc85xx_edac.c:1031: error: 'debug_attr' undeclared (first use 
 in this function)
   drivers/edac/mpc85xx_edac.c:1031: error: (Each undeclared identifier is 
 reported only once
   drivers/edac/mpc85xx_edac.c:1031: error: for each function it appears in.)
 
 Signed-off-by: Peter Tyser pty...@xes-inc.com

snip

Any chance some of these will be picked up for 2.6.33?

I added Kumar on CC as I'm not sure if these should go through the EDAC
or PPC tree.

1/4 fixes a build error when CONFIG_EDAC_DEBUG is defined and is pretty
trivial.

2/4 fixes a regression which results in ECC detection not working.

3/4 and 4/4 are improvements, but don't necessarily need to go into
2.6.33.

Best,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/85xx: Fix SMP when cpu-release-addr is in lowmem

[Peter Tyser]

On Fri, 2009-12-18 at 16:50 -0600, Peter Tyser wrote:
 Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
 the cpu-release-addr device tree property to contain the physical RAM
 location that secondary cores were spinning at.  Previously, the
 cpu-release-addr property contained a value referencing the boot page
 translation address range of 0xfxxx, which then indirectly accessed
 RAM.
 
 The cpu-release-addr is currently ioremapped and the secondary cores
 kicked.  However, due to the recent change in cpu-release-addr, it
 sometimes points to a memory location in low memory that cannot be
 ioremapped.  For example on a P2020-based board with 512MB of RAM the
 following error occurs on bootup:
 
   ...
   mpic: requesting IPIs ...
   __ioremap(): phys addr 0x1000 is RAM lr c05df9a0
   Unable to handle kernel paging request for data at address 0x0014
   Faulting instruction address: 0xc05df9b0
   Oops: Kernel access of bad area, sig: 11 [#1]
   SMP NR_CPUS=2 P2020 RDB
   Modules linked in:
   ... eventual kernel panic
 
 Adding logic to conditionally ioremap or access memory directly resolves
 the issue.
 
 Signed-off-by: Peter Tyser pty...@xes-inc.com
 Signed-off-by: Nate Case nc...@xes-inc.com
 Reported-by: Dipen Dudhat b09...@freescale.com
 Tested-by: Dipen Dudhat b09...@freescale.com

Any chance this going to be picked up for 2.6.33?  The issue is
currently going to bite anyone using an MP-capable 85xx system that
doesn't use highmem.

Thanks,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

Hi Wolfgang,


The new FIT image type should become the default, and old legacy
images should only be generated upon special request (i. e. if some-
one needs these for compatibility with an old, not yet FIT-aware
version of the boot loader).


Agreed.


What do you think about changing the U-Boot documentation to rename
those 2 image types to:
1 uImages
2 FIT Images


Let's make this uImage.old (or uImage.legacy similar) and
uImage, then.


I'm in favor of keeping the old uImage format/naming the same, and 
calling the new image format a FIT Image.  ie no mention of uImage for 
FIT images.


snip


uImages have to agree with U-Boot's header format defined in the U-Boot
source code, so the uImage name does make sense with respect to the
legacy uImages.


Well, you can read uImage as universal Image, which kind of fits
the FIT approach :-)


I agree that the FIT image is a type of universal Image, but I think 
FIT image is much more descriptive and accurate than universal 
Image.  The FIT naming convention is designed to match device tree 
naming, which has lots of meaning.  eg:

  Flattened Device Tree (FDT) - Flattened Image Tree (FIT)
  device tree source (.dts) - image tree source (.its)
  device tree blob (.dtb) - image tree blob (.itb)


My vote would be to make the Linux FIT target rule fitImage and then
update the U-Boot documentation to make obvious the differences between
uImages and FIT images.


I think we should not try to support both legacy and FIT images on the
same level - the idea is clearly that legacy images is the old, to be
replaced format, while FIT images is the new, to be used as standard
format.


Agreed.

In this sense I vote for using plain and simple uImage for

the (new) standard format, and marking the old format by some .old
or .legacy suffix.


I disagree here.  I don't think calling FIT images FIT uImages adds 
much value and it would add confusion as there are now multiple uImage 
formats that a user needs to keep straight.  Keeping the legacy uImage 
naming/format the same, and calling the new FIT images fitImage (or 
possibly itbImage to line up with the dtbImage target) would make more 
sense to me.  Is there a compelling reason to keep the uImage word 
connected to FIT images?


Best,
Peter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

snip


Note that the FIT image can also be made to contain a number of DT
blobs, and selection of a board profile then can be used to boot the
very sane FIT image file on any of the supported boards - so FIT
images inherently support multibooting.


I agree with Wolfgang.  Additionally, if a FIT image does contain a .dtb 
file, firmware can ignore it and load a different .dtb file.  So for the 
fitImage.boardname target you could think of it as including a 
default/fallback .dtb file, not a mandatory one.  So the FIT image 
could still be used as a multiplatform image even if it contained dtbs.



I see your point.  The main goal of the patch was to introduce FIT image
support as its the new, more flexible, better, standard image format
for U-Boot going forward.  Also, lots people aren't aware of FIT images
and the cool stuff they can do with them, so what better way to get the
word out than getting support for FIT images included in the kernel
proper:)


Define 'better'.  :-)


FIT images are better than the old uImage format because they:

- allow for strong checksum algorithms like MD5, SHA1, ... (the plain
   CRC32 method is not good enough if you for example want to run
   software in a slot machine in Las Vegas).

- can combine multiple kernel images, device tree blobs and root file
   system images in arbitrary combinations; this allows for example
   for multibooting the same image on different boards by selecting
   the right DTB, for software updates with automatic fall-back, etc.

- can be extended to add new features, images types or whatever in a
   standard way, using a standard technology (device tree support)
   which is already present anyway, i. e. without additional code
   overhead.


Other advantages of FIT images that I see day-to-day include:
- Adding meta-data such as timestamps and version information for each 
component of the FIT image.  Its great to be able to easily display the 
contents of a FIT image to determine which kernel versions it contains, etc.


- Embed multiple OS/dtb images in one FIT image.  As a board vendor its 
nice to give a customer 1 image that has example dtb(s) and Linux, 
VxWorks, QNX, diagnostic, etc kernels.  They can boot a number of OSes 
on a number of different boards with 1 image.


- You can extract the images contained in a FIT image using 'dtc' to 
convert the FIT image to a .dts file that has the raw image contents. 
 Other image formats are more difficult to extract contents from.


snip


I'd be okay (perhaps not happy, but okay) with merging fitImage and
fitImage.initrd targets (no dtb).  I will resist merging fitImage.%
and fitImage.initrd.% targets because I see that very much as a
project specific deployment target and I'm not convinced yet that it
the pattern is right or that it is even needed in the kernel at all.


Is this just your personal opinion, or do you think that this is
really what a majority of kernel developers and users are wanting?

Speaking for myself, I have to admit that I don't understand and don't
share this attitude.


I agree with Wolfgang that many people would find the combined 
kernel/dtb/ramfs useful, but understand Grant's reservations.  Assuming 
I rework the patch to include a fitImage (no dtb) target, for the 
users that basic multiplatform images are important to, they could build 
this kernel-only FIT image.  For people such as Wolfgang, Peter, and 
myself who would like to bundle a kernel + dtb(s), we could use the 
fitImage.boardname target.  Wouldn't both parties be happy then?  I 
could make the FIT documentation explain the benefits of multiplatform 
images or warn about the combined kernel/dtb FIT images if that made a 
difference too.


Best,
Peter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

Hi Wolfgang,

  IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
  Makefile so that make behaves more consistently.  Speaking of which,
  the number of '.' in the name is getting rather large.  Would you
  consider using 'fitImage' instead of 'uImage.fit'?
 
 Why chose a different name at all? We could still call it uImage,
 meaning U-Boot image - U-Boot is clever enought o detect
 automatically if we pass it an old style or a fit image.

I agree with your point to an extent, but having 2 types of uImages is
somewhat confusing to a user, even if U-Boot can differentiate between
them.  And if the legacy image and FIT image had the same Make target,
how does a user specify which type they want to build?  The fact that
both legacy and FIT images would reside at arch/powerpc/boot/uImage
doesn't make things any less confusing to Joe User.

Currently U-Boot supports booting:
1 legacy uImages
2 new Flattened Image Tree (FIT) uImages

What do you think about changing the U-Boot documentation to rename
those 2 image types to:
1 uImages
2 FIT Images

The FIT image is a relatively generic image type - its just a blob that
dtc created from a device tree and some input binaries.  In my mind its
not intimately tied to U-Boot, at least not conceptually.  The legacy
uImages have to agree with U-Boot's header format defined in the U-Boot
source code, so the uImage name does make sense with respect to the
legacy uImages.

My vote would be to make the Linux FIT target rule fitImage and then
update the U-Boot documentation to make obvious the differences between
uImages and FIT images.

What do you think of that?

Thanks,
Peter



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

Hi Grant,
I put U-Boot ML on CC.

On Wed, 2009-12-30 at 16:02 -0700, Grant Likely wrote:
 On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser pty...@xes-inc.com wrote:
  The PowerPC architecture has the ability to embed the ramdisk located
  at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image.  If
  the bootable kernel is in the Flattened Image Tree (FIT) format, the
  ramdisk should be a node in the tree instead of being embedded directly
  in the kernel executable.
 
  A FIT uImage with a ram filesystem can be generated using the command:
  make uImage.fit.initrd.boardname where boardname is one of
  arch/powerpc/boot/dts/boardname.dts.  The command will generate a FIT
  uImage at arch/powerpc/boot/uImage.fit.initrd.boardname that contains
  a kernel image, device tree blob, and a ram filesystem.
 
  The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older
  style ramdisk or a newer ramfs gzipped cpio archive.
 
  Signed-off-by: Peter Tyser pty...@xes-inc.com
  ---
  Changes since v1:
  - Don't strip leading 0x from dts ramdisk address
 
   arch/powerpc/boot/Makefile |3 +++
   arch/powerpc/boot/wrapper  |   20 
   scripts/mkits.sh   |   34 --
   3 files changed, 51 insertions(+), 6 deletions(-)
 
  diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
  index e56ec21..c2a6591 100644
  --- a/arch/powerpc/boot/Makefile
  +++ b/arch/powerpc/boot/Makefile
  @@ -313,6 +313,9 @@ $(obj)/uImage: vmlinux $(wrapperbits)
   $(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
 $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
 
  +$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
  +   $(call 
  if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
  +
 
 IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
 Makefile so that make behaves more consistently.

Makes sense.

 Speaking of which,
 the number of '.' in the name is getting rather large.  Would you
 consider using 'fitImage' instead of 'uImage.fit'?

Sure, I don't have a strong opinion about the name.  I settled on
uImage.fit because all the U-Boot documentation describes the FIT images
as type of uImage.  Eg the readme is located in doc/uImage.fit, its
referred to as the new uImage format, etc.  So using the
uimage.fit.* name goes along with the concept that a FIT image is a
type of uImage.  A target like fitImage loses the uImage-FIT
connection.

But I do agree that .s are a bit overwhelming.  I could rework these
patches with your suggested fitImage target name and follow-up with
U-Boot patches to clear up its documentation.  In my opinion, there's
not much reason to keep the uImage-FIT connection that currently
exists in U-Boot.  Right now U-Boot documents the Legacy uImage and
FIT uImage format when logically it would make sense to rename the
formats to uImage and FIT as there isn't much in common between the
2 formats.  The FIT image is just a blob generated by the device tree
compiler, its not tied to U-Boot in any way.

Does anyone in the U-Boot community have an opinion about this?  I'm
fine with keeping the uImage.fit naming or using fitImage for this
patch, but I think U-Boot's documentation should be on the same page
either way.

Thanks for the review,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
 On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser pty...@xes-inc.com wrote:
  Hi Grant,
  I put U-Boot ML on CC.
 
 Thinking further, I do actually have another concern, at least with
 regard to the way the current patch set implements things.  Is it
 expected or even recommended that fit images will *always* contain a
 .dtb image?  The current patch only handles the case of a .dtb
 embedded inside the fit image.

I'm not aware of any recommendations as far as what FIT images should
contain and there isn't a requirement that it should contain a .dtb
image - its just a flexible image format.

I believe in the most common FIT usage scenario the image would contain
both a kernel image and .dtb file though.  For example, most people I
deal with just have boardX and boardY that they want to boot Linux on.

Currently they have to make a legacy uImage, manually run the device
tree compiler with the proper flags to generate a board-specific .dtb
file, transfer the uImage to to boardX, transfer the .dtb file to
boardX, set some U-Boot variables, then boot to Linux.  For boardY they
would have to redo the steps with the exception of recreating the legacy
uImage.  (To add to the confusion, the format of device trees is a
somewhat moving target, so .dtb files aren't always compatible with
different kernel versions.)

The FIT+.dtb patches I sent make it so the same process is shortened to:
make a FIT image for boardX which contains a .dtb, download it to
boardX, and boot it.  Then repeat the same steps for boardY.

 Personally, I don't get any benefit out of the new image format, so I
 haven't spent any time looking at it.  However, I'm concerned about
 the drift back towards a different image per target when the move over
 the last 4 years has been towards multiplatform kernel images.  I
 certainly don't want to encourage embedding the device tree blob into
 the kernel image, and I'm not very interested in merging code to do
 that into the kernel tree.  If someone really needs to do that for
 their particular target, it is certainly easy enough for them to weld
 in the .dtb after the fact before transferring the image to the
 target, but I want that mode to be the exception, not the rule.

I see your point.  The main goal of the patch was to introduce FIT image
support as its the new, more flexible, better, standard image format
for U-Boot going forward.  Also, lots people aren't aware of FIT images
and the cool stuff they can do with them, so what better way to get the
word out than getting support for FIT images included in the kernel
proper:)

I think it would be nice to generate a FIT image that contained the
kernel + .dtb as it significantly simplifies the process of booting
Linux for the common case for lots of U-Boot users and showcases one of
the benefits of the FIT format.  If you'd prefer not to have this
portion of the patch included, I can respin so that the FIT image
created only contains a kernel image, not a .dtb or initramfs.  Or I
could make targets of fitImage (no dtb included), fitImage.board (dtb
included), and fitImage.initrd.board (dtb and initramfs included).
Either way is fine with me, it'd just be nice to see FIT support get in
in some form.

Thanks,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 1/3] powerpc: Use scripts/mkuboot.sh instead of 'mkimage'

[Peter Tyser]

mkuboot.sh provides a basic wrapper for the 'mkimage' utility.  Using
mkuboot.sh provides clearer error reporting and allows a toolchain to
use its own 'mkimage' executable specified by ${CROSS_COMPILE}mkimage.
Additionally, this brings PowerPC in line with other architectures
which already call mkimage via mkuboot.sh.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
 arch/powerpc/boot/wrapper |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 390512a..f4594ed 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -43,6 +43,9 @@ gzip=.gz
 # cross-compilation prefix
 CROSS=
 
+# mkimage wrapper script
+MKIMAGE=$srctree/scripts/mkuboot.sh
+
 # directory for object and other files used by this script
 object=arch/powerpc/boot
 objbin=$object
@@ -267,7 +270,7 @@ membase=`${CROSS}objdump -p $kernel | grep -m 1 LOAD | 
awk '{print $7}'`
 case $platform in
 uboot)
 rm -f $ofile
-mkimage -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
+${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
$uboot_version -d $vmz $ofile
 if [ -z $cacheit ]; then
rm -f $vmz
@@ -327,7 +330,7 @@ coff)
 ;;
 cuboot*)
 gzip -f -9 $ofile
-mkimage -A ppc -O linux -T kernel -C gzip -a $base -e $entry \
+${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $base -e $entry \
 $uboot_version -d $ofile.gz $ofile
 ;;
 treeboot*)
-- 
1.6.2.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 0/3] powerpc: Add support for FIT uImages

[Peter Tyser]

These patches add support for creating the new FIT uImage type
that U-Boot can use.  Additional info about FIT images can be
found in the doc/uImage.FIT/ directory of the U-Boot source.
Here's a link to a howto which gives an overview of the format:
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=doc/uImage.FIT/howto.txt;h=8065e9e1d8d4d65a9b5fe0fce08d3709183d0ee4;hb=HEAD

I've only added support for PowerPC, but the arm, avr32, blackfin,
and sh arches could use the same framework in theory.  The change
is especially useful on PowerPC since it creates 1 FIT uImage that
combines the functionality of an old uImage format, a device
tree blob, and possibly a ramdisk.

Changes since v1:
- Add 'dts-v1' header to scripts/mkits.sh output
- Don't strip leading 0x from dts addresses
- Default to using kernel dtc if the user doesn't have it in their path

Peter Tyser (3):
  powerpc: Use scripts/mkuboot.sh instead of 'mkimage'
  powerpc: Add support for creating FIT uImages
  powerpc: Add support for ram filesystems in FIT uImages

 arch/powerpc/Makefile|4 +-
 arch/powerpc/boot/.gitignore |1 +
 arch/powerpc/boot/Makefile   |8 ++-
 arch/powerpc/boot/wrapper|   43 +++--
 scripts/mkits.sh |  141 ++
 5 files changed, 190 insertions(+), 7 deletions(-)
 create mode 100755 scripts/mkits.sh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 2/3] powerpc: Add support for creating FIT uImages

[Peter Tyser]

Recent U-Boot versions support booting a Flattened Image Tree (FIT)
image format.  The FIT uImage format uses a tree structure to describe a
kernel image as well as supporting device tree blobs, ramdisks, etc.
The 'mkimage' and 'dtc' utilities convert this tree description into a
binary blob that bootloaders such as U-Boot can execute.

This patch adds support for automatically creating a U-Boot FIT image
using the make uImage.fit.boardname command where boardname is
one of arch/powerpc/boot/dts/boardname.dts.  The resulting
arch/powerpc/boot/uImage.fit.boardname file will contain a kernel
image as well as a device tree blob.  U-Boot versions compiled with FIT
support can directly boot this image using the bootm command.

Additional information about the FIT format and its uses can be found in
doc/uImage.FIT/howto.txt of U-Boot's source tree.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Changes since v1:
- Add 'dts-v1' header to scripts/mkits.sh output
- Don't strip leading 0x from dts addresses
- Default to using kernel dtc if the user doesn't have it in their path

 arch/powerpc/Makefile|4 +-
 arch/powerpc/boot/.gitignore |1 +
 arch/powerpc/boot/Makefile   |5 ++-
 arch/powerpc/boot/wrapper|   20 +++-
 scripts/mkits.sh |  111 ++
 5 files changed, 138 insertions(+), 3 deletions(-)
 create mode 100755 scripts/mkits.sh

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 1a54a3b..459aed5 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -158,7 +158,8 @@ drivers-$(CONFIG_OPROFILE)  += arch/powerpc/oprofile/
 # Default to zImage, override when needed
 all: zImage
 
-BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% 
cuImage.% simpleImage.%
+BOOT_TARGETS = zImage zImage.initrd uImage uImage.fit.% zImage% dtbImage% \
+  treeImage.% cuImage.% simpleImage.%
 
 PHONY += $(BOOT_TARGETS)
 
@@ -185,6 +186,7 @@ define archhelp
   @echo '* zImage  - Build default images selected by kernel config'
   @echo '  zImage.*- Compressed kernel image 
(arch/$(ARCH)/boot/zImage.*)'
   @echo '  uImage  - U-Boot native image format'
+  @echo '  uImage.fit.dt - U-Boot Flattened Image Tree image format'
   @echo '  cuImage.dt- Backwards compatible U-Boot image for older'
   @echo 'versions which do not support device trees'
   @echo '  dtbImage.dt   - zImage with an embedded device tree blob'
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index 3d80c3e..a443f1c 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -19,6 +19,7 @@ kernel-vmlinux.strip.c
 kernel-vmlinux.strip.gz
 mktree
 uImage
+uImage.fit.*
 cuImage.*
 dtbImage.*
 treeImage.*
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index bb2465b..e56ec21 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -310,6 +310,9 @@ $(obj)/zImage.iseries: vmlinux
 $(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
 
+$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
+   $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
+
 $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
 
@@ -349,7 +352,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
 
 # anything not in $(targets)
 clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
-   zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
+   uImage.* zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
simpleImage.* otheros.bld *.dtb
 
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index f4594ed..1f35b66 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -46,6 +46,9 @@ CROSS=
 # mkimage wrapper script
 MKIMAGE=$srctree/scripts/mkuboot.sh
 
+# script to generate an .its file for uImage.fit.* images
+MKITS=$srctree/scripts/mkits.sh
+
 # directory for object and other files used by this script
 object=arch/powerpc/boot
 objbin=$object
@@ -157,7 +160,7 @@ coff)
 lds=$object/zImage.coff.lds
 link_address='0x50'
 ;;
-miboot|uboot)
+miboot|uboot|uboot.fit)
 # miboot and U-boot want just the bare bits, not an ELF binary
 ext=bin
 objflags=-O binary
@@ -277,6 +280,21 @@ uboot)
 fi
 exit 0
 ;;
+uboot.fit)
+rm -f $ofile
+${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+   -d $srctree/$dtb -k $srctree/$vmz -o $object/uImage.its
+
+# mkimage calls dtc for FIT images so use kernel dtc if necessary
+export PATH=$PATH:$srctree/scripts/dtc
+
+${MKIMAGE} -f $object/uImage.its $ofile
+rm $object/uImage.its
+if [ -z $cacheit ]; then
+   rm -f $vmz
+fi
+exit 0
+;;
 esac
 
 addsec() {
diff

[PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

The PowerPC architecture has the ability to embed the ramdisk located
at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image.  If
the bootable kernel is in the Flattened Image Tree (FIT) format, the
ramdisk should be a node in the tree instead of being embedded directly
in the kernel executable.

A FIT uImage with a ram filesystem can be generated using the command:
make uImage.fit.initrd.boardname where boardname is one of
arch/powerpc/boot/dts/boardname.dts.  The command will generate a FIT
uImage at arch/powerpc/boot/uImage.fit.initrd.boardname that contains
a kernel image, device tree blob, and a ram filesystem.

The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older
style ramdisk or a newer ramfs gzipped cpio archive.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Changes since v1:
- Don't strip leading 0x from dts ramdisk address

 arch/powerpc/boot/Makefile |3 +++
 arch/powerpc/boot/wrapper  |   20 
 scripts/mkits.sh   |   34 --
 3 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e56ec21..c2a6591 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -313,6 +313,9 @@ $(obj)/uImage: vmlinux $(wrapperbits)
 $(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
 
+$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
+   $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
+
 $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
 
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 1f35b66..9ccaef7 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -270,6 +270,9 @@ fi
 # physical offset of kernel image
 membase=`${CROSS}objdump -p $kernel | grep -m 1 LOAD | awk '{print $7}'`
 
+# Size of uncompressed kernel is needed to calculate ramdisk location in RAM
+kernsize=`${CROSS}objdump -p $kernel | grep -m 1 rwx | awk '{print $4}'`
+
 case $platform in
 uboot)
 rm -f $ofile
@@ -282,8 +285,14 @@ uboot)
 ;;
 uboot.fit)
 rm -f $ofile
-${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
-   -d $srctree/$dtb -k $srctree/$vmz -o $object/uImage.its
+if [ -n $initrd ]; then
+   ${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+   -d $srctree/$dtb -k $srctree/$vmz -r $srctree/$initrd \
+   -l $kernsize -o $object/uImage.its
+else
+   ${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+   -d $srctree/$dtb -k $srctree/$vmz -o $object/uImage.its
+fi
 
 # mkimage calls dtc for FIT images so use kernel dtc if necessary
 export PATH=$PATH:$srctree/scripts/dtc
@@ -308,8 +317,11 @@ if [ -z $cacheit ]; then
 rm -f $vmz
 fi
 
-if [ -n $initrd ]; then
-addsec $tmp $initrd $isection
+# FIT images have the initrd in the image tree structure
+if [ $platform != uboot.fit ]; then
+if [ -n $initrd ]; then
+   addsec $tmp $initrd $isection
+fi
 fi
 
 if [ -n $dtb ]; then
diff --git a/scripts/mkits.sh b/scripts/mkits.sh
index fae43dd..ffcf2c4 100755
--- a/scripts/mkits.sh
+++ b/scripts/mkits.sh
@@ -16,7 +16,8 @@
 
 usage() {
echo Usage: `basename $0` -A arch -C comp -a addr -e entry \
-   -v version -k kernel [-d dtb] -o its_file
+   -v version -k kernel [-d dtb] [-r ramfs -l ramfs_addr] \
+   -o its_file
echo -e \t-A == set architecture to 'arch'
echo -e \t-C == set compression type 'comp'
echo -e \t-a == set load address to 'addr' (hex)
@@ -24,11 +25,13 @@ usage() {
echo -e \t-v == set kernel version to 'version'
echo -e \t-k == include kernel image 'kernel'
echo -e \t-d == include Device Tree Blob 'dtb'
+   echo -e \t-r == include initrd/initramfs 'ramfs'
+   echo -e \t-l == load initrd/initramfs at 'ramfs_addr'
echo -e \t-o == create output file 'its_file'
exit 1
 }
 
-while getopts :A:C:a:d:e:k:o:v: OPTION
+while getopts :A:C:a:d:e:k:l:o:r:v: OPTION
 do
case $OPTION in
A ) ARCH=$OPTARG;;
@@ -37,7 +40,9 @@ do
d ) DTB=$OPTARG;;
e ) ENTRY_ADDR=$OPTARG;;
k ) KERNEL=$OPTARG;;
+   l ) RAMFS_ADDR=$OPTARG;;
o ) OUTPUT=$OPTARG;;
+   r ) RAMFS=$OPTARG;;
v ) VERSION=$OPTARG;;
* ) echo Invalid option passed to '$0' (options:$@)
usage;;
@@ -49,6 +54,8 @@ if [ -z ${ARCH} ] || [ -z ${COMPRESS} ] || [ -z 
${LOAD_ADDR} ] || \
[ -z ${ENTRY_ADDR} ] || [ -z ${VERSION} ] || [ -z ${KERNEL} ] || \
[ -z ${OUTPUT} ]; then
usage
+elif [ -n ${RAMFS} ]  [ -z ${RAMFS_ADDR} ]; then
+   usage
 fi
 
 # Create a default, fully

Re: [PATCH v2 2/3] powerpc: Add support for creating FIT uImages

[Peter Tyser]

Hi Olof,

On Mon, 2009-12-21 at 21:48 -0600, Olof Johansson wrote:
 Hi,
 
 On Mon, Dec 21, 2009 at 07:50:42PM -0600, Peter Tyser wrote:
  diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
  index bb2465b..e56ec21 100644
  --- a/arch/powerpc/boot/Makefile
  +++ b/arch/powerpc/boot/Makefile
  @@ -310,6 +310,9 @@ $(obj)/zImage.iseries: vmlinux
   $(obj)/uImage: vmlinux $(wrapperbits)
  $(call if_changed,wrap,uboot)
   
  +$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
  +   $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
  +
   $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
  $(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
   
  @@ -349,7 +352,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
   
   # anything not in $(targets)
   clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
  -   zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
  +   uImage.* zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
 
 Please no. It's not entirely uncommon that I will save a known good
 binary in the build tree for a while, by copying it aside with a different
 suffix. That'd give me one very big surprise in this case.

You're right that it'd probably be better if the clean pattern was
uImage.fit.* to be more restrictive, but your concern would still exist,
as it does for a number of other image formats already (cuImage.*,
simpleImage.*, etc).  I can't think of a way to work around that issue
though...  Any ideas?  Don't keep backup images in arch/powerpc/boot?:)

Thanks for the feedback,
Peter



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/85xx: Fix SMP when cpu-release-addr is in lowmem

[Peter Tyser]

Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
the cpu-release-addr device tree property to contain the physical RAM
location that secondary cores were spinning at.  Previously, the
cpu-release-addr property contained a value referencing the boot page
translation address range of 0xfxxx, which then indirectly accessed
RAM.

The cpu-release-addr is currently ioremapped and the secondary cores
kicked.  However, due to the recent change in cpu-release-addr, it
sometimes points to a memory location in low memory that cannot be
ioremapped.  For example on a P2020-based board with 512MB of RAM the
following error occurs on bootup:

  ...
  mpic: requesting IPIs ...
  __ioremap(): phys addr 0x1000 is RAM lr c05df9a0
  Unable to handle kernel paging request for data at address 0x0014
  Faulting instruction address: 0xc05df9b0
  Oops: Kernel access of bad area, sig: 11 [#1]
  SMP NR_CPUS=2 P2020 RDB
  Modules linked in:
  ... eventual kernel panic

Adding logic to conditionally ioremap or access memory directly resolves
the issue.

Signed-off-by: Peter Tyser pty...@xes-inc.com
Signed-off-by: Nate Case nc...@xes-inc.com
Reported-by: Dipen Dudhat b09...@freescale.com
Tested-by: Dipen Dudhat b09...@freescale.com
---
 arch/powerpc/platforms/85xx/smp.c |   21 +++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/smp.c 
b/arch/powerpc/platforms/85xx/smp.c
index 04160a4..a15f582 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -46,6 +46,7 @@ smp_85xx_kick_cpu(int nr)
__iomem u32 *bptr_vaddr;
struct device_node *np;
int n = 0;
+   int ioremappable;
 
WARN_ON (nr  0 || nr = NR_CPUS);
 
@@ -59,21 +60,37 @@ smp_85xx_kick_cpu(int nr)
return;
}
 
+   /*
+* A secondary core could be in a spinloop in the bootpage
+* (0xf000), somewhere in highmem, or somewhere in lowmem.
+* The bootpage and highmem can be accessed via ioremap(), but
+* we need to directly access the spinloop if its in lowmem.
+*/
+   ioremappable = *cpu_rel_addr  virt_to_phys(high_memory);
+
/* Map the spin table */
-   bptr_vaddr = ioremap(*cpu_rel_addr, SIZE_BOOT_ENTRY);
+   if (ioremappable)
+   bptr_vaddr = ioremap(*cpu_rel_addr, SIZE_BOOT_ENTRY);
+   else
+   bptr_vaddr = phys_to_virt(*cpu_rel_addr);
 
local_irq_save(flags);
 
out_be32(bptr_vaddr + BOOT_ENTRY_PIR, nr);
out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
 
+   if (!ioremappable)
+   flush_dcache_range((ulong)bptr_vaddr,
+   (ulong)(bptr_vaddr + SIZE_BOOT_ENTRY));
+
/* Wait a bit for the CPU to ack. */
while ((__secondary_hold_acknowledge != nr)  (++n  1000))
mdelay(1);
 
local_irq_restore(flags);
 
-   iounmap(bptr_vaddr);
+   if (ioremappable)
+   iounmap(bptr_vaddr);
 
pr_debug(waited %d msecs for CPU #%d.\n, n, nr);
 }
-- 
1.6.2.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins

[Peter Tyser]

Hi Anton,
I've CC-ed devicetree-discuss.  The original patch is at
http://patchwork.ozlabs.org/patch/40361/ for reference.

On Sat, 2009-12-05 at 23:51 +0300, Anton Vorontsov wrote:
 On Sat, Dec 05, 2009 at 01:32:32PM -0600, Peter Tyser wrote:
 [...]
Adding a new fsl,gpio-mask device tree property allows a dts file to
accurately describe what GPIO pins are available for use on a given
board.
   
   I don't see any real usage for this. If device tree specifies a wrong
   gpio in the gpios =  property, then it's a bug in the device tree
   and should be fixed (or workarounded in the platform code).
   
   If a user fiddles with unknown gpios via sysfs interface, then it's
   user's problem.
  
  Its the sysfs case that I'm concerned about.  Primarily because:
  1. Users scratch their head when they see that the ngpio sysfs value
  doesn't match their CPU manual or board vendor's manual, and
  subsequently ask their board vendor's engineers (ie me:) what's up.
 
 I don't think that adding code and device tree entries just for
 documentation purposes is a good idea.

Its not just for documentation purposes.  Right now, the sysfs ngpio
value is flat out wrong for some processors, regardless of
documentation.  Granted its not a critical bug, but I'd still consider
it a bug.

  2. Improperly using GPIO pins could damage hardware for some boards.
 
 Well, your initial patch tried to solve a different problem: to not
 let users to request non-existent GPIOs, which is usually safe.

I can update the commit message with this rational if it makes a
difference.

 [...]
  #2 could be worked around by exporting GPIO pins in platform code so
  that they are not available via sysfs.
 
 Yes, badly designed hardware deserves ugly hacks in the platform
 code. ;-) So for this problem, just request these gpios in the
 platform code.

I'd wager lots of boards have GPIO pins that a user shouldn't play
around with once Linux boots up.  Like GPIO pins used to program an
FPGA, or control a PLL, etc.  1 device tree property is nicer than
hacking up lots of platform code...

  Would it be any more acceptable to instead add
  a fsl,num-gpio property so that ngpio actually reported an accurate
  value and non-existent GPIO pins couldn't be used/exported?
 
 I'd think it's actually less acceptable. fsl,gpio-mask is more generic,
 since from gpio-mask you can deduce ngpio. But it's still ugly.
 
 What would be OK to do is to describe in the device tree every
 device that is using some GPIO, and then let the userspace request
 *only* gpios that are described in the device-tree. That way you
 can automatically exclude not-existent gpios.
 And if some gpios are just headers on the board, you can still
 describe them in the device tree via gpio-header nodes.
 
 Still, a lot of efforts for no real gain...

Agreed.  Seems like a clean solution, but is a chunk of work.

In any case, my high-level thought process is:
1. Currently, the ngpio value is wrong for some processors and should
be fixed.
2. Adding a new fsl,gpio-mask gpio solves #1, and has the benefit of
allowing the device tree to easily reserve GPIO pins which should not be
used in Linux.

I guess I'm not seeing the big downside of a new fsl,gpio-mask
property.  Its the device tree's job to describe the hardware.  The
change is pretty minimal (~15 lines), and the property can be made
optional.

Or is there another suggestion on how to resolve #1 above?  I consider
it a bug and would like to fix it.

Best,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins

[Peter Tyser]

Hi Anton,
Thanks for the feedback.

 On Fri, Dec 04, 2009 at 01:43:40PM -0600, Peter Tyser wrote:
  This change resolves 2 issues:
  - Different chips have a different number of GPIO pins per controller.
For example, the MPC8347 has 32, the P2020 16, and the mpc8572 8.
Previously, the mpc8xxx_gpio driver assumed every chip had 32 GPIO
pins which resulted in some processors reporting an incorrect 'ngpio'
field in /sys.  Additionally, users could export and use 32 GPIO
pins, although in reality only a subset of the 32 pins had any real
functionality.
  
  - Some boards don't utilize all available GPIO pins.  Previously,
unused GPIO pins could still be exported and used, even though the
pins had no real functionality.  This is somewhat confusing to a user
and also allow a user to do something bad, like change an unused
floating output into a floating input.
 
 There are hundreds of other ways to screw things up.
 
 Think of /dev/mem, you still able to change the registers.
 Before changing any GPIO (whether it is a normal or reserved GPIO),
 user has to consult with schematics/docs.

Agreed.  This is an attempt to make it just a little bit harder to
accidentally screw things up and to make the ngpio sysfs value
actually contain an accurate value.

  Adding a new fsl,gpio-mask device tree property allows a dts file to
  accurately describe what GPIO pins are available for use on a given
  board.
 
 I don't see any real usage for this. If device tree specifies a wrong
 gpio in the gpios =  property, then it's a bug in the device tree
 and should be fixed (or workarounded in the platform code).
 
 If a user fiddles with unknown gpios via sysfs interface, then it's
 user's problem.

Its the sysfs case that I'm concerned about.  Primarily because:
1. Users scratch their head when they see that the ngpio sysfs value
doesn't match their CPU manual or board vendor's manual, and
subsequently ask their board vendor's engineers (ie me:) what's up.

2. Improperly using GPIO pins could damage hardware for some boards.
For example, some of our boards have a voltage regulator controlled via
GPIO pins so that a CPU's core voltage can be changed based on its
frequency, etc.  A user could damage their CPU if they aren't careful
with those GPIO pins.  For pins like that, it'd be nice to not even let
users play with them.

#2 could be worked around by exporting GPIO pins in platform code so
that they are not available via sysfs.  And I agree that if a user is
playing with GPIO pins, they had better know what they are doing, so #1
above is my main issue.  Would it be any more acceptable to instead add
a fsl,num-gpio property so that ngpio actually reported an accurate
value and non-existent GPIO pins couldn't be used/exported?

With the patch as is, if fsl,gpio-mask is not given, the driver
defaults to enabling all 32 gpio pins.  Would it be any better if I
respun the patch to only add the fsl,gpio-mask property for the
mpc8572, p2020, and mpc8379 boards which have less than 32 gpio pins and
document the dts property as optional?

Thanks,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins

[Peter Tyser]

This change resolves 2 issues:
- Different chips have a different number of GPIO pins per controller.
  For example, the MPC8347 has 32, the P2020 16, and the mpc8572 8.
  Previously, the mpc8xxx_gpio driver assumed every chip had 32 GPIO
  pins which resulted in some processors reporting an incorrect 'ngpio'
  field in /sys.  Additionally, users could export and use 32 GPIO
  pins, although in reality only a subset of the 32 pins had any real
  functionality.

- Some boards don't utilize all available GPIO pins.  Previously,
  unused GPIO pins could still be exported and used, even though the
  pins had no real functionality.  This is somewhat confusing to a user
  and also allow a user to do something bad, like change an unused
  floating output into a floating input.

Adding a new fsl,gpio-mask device tree property allows a dts file to
accurately describe what GPIO pins are available for use on a given
board.

Note that the 'ngpio' value reported in /sys will represent the
highest gpio pin accessible, not the total number of gpio pins
available.  For example, if a device only allowed the use of GPIO pin 3
(fsl,gpio-mask = 0x8), 'ngpio' would be reported as 4, although
only GPIO pin 3 could be exported and used.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
I don't know which GPIO pins are usable on Freescale boards.  Let me
know if the default mask for the reference boards should change.

Thanks,
Peter

 .../powerpc/dts-bindings/fsl/8xxx_gpio.txt |   11 ++--
 arch/powerpc/boot/dts/mpc8377_rdb.dts  |2 +
 arch/powerpc/boot/dts/mpc8377_wlan.dts |2 +
 arch/powerpc/boot/dts/mpc8378_rdb.dts  |2 +
 arch/powerpc/boot/dts/mpc8379_rdb.dts  |2 +
 arch/powerpc/boot/dts/p2020ds.dts  |1 +
 arch/powerpc/boot/dts/p2020rdb.dts |1 +
 arch/powerpc/boot/dts/xcalibur1501.dts |1 +
 arch/powerpc/boot/dts/xpedite5301.dts  |1 +
 arch/powerpc/boot/dts/xpedite5330.dts  |1 +
 arch/powerpc/boot/dts/xpedite5370.dts  |1 +
 arch/powerpc/sysdev/mpc8xxx_gpio.c |   24 ---
 12 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt 
b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
index d015dce..a8fac7f 100644
--- a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
@@ -11,9 +11,12 @@ Required properties:
   83xx, fsl,mpc8572-gpio for 85xx and fsl,mpc8610-gpio for 86xx.
 - #gpio-cells : Should be two. The first cell is the pin number and the
   second cell is used to specify optional parameters (currently unused).
- - interrupts : Interrupt mapping for GPIO IRQ (currently unused).
- - interrupt-parent : Phandle for the interrupt controller that
-   services interrupts for this device.
+- interrupts : Interrupt mapping for GPIO IRQ (currently unused).
+- interrupt-parent : Phandle for the interrupt controller that
+  services interrupts for this device.
+- fsl,gpio-mask: A bitmask representing which GPIO pins are availabe for
+  use.  For example, a value of 0x13 means GPIO pins 0, 1, and 4 are
+  usable.
 - gpio-controller : Marks the port as GPIO controller.
 
 Example of gpio-controller nodes for a MPC8347 SoC:
@@ -24,6 +27,7 @@ Example of gpio-controller nodes for a MPC8347 SoC:
reg = 0xc00 0x100;
interrupts = 74 0x8;
interrupt-parent = ipic;
+   fsl,gpio-mask = 0x;
gpio-controller;
};
 
@@ -33,6 +37,7 @@ Example of gpio-controller nodes for a MPC8347 SoC:
reg = 0xd00 0x100;
interrupts = 75 0x8;
interrupt-parent = ipic;
+   fsl,gpio-mask = 0x;
gpio-controller;
};
 
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts 
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 9e2264b..6152bfa 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -115,6 +115,7 @@
reg = 0xc00 0x100;
interrupts = 74 0x8;
interrupt-parent = ipic;
+   fsl,gpio-mask = 0x;
gpio-controller;
};
 
@@ -124,6 +125,7 @@
reg = 0xd00 0x100;
interrupts = 75 0x8;
interrupt-parent = ipic;
+   fsl,gpio-mask = 0x;
gpio-controller;
};
 
diff --git a/arch/powerpc/boot/dts/mpc8377_wlan.dts 
b/arch/powerpc/boot/dts/mpc8377_wlan.dts
index 9ea7830..a26535c 100644
--- a/arch/powerpc/boot/dts/mpc8377_wlan.dts
+++ b/arch/powerpc/boot/dts/mpc8377_wlan.dts
@@ -105,6 +105,7 @@
reg = 0xc00 0x100;
interrupts = 74 0x8

Re: [PATCH 2/3] powerpc: Add support for creating FIT uImages

[Peter Tyser]

Hi Stefano,

Stefano Babic wrote:

Peter Tyser ptyser wrote:


+# Create a default, fully populated DTS file
+DATA=/ {
+   description = \Linux kernel ${VERSION}\;
+   #address-cells = 1;
+
+   images {
+   kernel at 1 {


Is the at probably generated by your anti-spam mailer ? dtc seems not
to like it as replacement for the usual '@' ;)


The patch looks correct in my inbox and at 
http://patchwork.kernel.org/patch/61183/.  Perhaps its a problem at your 
end?


Please keep everyone cc-ed on responses - the changes are just as 
relevant to linuxppc as kbuild.


Best,
Peter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/3] powerpc: Add support for creating FIT uImages

[Peter Tyser]

Hi Stefano,
Thanks for trying the patches out.

On Tue, 2009-11-24 at 11:32 +0100, Stefano Babic wrote:
 Peter Tyser ptyser wrote:
  +uboot.fit)
  +rm -f $ofile
  +${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
  +   -d $srctree/$dtb -k $srctree/$vmz -o $object/uImage.its
  +${MKIMAGE} -f $object/uImage.its $ofile
 
 Hi,
 
 I have tested your patches against last mkimage utility provided with
 u-boot. The utility requires to pass the type of the image (flat_dt),
 even if this is not mentioned in the help output. Without the image type
 parameter, no image is generated, and no error is reported.
 It should be:
 
 ${MKIMAGE} -f $object/uImage.its - T flat_dt $ofile

Argh, I'm seeing the same behavior with the latest mkimage source too.
It looks like there was a regression in the mkimage utility - the -T
option shouldn't be necessary to create a FIT image.  I'll send a patch
to U-Boot to fix this behavior.

 I have tried to get an image for the lite5200b board, because I have the
 possibility to test the result on the target. However, dtc fails to
 compile the its generated by your script (Version: DTC 1.2.0-g0ef21055,
 cloned from jdt).

I did my testing using the dtc in the linux kernel source
(scripts/dtc/dtc, version 1.2.0) and version 1.2.0-rc1.  I see the same
error as you when using version 1.2.0-g0ef21055.

 DTC: dts-dtb  on file arch/powerpc/boot/uImage.its
 Error: arch/powerpc/boot/uImage.its 1:0 syntax error
 
 Do you test in different conditions ?

Applying the following change should resolve the dtc syntax error.

diff --git a/scripts/mkits.sh b/scripts/mkits.sh
index 88411dd..75edc27 100755
--- a/scripts/mkits.sh
+++ b/scripts/mkits.sh
@@ -64,7 +64,9 @@ ENTRY_ADDR=`echo $ENTRY_ADDR | sed 's/0x//'`
 RAMFS_ADDR=`echo $RAMFS_ADDR | sed 's/0x//'`
 
 # Create a default, fully populated DTS file
-DATA=/ {
+DATA=/dts-v1/;
+
+/ {
description = \Linux kernel ${VERSION}\;
#address-cells = 1;
 

I'll wait a few more days for feedback then resubmit with the dts syntax
fix

Thanks for testing,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/4] edac: Mask mpc85xx ECC syndrome appropriately

[Peter Tyser]

With a 64-bit wide data bus only the lowest 8-bits of the ECC syndrome
are relevant.  With a 32-bit wide data bus only the lowest 16-bits are
relevant on most architectures.

Without this change, the ECC syndrome displayed can be mildly confusing,
eg:

  EDAC MPC85xx MC1: syndrome: 0x25252525

When in reality the ECC syndrome is 0x25.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
A variety of Freescale manual's say a variety of different things about
how to decode the CAPTURE_ECC (syndrome) register.  I don't have a
system with a 32-bit bus to test on, but I believe the change is
correct.  It'd be good to get an ACK from someone at Freescale
about this change though.

 drivers/edac/mpc85xx_edac.c |   12 +++-
 drivers/edac/mpc85xx_edac.h |3 +++
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index ecd5928..6d0114a 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -672,6 +672,7 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
 {
struct mpc85xx_mc_pdata *pdata = mci-pvt_info;
struct csrow_info *csrow;
+   u32 bus_width;
u32 err_detect;
u32 syndrome;
u32 err_addr;
@@ -692,6 +693,15 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
}
 
syndrome = in_be32(pdata-mc_vbase + MPC85XX_MC_CAPTURE_ECC);
+
+   /* Mask off appropriate bits of syndrome based on bus width */
+   bus_width = (in_be32(pdata-mc_vbase + MPC85XX_MC_DDR_SDRAM_CFG) 
+   DSC_DBW_MASK) ? 32 : 64;
+   if (bus_width == 64)
+   syndrome = 0xff;
+   else
+   syndrome = 0x;
+
err_addr = in_be32(pdata-mc_vbase + MPC85XX_MC_CAPTURE_ADDRESS);
pfn = err_addr  PAGE_SHIFT;
 
@@ -707,7 +717,7 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
mpc85xx_mc_printk(mci, KERN_ERR, Capture Data Low: %#8.8x\n,
  in_be32(pdata-mc_vbase +
  MPC85XX_MC_CAPTURE_DATA_LO));
-   mpc85xx_mc_printk(mci, KERN_ERR, syndrome: %#8.8x\n, syndrome);
+   mpc85xx_mc_printk(mci, KERN_ERR, syndrome: %#2.2x\n, syndrome);
mpc85xx_mc_printk(mci, KERN_ERR, err addr: %#8.8x\n, err_addr);
mpc85xx_mc_printk(mci, KERN_ERR, PFN: %#8.8x\n, pfn);
 
diff --git a/drivers/edac/mpc85xx_edac.h b/drivers/edac/mpc85xx_edac.h
index 52432ee..cb24df8 100644
--- a/drivers/edac/mpc85xx_edac.h
+++ b/drivers/edac/mpc85xx_edac.h
@@ -48,6 +48,9 @@
 #define DSC_MEM_EN 0x8000
 #define DSC_ECC_EN 0x2000
 #define DSC_RD_EN  0x1000
+#define DSC_DBW_MASK   0x0018
+#define DSC_DBW_32 0x0008
+#define DSC_DBW_64 0x
 
 #define DSC_SDTYPE_MASK0x0700
 
-- 
1.6.2.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/4] edac: Fix mpc85xx page calculation

[Peter Tyser]

Commit b4846251727a38a7f248e41308c060995371dd05 accidentally broke how a
chip select's first and last page addresses are calculated.  The page
addresses are being shifted too far right by PAGE_SHIFT.  This results
in errors such as:

  EDAC MPC85xx MC1: Err addr: 0x003075c0
  EDAC MPC85xx MC1: PFN: 0x0307
  EDAC MPC85xx MC1: PFN out of range!
  EDAC MC1: INTERNAL ERROR: row out of range (4 = 4)
  EDAC MC1: CE - no information available: INTERNAL ERROR

The vale of PAGE_SHIFT is already being taken into consideration during
the calculation of the 'start' and 'end' variables, thus it is not
necessary to account for it again when setting a chip select's first and
last page address.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
 drivers/edac/mpc85xx_edac.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 28d3211..ecd5928 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -804,8 +804,8 @@ static void __devinit mpc85xx_init_csrows(struct 
mem_ctl_info *mci)
end   = (24 - PAGE_SHIFT);
end|= (1  (24 - PAGE_SHIFT)) - 1;
 
-   csrow-first_page = start  PAGE_SHIFT;
-   csrow-last_page = end  PAGE_SHIFT;
+   csrow-first_page = start;
+   csrow-last_page = end;
csrow-nr_pages = end + 1 - start;
csrow-grain = 8;
csrow-mtype = mtype;
-- 
1.6.2.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 4/4] edac: Improve SDRAM error reporting for mpc85xx

[Peter Tyser]

Add the ability to detect the specific data line or ECC line which
failed when printing out SDRAM single-bit errors.  An example of a
single-bit SDRAM ECC error is below:

  EDAC MPC85xx MC1: Err Detect Register: 0x8004
  EDAC MPC85xx MC1: Faulty data bit: 59
  EDAC MPC85xx MC1: Expected Data / ECC:  0x7f80d000_409effa0 / 0x6d
  EDAC MPC85xx MC1: Captured Data / ECC:  0x7780d000_409effa0 / 0x6d
  EDAC MPC85xx MC1: Err addr: 0x00031ca0
  EDAC MPC85xx MC1: PFN: 0x0031

Knowning which specific data or ECC line caused an error can be useful in
tracking down hardware issues such as improperly terminated signals,
loose pins, etc.

Note that this feature is only currently enabled for 64-bit wide data
buses, 32-bit wide bus support should be added.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
I don't have any 32-bit wide systems to test on.  If someone has one
and is willing to give this patch a shot with the check for a 64-bit
data bus removed it would be much appreciated and I can re-submit
with both 32 and 64 bit buses supported.

 drivers/edac/mpc85xx_edac.c |  146 ---
 1 files changed, 138 insertions(+), 8 deletions(-)

diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 6d0114a..517042f 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -668,6 +668,111 @@ static struct of_platform_driver mpc85xx_l2_err_driver = {
 
 / MC Err device ***/
 
+/*
+ * Taken from table 8-55 in the MPC8641 User's Manual and/or 9-61 in the
+ * MPC8572 User's Manual.  Each line represents a syndrome bit column as a
+ * 64-bit value, but split into an upper and lower 32-bit chunk.  The labels
+ * below correspond to Freescale's manuals.
+ */
+static unsigned int ecc_table[16] = {
+   /* MSB   LSB */
+   /* [0:31][32:63] */
+   0xf00fe11e, 0xc33c0ff7, /* Syndrome bit 7 */
+   0x00ff00ff, 0x00fff0ff,
+   0x0f0f0f0f, 0x0f0fff00,
+   0x, 0x000f,
+   0x, 0x222f,
+   0x, 0x4441,
+   0x, 0x8882,
+   0x, 0x1114, /* Syndrome bit 0 */
+};
+
+/*
+ * Calculate the correct ECC value for a 64-bit value specified by high:low
+ */
+static u8 calculate_ecc(u32 high, u32 low)
+{
+   u32 mask_low;
+   u32 mask_high;
+   int bit_cnt;
+   u8 ecc = 0;
+   int i;
+   int j;
+
+   for (i = 0; i  8; i++) {
+   mask_high = ecc_table[i * 2];
+   mask_low = ecc_table[i * 2 + 1];
+   bit_cnt = 0;
+
+   for (j = 0; j  32; j++) {
+   if ((mask_high  j)  1)
+   bit_cnt ^= (high  j)  1;
+   if ((mask_low  j)  1)
+   bit_cnt ^= (low  j)  1;
+   }
+
+   ecc |= bit_cnt  i;
+   }
+
+   return ecc;
+}
+
+/*
+ * Create the syndrome code which is generated if the data line specified by
+ * 'bit' failed.  Eg generate an 8-bit codes seen in Table 8-55 in the MPC8641
+ * User's Manual and 9-61 in the MPC8572 User's Manual.
+ */
+static u8 syndrome_from_bit(unsigned int bit) {
+   int i;
+   u8 syndrome = 0;
+
+   /*
+* Cycle through the upper or lower 32-bit portion of each value in
+* ecc_table depending on if 'bit' is in the upper or lower half of
+* 64-bit data.
+*/
+   for (i = bit  32; i  16; i += 2)
+   syndrome |= ((ecc_table[i]  (bit % 32))  1)  (i / 2);
+
+   return syndrome;
+}
+
+/*
+ * Decode data and ecc syndrome to determine what went wrong
+ * Note: This can only decode single-bit errors
+ */
+static void sbe_ecc_decode(u32 cap_high, u32 cap_low, u32 cap_ecc,
+  int *bad_data_bit, int *bad_ecc_bit)
+{
+   int i;
+   u8 syndrome;
+
+   *bad_data_bit = -1;
+   *bad_ecc_bit = -1;
+
+   /*
+* Calculate the ECC of the captured data and XOR it with the captured
+* ECC to find an ECC syndrome value we can search for
+*/
+   syndrome = calculate_ecc(cap_high, cap_low) ^ cap_ecc;
+
+   /* Check if a data line is stuck... */
+   for (i = 0; i  64; i++) {
+   if (syndrome == syndrome_from_bit(i)) {
+   *bad_data_bit = i;
+   return;
+   }
+   }
+
+   /* If data is correct, check ECC bits for errors... */
+   for (i = 0; i  8; i++) {
+   if ((syndrome  i)  0x1) {
+   *bad_ecc_bit = i;
+   return;
+   }
+   }
+}
+
 static void mpc85xx_mc_check(struct mem_ctl_info *mci)
 {
struct mpc85xx_mc_pdata *pdata = mci-pvt_info;
@@ -678,6 +783,10 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
u32 err_addr;
u32 pfn;
int row_index;
+   u32 cap_high;
+   u32 cap_low;
+   int bad_data_bit

[PATCH 1/4] edac: Remove unused mpc85xx debug code

[Peter Tyser]

Some unused, unsupported debug code existed in the mpc85xx EDAC driver
that resulted in a build failure when CONFIG_EDAC_DEBUG was defined:

  drivers/edac/mpc85xx_edac.c: In function 'mpc85xx_mc_err_probe':
  drivers/edac/mpc85xx_edac.c:1031: error: implicit declaration of function 
'edac_mc_register_mcidev_debug'
  drivers/edac/mpc85xx_edac.c:1031: error: 'debug_attr' undeclared (first use 
in this function)
  drivers/edac/mpc85xx_edac.c:1031: error: (Each undeclared identifier is 
reported only once
  drivers/edac/mpc85xx_edac.c:1031: error: for each function it appears in.)

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
 drivers/edac/mpc85xx_edac.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index cf27402..28d3211 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -892,10 +892,6 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device 
*op,
 
mpc85xx_init_csrows(mci);
 
-#ifdef CONFIG_EDAC_DEBUG
-   edac_mc_register_mcidev_debug((struct attribute **)debug_attr);
-#endif
-
/* store the original error disable bits */
orig_ddr_err_disable =
in_be32(pdata-mc_vbase + MPC85XX_MC_ERR_DISABLE);
-- 
1.6.2.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/3] powerpc: Add support for FIT uImages

[Peter Tyser]

These patches add support for creating the new FIT uImage type
that U-Boot can use.  Additional info about FIT images can be
found in the doc/uImage.FIT/ directory of the U-Boot source.
Here's a link to a howto which gives an overview of the format:
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=doc/uImage.FIT/howto.txt;h=8065e9e1d8d4d65a9b5fe0fce08d3709183d0ee4;hb=HEAD

I've only added support for PowerPC, but the arm, avr32, blackfin,
and sh arches could use the same framework in theory.  The change
is especially useful on PowerPC since it creates 1 FIT uImage that
combines the functionality of an old uImage format, a device
tree blob, and possibly a ramdisk.

Peter Tyser (3):
  powerpc: Use scripts/mkuboot.sh instead of 'mkimage'
  powerpc: Add support for creating FIT uImages
  powerpc: Add support for ram filesystems in FIT uImages

 arch/powerpc/Makefile|4 +-
 arch/powerpc/boot/.gitignore |1 +
 arch/powerpc/boot/Makefile   |8 ++-
 arch/powerpc/boot/wrapper|   39 ++--
 scripts/mkits.sh |  144 ++
 5 files changed, 189 insertions(+), 7 deletions(-)
 create mode 100755 scripts/mkits.sh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/3] powerpc: Use scripts/mkuboot.sh instead of 'mkimage'

[Peter Tyser]

mkuboot.sh provides a basic wrapper for the 'mkimage' utility.  Using
mkuboot.sh provides clearer error reporting and allows a toolchain to
use its own 'mkimage' executable specified by ${CROSS_COMPILE}mkimage.
Additionally, this brings PowerPC in line with other architectures
which already call mkimage via mkuboot.sh.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
 arch/powerpc/boot/wrapper |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index ac9e9a5..1ee9448 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -43,6 +43,9 @@ gzip=.gz
 # cross-compilation prefix
 CROSS=
 
+# mkimage wrapper script
+MKIMAGE=$srctree/scripts/mkuboot.sh
+
 # directory for object and other files used by this script
 object=arch/powerpc/boot
 objbin=$object
@@ -263,7 +266,7 @@ membase=`${CROSS}objdump -p $kernel | grep -m 1 LOAD | 
awk '{print $7}'`
 case $platform in
 uboot)
 rm -f $ofile
-mkimage -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
+${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
$uboot_version -d $vmz $ofile
 if [ -z $cacheit ]; then
rm -f $vmz
@@ -323,7 +326,7 @@ coff)
 ;;
 cuboot*)
 gzip -f -9 $ofile
-mkimage -A ppc -O linux -T kernel -C gzip -a $base -e $entry \
+${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $base -e $entry \
 $uboot_version -d $ofile.gz $ofile
 ;;
 treeboot*)
-- 
1.6.2.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

The PowerPC architecture has the ability to embed the ramdisk located
at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image.  If
the bootable kernel is in the Flattened Image Tree (FIT) format, the
ramdisk should be a node in the tree instead of being embedded directly
in the kernel executable.

A FIT uImage with a ram filesystem can be generated using the command:
make uImage.fit.initrd.boardname where boardname is one of
arch/powerpc/boot/dts/boardname.dts.  The command will generate a FIT
uImage at arch/powerpc/boot/uImage.fit.initrd.boardname that contains
a kernel image, device tree blob, and a ram filesystem.

The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older
style ramdisk or a newer ramfs gzipped cpio archive.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
 arch/powerpc/boot/Makefile |3 +++
 arch/powerpc/boot/wrapper  |   20 
 scripts/mkits.sh   |   35 +--
 3 files changed, 52 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 57e4eee..c2b6c25 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -310,6 +310,9 @@ $(obj)/uImage: vmlinux $(wrapperbits)
 $(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
 
+$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
+   $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
+
 $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
 
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 26a971e..8027ef9 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -266,6 +266,9 @@ fi
 # physical offset of kernel image
 membase=`${CROSS}objdump -p $kernel | grep -m 1 LOAD | awk '{print $7}'`
 
+# Size of uncompressed kernel is needed to calculate ramdisk location in RAM
+kernsize=`${CROSS}objdump -p $kernel | grep -m 1 rwx | awk '{print $4}'`
+
 case $platform in
 uboot)
 rm -f $ofile
@@ -278,8 +281,14 @@ uboot)
 ;;
 uboot.fit)
 rm -f $ofile
-${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
-   -d $srctree/$dtb -k $srctree/$vmz -o $object/uImage.its
+if [ -n $initrd ]; then
+   ${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+   -d $srctree/$dtb -k $srctree/$vmz -r $srctree/$initrd \
+   -l $kernsize -o $object/uImage.its
+else
+   ${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+   -d $srctree/$dtb -k $srctree/$vmz -o $object/uImage.its
+fi
 ${MKIMAGE} -f $object/uImage.its $ofile
 rm $object/uImage.its
 if [ -z $cacheit ]; then
@@ -300,8 +309,11 @@ if [ -z $cacheit ]; then
 rm -f $vmz
 fi
 
-if [ -n $initrd ]; then
-addsec $tmp $initrd $isection
+# FIT images have the initrd in the image tree structure
+if [ $platform != uboot.fit ]; then
+if [ -n $initrd ]; then
+   addsec $tmp $initrd $isection
+fi
 fi
 
 if [ -n $dtb ]; then
diff --git a/scripts/mkits.sh b/scripts/mkits.sh
index a438cac..88411dd 100755
--- a/scripts/mkits.sh
+++ b/scripts/mkits.sh
@@ -16,7 +16,8 @@
 
 usage() {
echo Usage: `basename $0` -A arch -C comp -a addr -e entry \
-   -v version -k kernel [-d dtb] -o its_file
+   -v version -k kernel [-d dtb] [-r ramfs -l ramfs_addr] \
+   -o its_file
echo -e \t-A == set architecture to 'arch'
echo -e \t-C == set compression type 'comp'
echo -e \t-a == set load address to 'addr' (hex)
@@ -24,11 +25,13 @@ usage() {
echo -e \t-v == set kernel version to 'version'
echo -e \t-k == include kernel image 'kernel'
echo -e \t-d == include Device Tree Blob 'dtb'
+   echo -e \t-r == include initrd/initramfs 'ramfs'
+   echo -e \t-l == load initrd/initramfs at 'ramfs_addr'
echo -e \t-o == create output file 'its_file'
exit 1
 }
 
-while getopts :A:C:a:d:e:k:o:v: OPTION
+while getopts :A:C:a:d:e:k:l:o:r:v: OPTION
 do
case $OPTION in
A ) ARCH=$OPTARG;;
@@ -37,7 +40,9 @@ do
d ) DTB=$OPTARG;;
e ) ENTRY_ADDR=$OPTARG;;
k ) KERNEL=$OPTARG;;
+   l ) RAMFS_ADDR=$OPTARG;;
o ) OUTPUT=$OPTARG;;
+   r ) RAMFS=$OPTARG;;
v ) VERSION=$OPTARG;;
* ) echo Invalid option passed to '$0' (options:$@)
usage;;
@@ -49,11 +54,14 @@ if [ -z ${ARCH} ] || [ -z ${COMPRESS} ] || [ -z 
${LOAD_ADDR} ] || \
[ -z ${ENTRY_ADDR} ] || [ -z ${VERSION} ] || [ -z ${KERNEL} ] || \
[ -z ${OUTPUT} ]; then
usage
+elif [ -n ${RAMFS} ]  [ -z ${RAMFS_ADDR} ]; then
+   usage
 fi
 
 # Device trees need the leading '0x' stripped for hex numbers
 LOAD_ADDR=`echo $LOAD_ADDR | sed 's/0x

[PATCH 2/3] powerpc: Add support for creating FIT uImages

[Peter Tyser]

Recent U-Boot versions support booting a Flattened Image Tree (FIT)
image format.  The FIT uImage format uses a tree structure to describe a
kernel image as well as supporting device tree blobs, ramdisks, etc.
The 'mkimage' and 'dtc' utilities convert this tree description into a
binary blob that bootloaders such as U-Boot can execute.

This patch adds support for automatically creating a U-Boot FIT image
using the make uImage.fit.boardname command where boardname is
one of arch/powerpc/boot/dts/boardname.dts.  The resulting
arch/powerpc/boot/uImage.fit.boardname file will contain a kernel
image as well as a device tree blob.  U-Boot versions compiled with FIT
support can directly boot this image using the bootm command.

Additional information about the FIT format and its uses can be found in
doc/uImage.FIT/howto.txt of U-Boot's source tree.

Signed-off-by: Peter Tyser pty...@xes-inc.com
---
 arch/powerpc/Makefile|4 +-
 arch/powerpc/boot/.gitignore |1 +
 arch/powerpc/boot/Makefile   |5 ++-
 arch/powerpc/boot/wrapper|   16 ++-
 scripts/mkits.sh |  113 ++
 5 files changed, 136 insertions(+), 3 deletions(-)
 create mode 100755 scripts/mkits.sh

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 1a54a3b..459aed5 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -158,7 +158,8 @@ drivers-$(CONFIG_OPROFILE)  += arch/powerpc/oprofile/
 # Default to zImage, override when needed
 all: zImage
 
-BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% 
cuImage.% simpleImage.%
+BOOT_TARGETS = zImage zImage.initrd uImage uImage.fit.% zImage% dtbImage% \
+  treeImage.% cuImage.% simpleImage.%
 
 PHONY += $(BOOT_TARGETS)
 
@@ -185,6 +186,7 @@ define archhelp
   @echo '* zImage  - Build default images selected by kernel config'
   @echo '  zImage.*- Compressed kernel image 
(arch/$(ARCH)/boot/zImage.*)'
   @echo '  uImage  - U-Boot native image format'
+  @echo '  uImage.fit.dt - U-Boot Flattened Image Tree image format'
   @echo '  cuImage.dt- Backwards compatible U-Boot image for older'
   @echo 'versions which do not support device trees'
   @echo '  dtbImage.dt   - zImage with an embedded device tree blob'
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index 3d80c3e..a443f1c 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -19,6 +19,7 @@ kernel-vmlinux.strip.c
 kernel-vmlinux.strip.gz
 mktree
 uImage
+uImage.fit.*
 cuImage.*
 dtbImage.*
 treeImage.*
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 7bfc8ad..57e4eee 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -307,6 +307,9 @@ $(obj)/zImage.iseries: vmlinux
 $(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
 
+$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
+   $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
+
 $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
 
@@ -346,7 +349,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
 
 # anything not in $(targets)
 clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
-   zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
+   uImage.* zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
simpleImage.* otheros.bld *.dtb
 
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 1ee9448..26a971e 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -46,6 +46,9 @@ CROSS=
 # mkimage wrapper script
 MKIMAGE=$srctree/scripts/mkuboot.sh
 
+# script to generate an .its file for uImage.fit.* images
+MKITS=$srctree/scripts/mkits.sh
+
 # directory for object and other files used by this script
 object=arch/powerpc/boot
 objbin=$object
@@ -157,7 +160,7 @@ coff)
 lds=$object/zImage.coff.lds
 link_address='0x50'
 ;;
-miboot|uboot)
+miboot|uboot|uboot.fit)
 # miboot and U-boot want just the bare bits, not an ELF binary
 ext=bin
 objflags=-O binary
@@ -273,6 +276,17 @@ uboot)
 fi
 exit 0
 ;;
+uboot.fit)
+rm -f $ofile
+${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+   -d $srctree/$dtb -k $srctree/$vmz -o $object/uImage.its
+${MKIMAGE} -f $object/uImage.its $ofile
+rm $object/uImage.its
+if [ -z $cacheit ]; then
+   rm -f $vmz
+fi
+exit 0
+;;
 esac
 
 addsec() {
diff --git a/scripts/mkits.sh b/scripts/mkits.sh
new file mode 100755
index 000..a438cac
--- /dev/null
+++ b/scripts/mkits.sh
@@ -0,0 +1,113 @@
+#!/bin/bash
+#
+# Licensed under the terms of the GNU GPL License version 2 or later.
+#
+# Author: Peter Tyser pty...@xes-inc.com
+#
+# U-Boot firmware supports

Re: [PATCH 0/3] powerpc: Add support for FIT uImages

[Peter Tyser]

On Wed, 2009-11-18 at 14:57 -0600, Peter Tyser wrote:
 These patches add support for creating the new FIT uImage type
 that U-Boot can use.  Additional info about FIT images can be
 found in the doc/uImage.FIT/ directory of the U-Boot source.
 Here's a link to a howto which gives an overview of the format:
 http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=doc/uImage.FIT/howto.txt;h=8065e9e1d8d4d65a9b5fe0fce08d3709183d0ee4;hb=HEAD
 
 I've only added support for PowerPC, but the arm, avr32, blackfin,
 and sh arches could use the same framework in theory.  The change
 is especially useful on PowerPC since it creates 1 FIT uImage that
 combines the functionality of an old uImage format, a device
 tree blob, and possibly a ramdisk.
 
 Peter Tyser (3):
   powerpc: Use scripts/mkuboot.sh instead of 'mkimage'
   powerpc: Add support for creating FIT uImages
   powerpc: Add support for ram filesystems in FIT uImages
 
  arch/powerpc/Makefile|4 +-
  arch/powerpc/boot/.gitignore |1 +
  arch/powerpc/boot/Makefile   |8 ++-
  arch/powerpc/boot/wrapper|   39 ++--
  scripts/mkits.sh |  144 
 ++
  5 files changed, 189 insertions(+), 7 deletions(-)
  create mode 100755 scripts/mkits.sh

Just realized I missed /Documentation/powerpc/bootwrapper.txt in this
series.  I'll wait for feedback and roll the documentation update and
any other requested changes into v2.

Sorry for the noise,
Peter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev