[PATCH, RFC]

[PATCH, RFC]

[Eddie Dawydiuk]

Hello,

The patch below resolves the following issues. The build system for the 
AMCC Yosemite eval board is not including the proper fixups(e.g. RAM 
initialization, timer initialization). In addition the wrapper script 
was not using the fixed-head.S source(e.g. add branch instruction so one 
can jump into the image at offset 0).

Any feedback appreciated..

diff -urN linux-2.6.28.orig/arch/powerpc/boot/Makefile 
linux-2.6.28/arch/powerpc/boot/Makefile
--- linux-2.6.28.orig/arch/powerpc/boot/Makefile        2008-12-24 
16:26:37.000000000 -0700
+++ linux-2.6.28/arch/powerpc/boot/Makefile     2009-03-05 
17:35:53.000000000 -0700
@@ -70,7 +70,7 @@
                 cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
                 cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c 
simpleboot.c \
                 virtex405-head.S virtex.c redboot-83xx.c 
cuboot-sam440ep.c \
-               cuboot-acadia.c
+               cuboot-acadia.c simpleboot-yosemite.c
  src-boot := $(src-wlib) $(src-plat) empty.c

  src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -224,7 +224,7 @@
  image-$(CONFIG_TAISHAN)                        += cuImage.taishan
  image-$(CONFIG_KATMAI)                 += cuImage.katmai
  image-$(CONFIG_WARP)                   += cuImage.warp
-image-$(CONFIG_YOSEMITE)               += cuImage.yosemite
+image-$(CONFIG_YOSEMITE)               += cuImage.yosemite 
simpleImage.yosemite

  # Board ports in arch/powerpc/platform/8xx/Kconfig
  image-$(CONFIG_MPC86XADS)              += cuImage.mpc866ads

diff -urN linux-2.6.28.orig/arch/powerpc/boot/wrapper 
linux-2.6.28/arch/powerpc/boot/wrapper
--- linux-2.6.28.orig/arch/powerpc/boot/wrapper 2008-12-24 
16:26:37.000000000 -0700
+++ linux-2.6.28/arch/powerpc/boot/wrapper      2009-03-05 
17:36:10.000000000 -0700
@@ -214,8 +214,12 @@
      platformo="$object/simpleboot.o $object/virtex.o"
      binary=y
      ;;
+simpleboot-yosemite)
+    platformo="$object/fixed-head.o $object/simpleboot.o 
$object/simpleboot-yosemite.o"
+    binary=y
+    ;;
  simpleboot-*)
-    platformo="$object/simpleboot.o"
+    platformo="$object/fixed-head.o $object/simpleboot.o"
      binary=y
      ;;
  asp834x-redboot)

diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 
linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
--- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 
1969-12-31 17:00:00.000000000 -0700
+++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c 
2009-03-06 10:48:19.000000000 -0700
@@ -0,0 +1,27 @@
+#include "ops.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static unsigned char eth0adr[] = { 0x0, 0xd0, 0x69, 0x41, 0x12, 0x34 };
+static unsigned char eth1adr[] = { 0x0, 0xd0, 0x69, 0x41, 0x12, 0x56 };
+
+static void yosemite_fixups(void)
+{
+       unsigned long sysclk = 50000000;
+
+       ibm440ep_fixup_clocks(sysclk, 11059200, 400000000);
+       ibm4xx_sdram_fixup_memsize();
+       dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
+       dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
+}
+
+void platform_specific_init(void)
+{
+       platform_ops.fixups = yosemite_fixups;
+       platform_ops.exit = ibm44x_dbcr_reset;
+}

-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive 	     | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: [PATCH, RFC]

[Josh Boyer]

On Fri, Mar 06, 2009 at 10:41:48AM -0700, Eddie Dawydiuk wrote:
> Hello,
>
> The patch below resolves the following issues. The build system for the  
> AMCC Yosemite eval board is not including the proper fixups(e.g. RAM  
> initialization, timer initialization). In addition the wrapper script  
> was not using the fixed-head.S source(e.g. add branch instruction so one  
> can jump into the image at offset 0).
>
> Any feedback appreciated..

Your patch is word-wrapped.  It also lacks the Signed-off-by tag, which
is required.

The changelog sounds as if there are bugs being fixed here, but really
you're adding support for something entirely new.  The yosemite board
comes with U-Boot, which uses uImages.  You seem to be adding support
for using simpleboot on the Yosemite board.  Is that correct?

See below for further comments.

> diff -urN linux-2.6.28.orig/arch/powerpc/boot/Makefile  
> linux-2.6.28/arch/powerpc/boot/Makefile
> --- linux-2.6.28.orig/arch/powerpc/boot/Makefile        2008-12-24  
> 16:26:37.000000000 -0700
> +++ linux-2.6.28/arch/powerpc/boot/Makefile     2009-03-05  
> 17:35:53.000000000 -0700
> @@ -70,7 +70,7 @@
>                 cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
>                 cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c  
> simpleboot.c \
>                 virtex405-head.S virtex.c redboot-83xx.c  
> cuboot-sam440ep.c \
> -               cuboot-acadia.c
> +               cuboot-acadia.c simpleboot-yosemite.c
>  src-boot := $(src-wlib) $(src-plat) empty.c
>
>  src-boot := $(addprefix $(obj)/, $(src-boot))
> @@ -224,7 +224,7 @@
>  image-$(CONFIG_TAISHAN)                        += cuImage.taishan
>  image-$(CONFIG_KATMAI)                 += cuImage.katmai
>  image-$(CONFIG_WARP)                   += cuImage.warp
> -image-$(CONFIG_YOSEMITE)               += cuImage.yosemite
> +image-$(CONFIG_YOSEMITE)               += cuImage.yosemite  
> simpleImage.yosemite
>
>  # Board ports in arch/powerpc/platform/8xx/Kconfig
>  image-$(CONFIG_MPC86XADS)              += cuImage.mpc866ads
>
> diff -urN linux-2.6.28.orig/arch/powerpc/boot/wrapper  
> linux-2.6.28/arch/powerpc/boot/wrapper
> --- linux-2.6.28.orig/arch/powerpc/boot/wrapper 2008-12-24  
> 16:26:37.000000000 -0700
> +++ linux-2.6.28/arch/powerpc/boot/wrapper      2009-03-05  
> 17:36:10.000000000 -0700
> @@ -214,8 +214,12 @@
>      platformo="$object/simpleboot.o $object/virtex.o"
>      binary=y
>      ;;
> +simpleboot-yosemite)
> +    platformo="$object/fixed-head.o $object/simpleboot.o  
> $object/simpleboot-yosemite.o"
> +    binary=y
> +    ;;
>  simpleboot-*)
> -    platformo="$object/simpleboot.o"
> +    platformo="$object/fixed-head.o $object/simpleboot.o"

Does this break other boards, or should it have always been there?

>      binary=y
>      ;;
>  asp834x-redboot)
>
> diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c  
> linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
> --- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 1969-12-31 
> 17:00:00.000000000 -0700
> +++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c 2009-03-06 
> 10:48:19.000000000 -0700
> @@ -0,0 +1,27 @@
> +#include "ops.h"
> +#include "stdio.h"
> +#include "4xx.h"
> +#include "44x.h"
> +
> +#define TARGET_4xx
> +#define TARGET_44x
> +#include "ppcboot.h"
> +
> +static unsigned char eth0adr[] = { 0x0, 0xd0, 0x69, 0x41, 0x12, 0x34 };
> +static unsigned char eth1adr[] = { 0x0, 0xd0, 0x69, 0x41, 0x12, 0x56 };

You can't do this.  If you hard code the MAC address of whatever board
you are using in the kernel, everyone will have to edit it.  You need
to specify this in your board DTS file or via some other configurable
mechansim.

> +
> +static void yosemite_fixups(void)
> +{
> +       unsigned long sysclk = 50000000;
> +
> +       ibm440ep_fixup_clocks(sysclk, 11059200, 400000000);
> +       ibm4xx_sdram_fixup_memsize();
> +       dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
> +       dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
> +}
> +
> +void platform_specific_init(void)
> +{
> +       platform_ops.fixups = yosemite_fixups;
> +       platform_ops.exit = ibm44x_dbcr_reset;
> +}

josh

Re: [PATCH, RFC]

[Grant Likely]

On Fri, Mar 6, 2009 at 11:40 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wr=
ote:
> On Fri, Mar 06, 2009 at 10:41:48AM -0700, Eddie Dawydiuk wrote:
>> @@ -214,8 +214,12 @@
>> =A0 =A0 =A0platformo=3D"$object/simpleboot.o $object/virtex.o"
>> =A0 =A0 =A0binary=3Dy
>> =A0 =A0 =A0;;
>> +simpleboot-yosemite)
>> + =A0 =A0platformo=3D"$object/fixed-head.o $object/simpleboot.o
>> $object/simpleboot-yosemite.o"
>> + =A0 =A0binary=3Dy
>> + =A0 =A0;;
>> =A0simpleboot-*)
>> - =A0 =A0platformo=3D"$object/simpleboot.o"
>> + =A0 =A0platformo=3D"$object/fixed-head.o $object/simpleboot.o"
>
> Does this break other boards, or should it have always been there?

This probably should have always been there.  Same for the simpleboot
virtex targets, but I'll need to test to be sure.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH, RFC]

[Eddie Dawydiuk]

Hello,

> Your patch is word-wrapped.  It also lacks the Signed-off-by tag, which
> is required.

I apologize please see an updated patch below.

> The changelog sounds as if there are bugs being fixed here, but really
> you're adding support for something entirely new.  The yosemite board
> comes with U-Boot, which uses uImages.  You seem to be adding support
> for using simpleboot on the Yosemite board.  Is that correct?

Yes, the patch ensures the simpleboot image works on the Yosemite board. I was 
under the impression the code was broken as one can build a simpleImage for the 
Yosemite board as described in Documentation/powerpc/bootwrapper.txt without any 
modification on a vanilla kernel, although the resulting image does not work 
without the following patches.

 > You can't do this.  If you hard code the MAC address of whatever board
 > you are using in the kernel, everyone will have to edit it.  You need
 > to specify this in your board DTS file or via some other configurable
 > mechansim.

Oops, sorry I forgot to pull out the debug code...

Signed-off-by: Eddie Dawydiuk <eddie@embeddedarm.com>

diff -urN linux-2.6.28.orig/arch/powerpc/boot/Makefile 
linux-2.6.28/arch/powerpc/boot/Makefile
--- linux-2.6.28.orig/arch/powerpc/boot/Makefile        2008-12-24 
16:26:37.000000000 -0700
+++ linux-2.6.28/arch/powerpc/boot/Makefile     2009-03-05 17:35:53.000000000 -0700
@@ -70,7 +70,7 @@
                 cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
                 cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c \
                 virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
-               cuboot-acadia.c
+               cuboot-acadia.c simpleboot-yosemite.c
  src-boot := $(src-wlib) $(src-plat) empty.c

  src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -224,7 +224,7 @@
  image-$(CONFIG_TAISHAN)                        += cuImage.taishan
  image-$(CONFIG_KATMAI)                 += cuImage.katmai
  image-$(CONFIG_WARP)                   += cuImage.warp
-image-$(CONFIG_YOSEMITE)               += cuImage.yosemite
+image-$(CONFIG_YOSEMITE)               += cuImage.yosemite simpleImage.yosemite

  # Board ports in arch/powerpc/platform/8xx/Kconfig
  image-$(CONFIG_MPC86XADS)

diff -urN linux-2.6.28.orig/arch/powerpc/boot/wrapper 
linux-2.6.28/arch/powerpc/boot/wrapper
--- linux-2.6.28.orig/arch/powerpc/boot/wrapper 2008-12-24 16:26:37.000000000 -0700
+++ linux-2.6.28/arch/powerpc/boot/wrapper      2009-03-05 17:36:10.000000000 -0700
@@ -214,8 +214,12 @@
      platformo="$object/simpleboot.o $object/virtex.o"
      binary=y
      ;;
+simpleboot-yosemite)
+    platformo="$object/fixed-head.o $object/simpleboot.o 
$object/simpleboot-yosemite.o"
+    binary=y
+    ;;
  simpleboot-*)
-    platformo="$object/simpleboot.o"
+    platformo="$object/fixed-head.o $object/simpleboot.o"
      binary=y
      ;;
  asp834x-redboot)

diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 
linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
--- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c   1969-12-31 
17:00:00.000000000 -0700
+++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c        2009-03-06 
14:55:46.000000000 -0700
@@ -0,0 +1,24 @@
+#include "ops.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static void yosemite_fixups(void)
+{
+       unsigned long sysclk = 50000000;
+
+       ibm440ep_fixup_clocks(sysclk, 11059200, 400000000);
+       ibm4xx_sdram_fixup_memsize();
+       dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
+       dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
+}
+
+void platform_specific_init(void)
+{
+       platform_ops.fixups = yosemite_fixups;
+       platform_ops.exit = ibm44x_dbcr_reset;
+}

-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive 	     | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: [PATCH, RFC]

[Eddie Dawydiuk]

Hello,

Let's try this one more time. The last patch was using the clocks for a custom 
board based on the Yosemite board and was referencing a non-existent ethNadr( I 
forgot to pull out this code out).

Signed-off-by: Eddie Dawydiuk <eddie@embeddedarm.com>

diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 
linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
--- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c   1969-12-31 
17:00:00.000000000 -0700
+++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c        2009-03-06 
15:33:24.000000000 -0700
@@ -0,0 +1,23 @@
+#include "ops.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static void yosemite_fixups(void)
+{
+       unsigned long sysclk = 66666666;
+
+       ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
+       ibm4xx_sdram_fixup_memsize();
+}
+
+void platform_specific_init(void)
+{
+       platform_ops.fixups = yosemite_fixups;
+       platform_ops.exit = ibm44x_dbcr_reset;
+}

> diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 
> linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
> --- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c   
> 1969-12-31 17:00:00.000000000 -0700
> +++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c        
> 2009-03-06 14:55:46.000000000 -0700
> @@ -0,0 +1,24 @@
> +#include "ops.h"
> +#include "stdio.h"
> +#include "4xx.h"
> +#include "44x.h"
> +
> +#define TARGET_4xx
> +#define TARGET_44x
> +#include "ppcboot.h"
> +
> +static void yosemite_fixups(void)
> +{
> +       unsigned long sysclk = 50000000;
> +
> +       ibm440ep_fixup_clocks(sysclk, 11059200, 400000000);
> +       ibm4xx_sdram_fixup_memsize();
> +       dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
> +       dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
> +}
> +
> +void platform_specific_init(void)
> +{
> +       platform_ops.fixups = yosemite_fixups;
> +       platform_ops.exit = ibm44x_dbcr_reset;
> +}
> 


-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive 	     | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: [PATCH, RFC]

[Grant Likely]

On Fri, Mar 6, 2009 at 3:32 PM, Eddie Dawydiuk <eddie@embeddedarm.com> wrot=
e:
> Hello,
>
> Let's try this one more time. The last patch was using the clocks for a
> custom board based on the Yosemite board and was referencing a non-existe=
nt
> ethNadr( I forgot to pull out this code out).

But the question remains: Why do you need simpleboot support for
Yosemite when you can use a uImage or cuImage with u-boot?

g.

>
> Signed-off-by: Eddie Dawydiuk <eddie@embeddedarm.com>
>
> diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
> linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
> --- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c =A0 1969-12=
-31
> 17:00:00.000000000 -0700
> +++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c =A0 =A0 =A0 =A02=
009-03-06
> 15:33:24.000000000 -0700
> @@ -0,0 +1,23 @@
> +#include "ops.h"
> +#include "stdio.h"
> +#include "4xx.h"
> +#include "44x.h"
> +
> +#define TARGET_4xx
> +#define TARGET_44x
> +#include "ppcboot.h"
> +
> +static void yosemite_fixups(void)
> +{
> + =A0 =A0 =A0 unsigned long sysclk =3D 66666666;
> +
> + =A0 =A0 =A0 ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
> + =A0 =A0 =A0 ibm4xx_sdram_fixup_memsize();
> +}
> +
> +void platform_specific_init(void)
> +{
> + =A0 =A0 =A0 platform_ops.fixups =3D yosemite_fixups;
> + =A0 =A0 =A0 platform_ops.exit =3D ibm44x_dbcr_reset;
> +}
>
>> diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
>> linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
>> --- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c =A0 1969-1=
2-31
>> 17:00:00.000000000 -0700
>> +++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c =A0 =A0 =A0 =A0=
2009-03-06
>> 14:55:46.000000000 -0700
>> @@ -0,0 +1,24 @@
>> +#include "ops.h"
>> +#include "stdio.h"
>> +#include "4xx.h"
>> +#include "44x.h"
>> +
>> +#define TARGET_4xx
>> +#define TARGET_44x
>> +#include "ppcboot.h"
>> +
>> +static void yosemite_fixups(void)
>> +{
>> + =A0 =A0 =A0 unsigned long sysclk =3D 50000000;
>> +
>> + =A0 =A0 =A0 ibm440ep_fixup_clocks(sysclk, 11059200, 400000000);
>> + =A0 =A0 =A0 ibm4xx_sdram_fixup_memsize();
>> + =A0 =A0 =A0 dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
>> + =A0 =A0 =A0 dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
>> +}
>> +
>> +void platform_specific_init(void)
>> +{
>> + =A0 =A0 =A0 platform_ops.fixups =3D yosemite_fixups;
>> + =A0 =A0 =A0 platform_ops.exit =3D ibm44x_dbcr_reset;
>> +}
>>
>
>
> --
> Best Regards,
> ________________________________________________________________
> =A0Eddie Dawydiuk, Technologic Systems | voice: =A0(480) 837-5200
> =A016525 East Laser Drive =A0 =A0 =A0 =A0 =A0 =A0 =A0| fax: =A0 =A0(480) =
837-5300
> =A0Fountain Hills, AZ 85268 =A0 =A0 =A0 =A0 =A0 =A0| web: www.embeddedARM=
.com
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH, RFC]

[Grant Likely]

On Fri, Mar 6, 2009 at 9:22 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Mar 6, 2009 at 3:32 PM, Eddie Dawydiuk <eddie@embeddedarm.com> wrote:
>> Hello,
>>
>> Let's try this one more time. The last patch was using the clocks for a
>> custom board based on the Yosemite board and was referencing a non-existent
>> ethNadr( I forgot to pull out this code out).
>
> But the question remains: Why do you need simpleboot support for
> Yosemite when you can use a uImage or cuImage with u-boot?

On a more general note; this patch also diverges from the original
model for simple image.  The idea behind simpleimage was that it would
contain a fully formed device tree, with no fixups necessary.  I want
to think carefully before diverging from that.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH, RFC]

[Eddie Dawydiuk]

Hello,

> But the question remains: Why do you need simpleboot support for
> Yosemite when you can use a uImage or cuImage with u-boot?

We are developing a new board based upon the Yosemite board. Seeing as
though the Yosemite board was supported in the mainline kernel I decided
to start with that code base. After looking at what different
options/images were available for device trees vs open firmware I decided
the simpleImage would be the ideal format for our new board. I then read
how to build a simpleImage for the Yosemite board, which build without any
compiler errors. Although I found the image didn't work, so I figured it
might be helpful for others if the image just worked without
modifications. Although shortly I will be submitting support for our
custom board using this same approach. So if you have any suggestions on
this approach using the simpleImage please let me know.

On another note, can you tell me/point me to some documentation on how to
get a unique machine ID for a new board?

--
Best Regards,
________________________________________________________________
 Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
 16525 East Laser Drive              | fax:    (480) 837-5300
 Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: [PATCH, RFC]

[Eddie Dawydiuk]

Hello,

> On a more general note; this patch also diverges from the original
> model for simple image.  The idea behind simpleimage was that it would
> contain a fully formed device tree, with no fixups necessary.  I want
> to think carefully before diverging from that.

I wasn't aware of these design goals... I believe one can also modify the
default dts file such that the RAM size is not dynamically detected so the
fixups aren't required(although keep in mind I haven't tested this).
Although it is quite convenient to add the fixed-head.o so one can jump
into the simpleImage at offset 0 rather than having to check what the
offset should be each time a change is made.

//Eddie

Re: [PATCH, RFC]

[Grant Likely]

On Sat, Mar 7, 2009 at 8:21 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrot=
e:
> Hello,
>
>> On a more general note; this patch also diverges from the original
>> model for simple image. =A0The idea behind simpleimage was that it would
>> contain a fully formed device tree, with no fixups necessary. =A0I want
>> to think carefully before diverging from that.
>
> I wasn't aware of these design goals... I believe one can also modify the
> default dts file such that the RAM size is not dynamically detected so th=
e
> fixups aren't required(although keep in mind I haven't tested this).

Just to be clear, I'm not saying 'no'.  I'm just not saying 'yes' yet
either.  However, if you can fully form the dts file then that is
definitely my preference.

> Although it is quite convenient to add the fixed-head.o so one can jump
> into the simpleImage at offset 0 rather than having to check what the
> offset should be each time a change is made.

The missing fixed-head thing is a bug.  I have no issue with that change.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH, RFC]

[Grant Likely]

On Sat, Mar 7, 2009 at 8:14 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrote:
> Hello,
>
>> But the question remains: Why do you need simpleboot support for
>> Yosemite when you can use a uImage or cuImage with u-boot?
>
> We are developing a new board based upon the Yosemite board. Seeing as
> though the Yosemite board was supported in the mainline kernel I decided
> to start with that code base. After looking at what different
> options/images were available for device trees vs open firmware I decided
> the simpleImage would be the ideal format for our new board. I then read
> how to build a simpleImage for the Yosemite board, which build without any
> compiler errors. Although I found the image didn't work, so I figured it
> might be helpful for others if the image just worked without
> modifications. Although shortly I will be submitting support for our
> custom board using this same approach. So if you have any suggestions on
> this approach using the simpleImage please let me know.

Before I answer this, what bootloader are you using?

> On another note, can you tell me/point me to some documentation on how to
> get a unique machine ID for a new board?

What do you mean?  Are you referring to the top level compatible and
model properties?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH, RFC]

[Sean MacLennan]

On Sat, 7 Mar 2009 08:14:41 -0700 (MST)
"Eddie Dawydiuk" <eddie@embeddedarm.com> wrote:

> On another note, can you tell me/point me to some documentation on
> how to get a unique machine ID for a new board?

Do you mean the model in the dts, like "amcc,yosemite"? You just pick
one.

It is just company name, board name. We based the Pika Warp on the
yosemite board but our model name is pika,warp since it is too far
removed to use the stock yosemite to use the same DTS.

Cheers,
   Sean

Re: [PATCH, RFC]

[Grant Likely]

On Sat, Mar 7, 2009 at 9:37 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrot=
e:
> Hello,
>
>>> So if you have any suggestions on
>>> this approach using the simpleImage please let me know.
>>
>> Before I answer this, what bootloader are you using?
>
> We are using a custom bootloader we developed ourselves. The bootloader i=
s
> very minimal as one of our primary design goals is a fast boot time. We d=
o
> some basic initialization of the AMCC 440EP, then load the simpleImage
> into RAM at address 0 and jump into it. In my mind I had considered our
> code as more of a bootrom and the simpleboot.c as a bootloader ;)
>
>>> On another note, can you tell me/point me to some documentation on how
>>> to get a unique machine ID for a new board?
>>
>> What do you mean? =A0Are you referring to the top level compatible and
>> model properties?
>
> I think I might be getting ahead of myself, as I'm not yet up to speed on
> how the powerpc code base identifies unique machines. For instance the AR=
M
> codebase required that each new machine have a unique machine ID. When
> bringing up a new platform one had to request a new unique machine ID. Th=
e
> bootloader was required to pass this unique machine id to the kernel.
> We're still using quite a bit of the Yosemite code base and so I had
> assumed we are probably using the Yosemite boards "unique machine id" for
> our custom hardware. Although based on your response it sounds like
> powerpc =A0uses a different approach.

The powerpc kernel completely trusts the device tree blob that is
passed to it at boot time.  Most of the platform support code simply
reads the top level 'compatible' property to decide whether or not it
can support the board.  For example,
arch/powerpc/platforms/44x/ppc4xx_simple.c supports a bunch of boards,
including yosemite, and arch/powerpc/platforms/44x/ebony.c only
supports the ebony board.  ppc4xx_simple.c, ebony.c, and other
platform support files can selected at the same time to build a kernel
which supports multiple boards (multi-platform).

Since there is no common boot mechanism shared between all powerpc
platforms, the bootwrapper is the adapter layer from whatever data is
provided by firmware to the form required by the kernel.  As long as
the kernel-proper (vmlinux) receives a fully formed device tree at the
end, it is happy.  Both firmware and the boot wrapper have the option
of modifying the device tree before passing it on to the next step.
One of the boot methods (uImage) even bypasses the bootwrapper step
entirely since U-Boot is able to pass a fully formed device tree
directly to the kernel.

One of the advantages of the device tree scheme is that the kernel
image format no longer needs to be board dependent.  There is no need
to encode a board specific format anymore.  Sure, you *can* use
simpleImage or dtbImage to build an image with an embedded dtb, but
those images are really just compatibility layers for existing
firmware, and using them throws away the advantage of splitting the
hardware description from the kernel image.  Not to mention that the
building of board specific images is a maze of special cases and
barely documented heuristics in arch/powerpc/boot/wrapper.

If you've got control over your boot firmware, and you don't want to
use U-Boot, then I strongly recommend that at the very least you keep
the .dtb separate from the kernel image and don't write any board
specific code in the boot wrapper.  Keep your board specific code in
arch/powerpc/platforms/44x/* where it is easy for mere mortals to
comprehend.  Get the firmware to copy both the dtb and kernel into RAM
and pass the dtb pointer to the kernel.  Ideally, you should use the
existing uImage format so you don't need to define something new (and
incompatible with anything else).  However, parsing uImage requires
your firmware to include gunzip code.

Failing that, create a new zImage target (perhaps 'zImage.fdt') that
accepts a pointer to the .dtb blob in memory.  Use the calling
convention described in Documentation/powerpc/booting-without-of.txt
for direct flattened device tree booting.  At least that way your code
has a fighting chance of being useful to someone else.  Code to do
this should be pretty trivial.  In fact the simpleImage platform_init
could be refactored to provide a large chunk of common code.  Only
difference really being the source pointer to the dtb.

Heck, you could even eliminate the boot wrapper entirely and use the
vmlinux image directly; but the kernel image can be quite large and
then you'd probably want it gzipped (which means our firmware must be
able to gunzip it).

One last think.  It's not a good idea to link the .dtb image into the
firmware either.  Many people have learned the hard way that device
trees often need to be tweaked after the firmware is deployed.  Make
the dtb a separate image that can be updated in the same way that the
kernel image can be updated.

Have fun,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH, RFC]

[Eddie Dawydiuk]

Hello,

>> So if you have any suggestions on
>> this approach using the simpleImage please let me know.
>
> Before I answer this, what bootloader are you using?

We are using a custom bootloader we developed ourselves. The bootloader is
very minimal as one of our primary design goals is a fast boot time. We do
some basic initialization of the AMCC 440EP, then load the simpleImage
into RAM at address 0 and jump into it. In my mind I had considered our
code as more of a bootrom and the simpleboot.c as a bootloader ;)

>> On another note, can you tell me/point me to some documentation on how
>> to get a unique machine ID for a new board?
>
> What do you mean?  Are you referring to the top level compatible and
> model properties?

I think I might be getting ahead of myself, as I'm not yet up to speed on
how the powerpc code base identifies unique machines. For instance the ARM
codebase required that each new machine have a unique machine ID. When
bringing up a new platform one had to request a new unique machine ID. The
bootloader was required to pass this unique machine id to the kernel.
We're still using quite a bit of the Yosemite code base and so I had
assumed we are probably using the Yosemite boards "unique machine id" for
our custom hardware. Although based on your response it sounds like
powerpc  uses a different approach.

//Eddie

[PATCH][RFC]

[Vitaly Luban]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Attached patch is an implementation of "signal-per-fd"
enhancement to kernel RT signal mechanism, AFAIK first
proposed by A. Chandra and D. Mosberger :

http://www.hpl.hp.com/techreports/2000/HPL-2000-174.html

which should dramatically increase linux based network
servers scalability.

Patch is made against 2.4.4 tree.

This patch allows to set signal-per-fd mode per each
file descriptor by introducing new fcntls "F_SETAUXFL"
and "F_GETAUXFL" with one possible argument "O_ONESIGFD"
to F_SETAUXFL defined.

When set, no additional siginfo will be queued for an
RT signal, generated by event on file descriptor, while
there are already one queued, though event report field
in already queued struct siginfo - "si_band" is updated.

I'd also like to hear an opinion on the signal filtering
capability. I.e, it's relatively easy to filter signals
upon an interest mask, supplied by the same F_SETAUXFL in
the form of POLL_... This will bring functionality of RT
signals event notification on the level with 'select' or
'poll' one, while more efficient and scalable. If there's
an interest in such a feature, I'd be eager to publish a
patch.

Thanks,
    Vitaly.


[-- Attachment #2: one-sig-perfd-2.4.4.patch.gz --]
[-- Type: application/x-gzip, Size: 15758 bytes --]