Re: mpc5121e port status
On Thursday 28 August 2008 00:07:11 Andrés Calderón wrote: > Is the mpc5121e kernel port mature enough to be used in commercial > appliance? That depends. For any use of the linux kernel in a "commercial appliance", the manufacturer of the appliance has the sole responsibility of testing for stability and fitness. That said, the status of MPC5121e support in the linux kernel is as follows: Latest mainline (git) kernel: Only basic CPU support, almost no drivers for anything. LTIB distribution from Freescale (downloadable on Freescale web-page of the MPC5121e), latest version: kernel 2.6.24.5 with a lot of drivers for (among other things): DIU, NAND-flash, PSC-I2C, PSC-Uarts, CAN, DMA, Ethernet, USB (ehci host works well), etc Notably missing from this version is support for MBX, SATA and SDHC. One thing that you shouldn't count on quite yet is the MBX (3D-acceleration), because it will not have open-source drivers in any forseeable time AFAIK (probably never)... only some promise of a commercial driver and OpenGL-ES library which probably will be more of a hassle than useful to anyone. We have a custom board running the LTIB version of the kernel, and the existing drivers work surprisingly well, but are IMHO not useable for production right out of the box. The NAND-flash driver for instance is broken for most uses, and the DIU driver has some cache-related issues (glitches in the image). Those problems are more or less easily fixed however. Ethernet and USB (host) seem pretty stable however (I am running on NFS-root all the time). There are effords underway to get the drivers ported and fixed for mainline linux, but the process is quite slow at the moment. That has us for instance locked in the ancient 2.6.24.5 version of the kernel. Best regards, -- David Jander ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: porting linux 2.6.27 to embedded powerpc board
On Thursday 21 August 2008 01:24:46 Laxmikant Rashinkar wrote: > Hi, > > I have an embedded PowerPC (MPC8347) board that works fine with uboot and > Linux 2.6.15. > > I am trying to upgrade the kernel so that it runs on the latest release - > Linux 2.6.27. So far, I have gotten the kernel to compile on my platform, > but of course it does not boot. Well, honestly I don't know where to look for information either (other than the source-code and examples from others), but here is a list with points to look out for (I have just done the same thing as you for a MPC5200B-based board): 1. Upgrade to latest u-boot first (recent git seems to be fine). There have been a lot of changes in u-boot lately about OF and device-tree related things. I suspect you need a fairly recent version of u-boot to go well with the latest kernel. It's also generally a good idea IMHO. 2. I assume you are porting to arch/powerpc (the old arch/ppc you used back in 2.6.15 is obsolete and broken now). 3. Look at other platforms that use the same processor, and pick a simple one as starting point. Look out for the dts (device-tree-source file in arch/powerpc/boot/dts), copy and modify one to reflect your hardware. Recently a lot of changes happend in the kernel, changing device names, obsoleting "device-type" tags, etc..., so some of the current DTS sources included in the kernel might not even work (wrong device name, missing information, wrong use of "device-type", etc...), so watch out for these kind of issues too. 4. Be sure that the device(s) necessary to produce output on your console are correctly placed in the DT. Also make sure that u-boot knows about it (#define OF_STDOUT_PATH... in your u-boot board config file) 5. When compiling the device tree, it may be necessary to add some extra reserved entries to the compiled tree (I am using dtc -p 10240 -R 20, which might be slightly exaggerated), because u-boot may add something to it, and if it can't, linux won't boot. 6. Remember to always specify the "rootfstype=" option on the commandline if booting from anything other than NFS. This was not necessary back in the 2.6.15-times AFAICR. 7. Boot with a device-tree (in u-boot: "bootm $addrofkernel - $addrofdtb", don't forget the dash if you are not using an initrd). If you don't do this, u-boot can't fix your DT, and the kernel probably won't find it either. 8. Be sure to use the correct version of the DTC (DT compiler) for your kernel (the sources are included nowadays, somewhere in arch/powerpc/boot IIRC). The command used to compile, should probably be something like this: $ ./dtc -p 10240 -R 20 -I dts -o myplatform.dtb -O dtb -b 0 dts/myplatform.dts Load the resulting .dtb file directly with u-boot (don't make an u-image out of it). That's all I remember right now... hope it helps. Regards, -- David Jander ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Added support for PRTLVT based boards (MPC5121)
On Friday 20 June 2008 16:36:20 you wrote: > I have a set of patches that I will be submitting later today that > adds the generic board support without removing ADS. So I would > prefer for you to just submit a device tree file for your board. Ok, thanks. I'll check your patches, fix our DT and resubmit that one. Greetings, -- David Jander Protonic Holland. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Added support for PRTLVT based boards (MPC5121)
Hi John, On Wednesday 18 June 2008 17:33:48 John Rigby wrote: > Hi David, > > Looks like your device tree is based on the beta ltib bsp. There were > some changes in release 1 that you may want to incorporate: > > First as a convention I changed all the interrupt numbers in the > tuples to be decimal. I like this better because the interrupts are > decimal in the reference manual. > > Second, the new clock driver that is in the release 1 bsp and will be > posting here shortly no longer uses the device tree, so you can remove > all the clk-name, clk-parent, clk-ctrl properties. Thanks, I'll incorporate these changes and submit again. Btw, do you agree with the following part of the patch? > > diff --git a/arch/powerpc/platforms/512x/Kconfig > > b/arch/powerpc/platforms/512x/Kconfig index 4c0da0c..57b3912 100644 > > --- a/arch/powerpc/platforms/512x/Kconfig > > +++ b/arch/powerpc/platforms/512x/Kconfig > > @@ -2,18 +2,20 @@ config PPC_MPC512x > >bool > >select FSL_SOC > >select IPIC > > - default n > > > > config PPC_MPC5121 > >bool > >select PPC_MPC512x > > - default n > > > > -config MPC5121_ADS > > - bool "Freescale MPC5121E ADS" > > +config MPC5121_GENERIC > > + bool "Generic support for simple MPC5121 based boards" > >depends on PPC_MULTIPLATFORM && PPC32 > >select DEFAULT_UIMAGE > >select PPC_MPC5121 > >help > > - This option enables support for the MPC5121E ADS board. > > - default n > > + This option enables support for a simple MPC5121 based boards > > which + do not need a custom platform specific setup. > > + > > + Boards that are compatible with this generic platform support > > + are: Freescale MPC5121 ADS and Protonic LVT based boards > > (ZANMCU + and VICVT2). > > diff --git a/arch/powerpc/platforms/512x/Makefile > > b/arch/powerpc/platforms/512x/Makefile index 232c89f..9d40a2e 100644 > > --- a/arch/powerpc/platforms/512x/Makefile > > +++ b/arch/powerpc/platforms/512x/Makefile > > @@ -1,4 +1,4 @@ > > # > > # Makefile for the Freescale PowerPC 512x linux kernel. > > # > > -obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o > > +obj-$(CONFIG_MPC5121_GENERIC) += mpc5121_generic.o > > diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c > > b/arch/powerpc/platforms/512x/mpc5121_generic.c similarity index 73% > > rename from arch/powerpc/platforms/512x/mpc5121_ads.c > > rename to arch/powerpc/platforms/512x/mpc5121_generic.c > > index 50bd3a3..824ddbb 100644 > > --- a/arch/powerpc/platforms/512x/mpc5121_ads.c > > +++ b/arch/powerpc/platforms/512x/mpc5121_generic.c >[...] The idea is to make it as simple as possible to add new platforms that are basically just derivatives of the same. Greetings, -- David Jander Protonic Holland. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head
On Thursday 12 June 2008 14:12:15 you wrote:
> On Jun 12, 2008, at 6:45 AM, David Jander wrote:
>
> Your commit message isn't exactly helpful as most people dont know
> what LTIB is and its not terribly relevant. It just seems like you
> are adding support for the FEC on MPC5121 and this point.
>
>[...]
> > --- a/drivers/net/fec.h
> > +++ b/drivers/net/fec.h
> > @@ -59,6 +59,7 @@ typedef struct fec {
> > } fec_t;
> >
> > #else
> > +#if !defined(CONFIG_FS_ENET_MPC5121_FEC)
> >
> > /*
> > * Define device register set address map.
> > @@ -97,6 +98,48 @@ typedef struct fec {
> > unsigned long fec_fifo_ram[112]; /* FIFO RAM buffer */
> > } fec_t;
> >
> > +#else /* CONFIG_FS_ENET_MPC5121_FEC */
> > +
> > +typedef struct fec {
> > [...]
> > +} fec_t;
> > +
> > +#endif /* CONFIG_FS_ENET_MPC5121_FEC */
> > #endif /* CONFIG_M5272 */
>
> I'm not exactly clear as to why this was done this way but this not
> acceptable as it means we can't build a multiplatform kernel that
> needs this driver.
Well, it wouldn't be possible either, since CONFIG_M5272 is a Cold-fire
processor, and CONFIG_FS_ENET_MPC5121_FEC is for a PowerPC processor.
In this case.
Otherwise you are right, the driver breaks MPC83xx/MPC5121 multiplatform
builds.
> I'm also not clear to me if the MPC5121 FEC is really the same device
> or close to it that it should be sharing this driver or have its own.
I am coming to the conclusion that it should have its own driver.
Altough a lot of code could be shared, there are still enough differences, so
that writing just ONE driver without some #ifdef's that would break
multiplatform builds, would instead end up with a much bigger amount of if's,
that would make it unreadable, unmaintainable and inefficient.
Here's why: The above struct fet_t for instance is mapped to a set of
registers in the FEC. For processors with a CPM1, a CPM2 or without CPM (i.e.
MPC5121) the register mapping seems to be significantly different,
nevertheless the structs are all called "struct fec_t". How can one fix this
at runtime without changing the name of the structs and then just use a lot
of "if's" or a combination of macro's and if's everywhere a register of the
FEC is accessed? I fear it will be a mess.
So I think it's either a separate driver, or break multiplatform builds.
Since I am learning from you that breaking multiplatform builds is a no-go,
I'll settle for splitting up the driver.
Any suggestion on where to put that split-off? How to name it?
I would suggest drivers/net/fec_mpc512x/*
I just resubmitted PATCH 1/2 again without part 2 (which hasn't much to do
with it anyway), so Grant may have a final look at it (hopefully I did it
right this time). Part 2 (MPC5121_FEC) will have to wait until monday or so,
since it will take me a while, and I have to do other things in between.
Any suggestions on how to solve the puzzle are of course welcome...
Thanks a lot for reviewing.
Best regards,
--
David Jander
Protonic Holland.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] Added support for PRTLVT based boards (MPC5121)
Made MPC5121_ADS board support generic:
Renamed arch/powerpc/platforms/512x/mpc5121_ads.c and added list of supported
boards.
For both MPC5121 ADS or PRTLVT support, just select "MPC5121_GENERIC" and use
the corresponding device-tree.
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prtlvt.dts | 255
arch/powerpc/platforms/512x/Kconfig| 14 +-
arch/powerpc/platforms/512x/Makefile |2 +-
.../512x/{mpc5121_ads.c => mpc5121_generic.c} | 38 ++-
4 files changed, 290 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/boot/dts/prtlvt.dts
rename arch/powerpc/platforms/512x/{mpc5121_ads.c => mpc5121_generic.c} (73%)
diff --git a/arch/powerpc/boot/dts/prtlvt.dts b/arch/powerpc/boot/dts/prtlvt.dts
new file mode 100644
index 000..aeb663b
--- /dev/null
+++ b/arch/powerpc/boot/dts/prtlvt.dts
@@ -0,0 +1,255 @@
+/*
+ * Device tree source for PRTLVT based boards, based on:
+ * MPC5121E MDS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ * Copyright 2008 Protonic Holland
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+ /* compile with: ./dtc -p 10240 -R 20 -I dts -o prtlvt.dtb -O dtb -b 0
dts/prtlvt.dts */
+
+/dts-v1/;
+
+/ {
+ model = "prtlvt";
+ compatible = "prt,prtlvt";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>;// L1, 32K
+ i-cache-size = <0x8000>;// L1, 32K
+ timebase-frequency = <5000>;// 50 MHz (csb/4)
+ bus-frequency = <2>;// 200 MHz csb bus
+ clock-frequency = <4>; // 400 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>; // 256MB at 0
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "prt,prtlvt-localbus", "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x8020 0x40>;
+ ranges = <0x0 0x0 0xfe00 0x0200>;
+ [EMAIL PROTECTED],0 {
+ compatible = "amd,s29gl256n", "cfi-flash";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0 0x0 0x0200>;
+ bank-width = <2>;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-immr", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x8000 0x40>;
+ reg = <0x8000 0x40>;
+ bus-frequency = <6600>; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell =
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+ };
+
+ // 512x PSCs are not 52xx PSCs compatible
+ // PSC0 serial port aka ttyPSC0
+ [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "fsl,mpc5121-psc-uart";
+ port-number = <0>;
+ cell-index = <0>;
+ reg = <0x11000 0x100>;
+ interrupts = <0x28 0x8>; // actually the fifo irq
+ interrupt-parent = < &ipic >;
+ };
+
+ // PSC
[PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +-
drivers/net/fec.h | 43
drivers/net/fs_enet/Kconfig| 22 +-
drivers/net/fs_enet/fs_enet-main.c | 76 ++--
drivers/net/fs_enet/fs_enet.h | 17 +---
drivers/net/fs_enet/mac-fec.c | 22 +-
drivers/net/fs_enet/mii-fec.c | 10 -
7 files changed, 167 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 87454c5..a96937f 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -288,7 +288,7 @@ config CPM2
config PPC_CPM_NEW_BINDING
bool
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
default y
config AXON_RAM
diff --git a/drivers/net/fec.h b/drivers/net/fec.h
index 292719d..5c9fe34 100644
--- a/drivers/net/fec.h
+++ b/drivers/net/fec.h
@@ -59,6 +59,7 @@ typedef struct fec {
} fec_t;
#else
+#if !defined(CONFIG_FS_ENET_MPC5121_FEC)
/*
* Define device register set address map.
@@ -97,6 +98,48 @@ typedef struct fec {
unsigned long fec_fifo_ram[112]; /* FIFO RAM buffer */
} fec_t;
+#else /* CONFIG_FS_ENET_MPC5121_FEC */
+
+typedef struct fec {
+ u32 fec_reserved0;
+ u32 fec_ievent; /* Interrupt event reg */
+ u32 fec_imask; /* Interrupt mask reg */
+ u32 fec_reserved1;
+ u32 fec_r_des_active; /* Receive descriptor reg */
+ u32 fec_x_des_active; /* Transmit descriptor reg */
+ u32 fec_reserved2[3];
+ u32 fec_ecntrl; /* Ethernet control reg */
+ u32 fec_reserved3[6];
+ u32 fec_mii_data; /* MII manage frame reg */
+ u32 fec_mii_speed; /* MII speed control reg */
+ u32 fec_reserved4[7];
+ u32 fec_mib_ctrlstat; /* MIB control/status reg */
+ u32 fec_reserved5[7];
+ u32 fec_r_cntrl;/* Receive control reg */
+ u32 fec_reserved6[15];
+ u32 fec_x_cntrl;/* Transmit Control reg */
+ u32 fec_reserved7[7];
+ u32 fec_addr_low; /* Low 32bits MAC address */
+ u32 fec_addr_high; /* High 16bits MAC address */
+ u32 fec_opd;/* Opcode + Pause duration */
+ u32 fec_reserved8[10];
+ u32 fec_hash_table_high;/* High 32bits hash table */
+ u32 fec_hash_table_low; /* Low 32bits hash table */
+ u32 fec_grp_hash_table_high;/* High 32bits hash table */
+ u32 fec_grp_hash_table_low; /* Low 32bits hash table */
+ u32 fec_reserved9[7];
+ u32 fec_x_wmrk; /* FIFO transmit water mark */
+ u32 fec_reserved10;
+ u32 fec_r_bound;/* FIFO receive bound reg */
+ u32 fec_r_fstart; /* FIFO receive start reg */
+ u32 fec_reserved11[11];
+ u32 fec_r_des_start;/* Receive descriptor ring */
+ u32 fec_x_des_start;/* Transmit descriptor ring */
+ u32 fec_r_buff_size;/* Maximum receive buff size */
+ u32 fec_dma_control;/* DMA Endian and other ctrl */
+} fec_t;
+
+#endif /* CONFIG_FS_ENET_MPC5121_FEC */
#endif /* CONFIG_M5272 */
diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index 562ea68..5e2520b 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -1,9 +1,23 @@
config FS_ENET
tristate "Freescale Ethernet Driver"
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
select MII
select PHYLIB
+config FS_ENET_MPC5121_FEC
+ bool "Freescale MPC512x FEC driver"
+ depends on PPC_MPC512x
+ select FS_ENET
+ select FS_ENET_HAS_FEC
+
+config FS_ENET_TX_ALIGN_WORKAROUND
+ bool "MPC5121 FEC driver TX alignment workaround"
+ depends on FS_ENET_MPC5121_FEC
+ help
+ Workaround for a problem with early Freescale MPC5121 chips.
+ If unsure say 'y'
+ default y
+
config FS_ENET_HAS_SCC
bool "Chip has an SCC usable for ethernet"
depends on FS_ENET && (CPM1 || CPM2)
@@ -16,13 +30,15 @@ config FS_ENET_HAS_FCC
config FS_ENET_HAS_FEC
bool "Chip has an FEC usable for ethernet"
- depends on FS_ENET && CPM1
+ depends on FS_ENET && (CPM1 || FS_ENET_MPC5121_FEC)
select FS_ENET_MDIO_FEC
default y
+
config FS_ENET_MDIO_FEC
tristate "MDIO driver for FEC"
- depends on FS_ENET && CPM1
+ depends on FS_ENET && (CPM1 || FS_ENET_MPC5121_FEC)
+
config FS_ENET_MDIO_FCC
tristate "MDIO driver for FCC"
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 31c9693..54f0079 100
[PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
Made MPC5121_ADS board support generic:
Renamed arch/powerpc/platforms/512x/mpc5121_ads.c and added list of supported
boards.
For both MPC5121 ADS or PRTLVT support, just select "MPC5121_GENERIC" and use
the corresponding device-tree.
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prtlvt.dts | 272
arch/powerpc/platforms/512x/Kconfig| 14 +-
arch/powerpc/platforms/512x/Makefile |2 +-
.../512x/{mpc5121_ads.c => mpc5121_generic.c} | 38 ++-
4 files changed, 307 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/boot/dts/prtlvt.dts
rename arch/powerpc/platforms/512x/{mpc5121_ads.c => mpc5121_generic.c} (73%)
diff --git a/arch/powerpc/boot/dts/prtlvt.dts b/arch/powerpc/boot/dts/prtlvt.dts
new file mode 100644
index 000..a011c8c
--- /dev/null
+++ b/arch/powerpc/boot/dts/prtlvt.dts
@@ -0,0 +1,272 @@
+/*
+ * Device tree source for PRTLVT based boards, base on:
+ * MPC5121E MDS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ * Copyright 2008 Protonic Holland
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+ /* compile with: ./dtc -p 10240 -R 20 -I dts -o prtlvt.dtb -O dtb -b 0
dts/prtlvt.dts */
+
+/dts-v1/;
+
+/ {
+ model = "prtlvt";
+ compatible = "prt,prtlvt";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>;// L1, 32K
+ i-cache-size = <0x8000>;// L1, 32K
+ timebase-frequency = <5000>;// 50 MHz (csb/4)
+ bus-frequency = <2>;// 200 MHz csb bus
+ clock-frequency = <4>; // 400 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>; // 256MB at 0
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "amd,s29gl256n", "cfi-flash";
+ reg = <0xfe00 0x0200>;
+ bank-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ [EMAIL PROTECTED] {
+ label = "rootfs";
+ reg = <0x 0x0180>;
+ };
+ [EMAIL PROTECTED] {
+ label ="config0";
+ reg = <0x0180 0x0020>;
+ };
+ [EMAIL PROTECTED] {
+ label ="config1";
+ reg = <0x01a0 0x0020>;
+ };
+ [EMAIL PROTECTED] {
+ label ="kernel";
+ reg = <0x01c0 0x002e>;
+ };
+ [EMAIL PROTECTED] {
+ label ="devicetree";
+ reg = <0x01ee 0x0002>;
+ };
+ [EMAIL PROTECTED] {
+ label ="uboot";
+ reg = <0x01f0 0x0010>;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-immr", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x8000 0x40>;
+ reg = <0x8000 0x40>;
+ bus-frequency = <6600>; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell =
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB
On Wednesday 11 June 2008 20:19:17 Scott Wood wrote:
> Please post patches to linuxppc-dev rather than linuxppc-embedded --
> you'll get a larger reviewing audience.
Ok, but I thought linuxppc-dev was for all non-embedded development only...
> PPC_CPM_NEW_BINDING is default y, and will be going away as an option as
> soon as arch/ppc does. In the meantime, instead of selecting it here,
> add FS_ENET_MPC5121_FEC to the depends list of PPC_CPM_NEW_BINDING -- or
> just remove the depends list altogether.
Good idea, done that.
> > +/*
> > + * Define the buffer descriptor structure.
> > + */
> > +typedef struct bufdesc {
> > + unsigned short cbd_sc; /* Control and status info */
> > + unsigned short cbd_datlen; /* Data length */
> > + unsigned long cbd_bufaddr;/* Buffer address */
> > +} cbd_t;
>
> This can be factored out into a common header -- along with most if not
> all of the flag defines.
Ok, I added the changes to ../fec.h inside an #if-#else.
> > +#define TX_ALIGN_WORKAROUND
> > +#ifdef TX_ALIGN_WORKAROUND
> > +static struct sk_buff *aligntxskb(struct net_device *dev, struct sk_buff
> > *skb) +{
> > + struct sk_buff *skbn;
> > + skbn = dev_alloc_skb(ENET_RX_FRSIZE+0x20);
> > + if (skbn)
> > + skb_align(skbn, 0x20);
> > +
> > + if (!skbn) {
> > + printk(KERN_WARNING DRV_MODULE_NAME
> > + ": %s Memory squeeze, dropping tx packet.\n",
> > + dev->name);
> > + dev_kfree_skb_any(skb);
> > + return NULL;
> > + }
> > +
> > + skb_copy_from_linear_data(skb, skbn->data, skb->len);
> > + skb_put(skbn, skb->len);
> > + dev_kfree_skb_any(skb);
> > + return skbn;
> > +}
> > +#else
> > +#define aligntxskb(skb) skb
> > +#endif
>
> Can we encode the required alignment for rx and tx in the device tree?
Hmmm... This actually is a silicon-bug workaround AFAIK.
I agree with you that this solution is not good, but I doubt resolving this
in the device-tree is much better. It will add run-time overhead just because
right now there are some buggy chips around. I think this could better
be a Kconfig option, so people can have faster kernels if they want later.
If you are concerned about multiplatform kernels, this shouldn't harm.
>[...]
> > + printk("<1> %s: %s (%d)\n",__FILE__,__FUNCTION__,__LINE__);
>
> Please use the KERN_ prefixes rather than hardcoding the number, and put
> spaces after commas. Of course, if this is to be here at all, this
> should be dev_dbg() rather than KERN_ALERT.
Ooops. This shouldn't be here. Removing it.
> > -#define __cbd_out32(addr, x) out_be32(addr, x)
> > -#define __cbd_out16(addr, x) out_be16(addr, x)
> > -#define __cbd_in32(addr) in_be32(addr)
> > -#define __cbd_in16(addr) in_be16(addr)
> > +#define __cbd_out32(addr, x) out_be32((volatile void __iomem *)addr,
> > x)
> > +#define __cbd_out16(addr, x) out_be16((volatile void __iomem *)addr,
> > x)
> > +#define __cbd_in32(addr) in_be32((volatile void __iomem *)addr)
> > +#define __cbd_in16(addr) in_be16((volatile void __iomem *)addr)
>
> NACK, please don't remove type checking.
Ok, but given the macro's further down, I'll have to cast there...
#define CBDR_BUFADDR(_cbd) __cbd_in32((volatile void __iomem
*)&(_cbd)->cbd_bufaddr)
> > +#ifndef CONFIG_FS_ENET_MPC5121_FEC
> > FW(fecp, r_hash, PKT_MAXBUF_SIZE);
> > +#endif
> >
> > /* get physical address */
> > rx_bd_base_phys = fep->ring_mem_addr;
> > @@ -320,10 +325,17 @@ static void restart(struct net_device *dev)
> >
> > fs_init_bds(dev);
> >
> > +#ifndef CONFIG_FS_ENET_MPC5121_FEC
> > /*
> > * Enable big endian and don't care about SDMA FC.
> > */
> > FW(fecp, fun_code, 0x7800);
> > +#else
> > + /*
> > +* Set DATA_BO and DESC_BO and leave the rest unchanged
> > +*/
> > + FS(fecp, dma_control, 0xc000);
> > +#endif
I have tried, but it is almost impossible, since both FEC types use a struct
named "fec_t" which very different betwen both types. That means that the code
would have enormous amounts of "if" statements all over.
Any suggestion?
Best regards,
--
David Jander
Protonic Holland.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
On Wednesday 11 June 2008 19:58:32 Scott Wood wrote:
> Pass -B -M -C to git-format-patch to detect renames, copies, etc.
Thanks for the hint. I am still a git-noob ;-)
>[...]
> This is an old flash binding. Please use the one currently described in
> Documentation/booting-without-of.txt.
Thanks again, I was searching for documentation about dts, and couldn't find
much.
> > + //[EMAIL PROTECTED] {
> > + // compatible = "mpc512x-axe";
> > + // reg = <2000 100>;
> > + // interrupts = <2a 8>;
> > + // interrupt-parent = < &ipic >;
> > + //};
>
> Why is this here, but commented out?
Hmm, I know we are going to use it, but there are no drivers still...
I'll leave it out, and add it again later when axe-support has arrived.
> > + [EMAIL PROTECTED] {
> > + compatible = "fsl,mpc5121-dma2";
>
> Is this DMA controller compatible with drivers/dma/fsldma.c? If so,
> follow the established binding.
No, it's not compatible with any other dma controller AFAIK. It special for
this chip. John Rigby is writing the driver for it right now.
> > +config MPC5121_GENERIC
> > + bool
> > + default n
> > +
> > config MPC5121_ADS
> > bool "Freescale MPC5121E ADS"
> > depends on PPC_MULTIPLATFORM && PPC32
> > select DEFAULT_UIMAGE
> > select PPC_MPC5121
> > + select MPC5121_GENERIC
> > help
> > This option enables support for the MPC5121E ADS board.
> > default n
> > +
> > +config PRTLVT
> > + bool "Protonic LVT family of MPC5121 based boards"
> > + depends on PPC_MULTIPLATFORM && PPC32
> > + select DEFAULT_UIMAGE
> > + select PPC_MPC5121
> > + select MPC5121_GENERIC
> > + help
> > + This option enables support for the Protonic LVT family (ZANMCU and
> > VICVT2). + default n
>
> Can we leave out the "default n" lines? They're no-ops.
Ok, I removed also several others (all of them in this file). I hope that it
is not a problem not making this a separate patch?
> I don't think these configs should depend on an option
> (PPC_MULTIPLATFORM) that is described as "Generic desktop/server/laptop"...
I think right now they need to. That's the way someone broke...err changed
platform selection.
We should fix that later, but I don't really know what would be the right way
to fix this right now. I'll think about it after this...
Btw, is it ok I just re-submit the fixed patches (with cc to linuxppc-dev)?
Thanks.
Greetings,
--
David Jander
Protonic Holland.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB
to current head
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/Kconfig| 16 -
drivers/net/fs_enet/fec_mpc5121.h | 120
drivers/net/fs_enet/fs_enet-main.c | 90 +++
drivers/net/fs_enet/fs_enet.h | 14 +++-
drivers/net/fs_enet/mac-fec.c | 22 ++-
drivers/net/fs_enet/mii-fec.c | 10 +++-
6 files changed, 249 insertions(+), 23 deletions(-)
create mode 100644 drivers/net/fs_enet/fec_mpc5121.h
diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index 562ea68..8eea038 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -1,9 +1,17 @@
config FS_ENET
tristate "Freescale Ethernet Driver"
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
select MII
select PHYLIB
+config FS_ENET_MPC5121_FEC
+ bool "Freescale MPC512x FEC driver"
+ depends on PPC_MPC512x
+ select FS_ENET
+ select FS_ENET_HAS_FEC
+ select PPC_CPM_NEW_BINDING
+ default n
+
config FS_ENET_HAS_SCC
bool "Chip has an SCC usable for ethernet"
depends on FS_ENET && (CPM1 || CPM2)
@@ -16,13 +24,15 @@ config FS_ENET_HAS_FCC
config FS_ENET_HAS_FEC
bool "Chip has an FEC usable for ethernet"
- depends on FS_ENET && CPM1
+ depends on FS_ENET && (CPM1 || FS_ENET_MPC5121_FEC)
select FS_ENET_MDIO_FEC
default y
+
config FS_ENET_MDIO_FEC
tristate "MDIO driver for FEC"
- depends on FS_ENET && CPM1
+ depends on FS_ENET && (CPM1 || FS_ENET_MPC5121_FEC)
+
config FS_ENET_MDIO_FCC
tristate "MDIO driver for FCC"
diff --git a/drivers/net/fs_enet/fec_mpc5121.h
b/drivers/net/fs_enet/fec_mpc5121.h
new file mode 100644
index 000..b8a69d4
--- /dev/null
+++ b/drivers/net/fs_enet/fec_mpc5121.h
@@ -0,0 +1,120 @@
+/*
+ * Copyright (C) 2007,2008 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: John Rigby, <[EMAIL PROTECTED]>
+ *
+ * Modified version of drivers/net/fec.h:
+ *
+ * fec.h -- Fast Ethernet Controller for Motorola ColdFire SoC
+ *processors.
+ *
+ * (C) Copyright 2000-2005, Greg Ungerer ([EMAIL PROTECTED])
+ * (C) Copyright 2000-2001, Lineo (www.lineo.com)
+ *
+ * This is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef FEC_MPC5121_H
+#define FEC_MPC5121_H
+
+typedef struct fec {
+ u32 fec_reserved0;
+ u32 fec_ievent; /* Interrupt event reg */
+ u32 fec_imask; /* Interrupt mask reg */
+ u32 fec_reserved1;
+ u32 fec_r_des_active; /* Receive descriptor reg */
+ u32 fec_x_des_active; /* Transmit descriptor reg */
+ u32 fec_reserved2[3];
+ u32 fec_ecntrl; /* Ethernet control reg */
+ u32 fec_reserved3[6];
+ u32 fec_mii_data; /* MII manage frame reg */
+ u32 fec_mii_speed; /* MII speed control reg */
+ u32 fec_reserved4[7];
+ u32 fec_mib_ctrlstat; /* MIB control/status reg */
+ u32 fec_reserved5[7];
+ u32 fec_r_cntrl;/* Receive control reg */
+ u32 fec_reserved6[15];
+ u32 fec_x_cntrl;/* Transmit Control reg */
+ u32 fec_reserved7[7];
+ u32 fec_addr_low; /* Low 32bits MAC address */
+ u32 fec_addr_high; /* High 16bits MAC address */
+ u32 fec_opd;/* Opcode + Pause duration */
+ u32 fec_reserved8[10];
+ u32 fec_hash_table_high;/* High 32bits hash table */
+ u32 fec_hash_table_low; /* Low 32bits hash table */
+ u32 fec_grp_hash_table_high;/* High 32bits hash table */
+ u32 fec_grp_hash_table_low; /* Low 32bits hash table */
+ u32 fec_reserved9[7];
+ u32 fec_x_wmrk; /* FIFO transmit water mark */
+ u32 fec_reserved10;
+ u32 fec_r_bound;/* FIFO receive bound reg */
+ u32 fec_r_fstart; /* FIFO receive start reg */
+ u32 fec_reserved11[11];
+ u32 fec_r_des_start;/* Receive descriptor ring */
+ u32 fec_x_des_start;/* Transmit descriptor ring */
+ u32 fec_r_buff_size;/* Maximum receive buff size */
+ u32 fec_dma_control;/* DMA Endian and other ctrl */
+} fec_t;
+
+/*
+ * Define the buffer descriptor structure.
+ */
+typedef struct bufdesc {
+ unsigned short cbd_sc; /* Control and status info */
+ unsigned short cbd_datlen; /* Data length */
+ unsigned long cbd_bufaddr;/* Buffer address */
+} cbd_t;
[PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
Made MPC5121_ADS board support generic
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prtlvt.dts | 267 +
arch/powerpc/platforms/512x/Kconfig | 15 ++
arch/powerpc/platforms/512x/Makefile |2 +-
arch/powerpc/platforms/512x/mpc5121_ads.c | 104 --
arch/powerpc/platforms/512x/mpc5121_generic.c | 105 ++
5 files changed, 388 insertions(+), 105 deletions(-)
create mode 100644 arch/powerpc/boot/dts/prtlvt.dts
delete mode 100644 arch/powerpc/platforms/512x/mpc5121_ads.c
create mode 100644 arch/powerpc/platforms/512x/mpc5121_generic.c
diff --git a/arch/powerpc/boot/dts/prtlvt.dts b/arch/powerpc/boot/dts/prtlvt.dts
new file mode 100644
index 000..93d2fa2
--- /dev/null
+++ b/arch/powerpc/boot/dts/prtlvt.dts
@@ -0,0 +1,267 @@
+/*
+ * Device tree source for PRTLVT based boards, base on:
+ * MPC5121E MDS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ * Copyright 2008 Protonic Holland
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+ /* compile with: ./dtc -p 10240 -R 20 -I dts -o prtlvt.dtb -O dtb -b 0
dts/prtlvt.dts */
+
+/dts-v1/;
+
+/ {
+ model = "prtlvt";
+ compatible = "prt,prtlvt";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>;// L1, 32K
+ i-cache-size = <0x8000>;// L1, 32K
+ timebase-frequency = <5000>;// 50 MHz (csb/4)
+ bus-frequency = <2>;// 200 MHz csb bus
+ clock-frequency = <4>; // 400 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>; // 256MB at 0
+ };
+
+ [EMAIL PROTECTED] {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ probe-type = "CFI";
+ reg = <0xfe00 0x0200>;
+ bank-width = <2>;
+ partitions = <0x 0x0180 // filesystem
+ 0x0180 0x0020 // config0
+ 0x01a0 0x0020 // config1
+ 0x01c0 0x002e // kernel
+ 0x01ee 0x0002 // one sector for device
tree
+ 0x01f0 0x0010>; // u-boot
+ partition-names = "filesystem", "config0", "config1","kernel",
"device-tree", "u-boot";
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-immr";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x8000 0x40>;
+ reg = <0x8000 0x40>;
+ bus-frequency = <6600>; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell =
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+ };
+
+ // 512x PSCs are not 52xx PSCs compatible
+ // PSC0 serial port aka ttyPSC0
+ [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "fsl,mpc5121-psc-uart";
+ port-number = <0>;
+ cell-index = <0>;
+ reg = <0x11000 0x100>;
+ interrupts = <0x28 0x8>; // actually the fifo irq
+ interrupt-parent = < &ipic >;
+
Ooops... Re: [PATCH] prtlvt board support (MPC5121e) added
On Tuesday 10 June 2008 22:35:11 you wrote: > In message <[EMAIL PROTECTED]> you wrote: > > Signed-off-by: David Jander <[EMAIL PROTECTED]> > > --- > > arch/powerpc/boot/dts/prtlvt.dts | 280 > > ++ arch/powerpc/platforms/512x/Kconfig | > >9 + > > arch/powerpc/platforms/512x/Makefile |1 + > > arch/powerpc/platforms/512x/prtlvt.c | 105 + > > 4 files changed, 395 insertions(+), 0 deletions(-) > > create mode 100644 arch/powerpc/boot/dts/prtlvt.dts > > create mode 100644 arch/powerpc/platforms/512x/prtlvt.c > > This doesn't apply on top of the original LTIB source tree: It was meant for application on denx git master head, not LTIB, which is outdated. Anyway, this patch was sent by accident. Sorry for that mistake. My intention is to end up with full MPC5121 support in mainline kernel. The first step (for me) was our BSP. Then a patch to make fs_enet working would follow. I have that one prepared also, but it is still not quite right... I am still fighting with git about it ;-) It was very late yesterday, and I am still learning how to use GIT correctly. I prepared the e-mail for submission (more to see how its done, than with the true intention of actually sending it), and must have hit the "send" button by accident. I was supposed to review this patch first, and now Grant won the race ;-) I was in the middle of trying to figure out how to fill in the right e-mail headers automatically with git-format-patch. So I believe it was a beginners mistake, sorry for that, and thanks for reviewing it anyway... Greetings, -- David Jander Protonic Holland. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] prtlvt board support (MPC5121e) added
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prtlvt.dts | 280 ++
arch/powerpc/platforms/512x/Kconfig |9 +
arch/powerpc/platforms/512x/Makefile |1 +
arch/powerpc/platforms/512x/prtlvt.c | 105 +
4 files changed, 395 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/prtlvt.dts
create mode 100644 arch/powerpc/platforms/512x/prtlvt.c
diff --git a/arch/powerpc/boot/dts/prtlvt.dts b/arch/powerpc/boot/dts/prtlvt.dts
new file mode 100644
index 000..238dc89
--- /dev/null
+++ b/arch/powerpc/boot/dts/prtlvt.dts
@@ -0,0 +1,280 @@
+/*
+ * MPC5121E MDS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+ /* compile with: ./dtc -p 10240 -R 20 -I dts -o prtlvt.dtb -O dtb -b 0
dts/prtlvt.dts */
+
+/dts-v1/;
+
+/ {
+ model = "prtlvt";
+ compatible = "fsl,prtlvt";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>;// L1, 32K
+ i-cache-size = <0x8000>;// L1, 32K
+ timebase-frequency = <5000>;// 50 MHz (csb/4)
+ bus-frequency = <2>;// 200 MHz csb bus
+ clock-frequency = <4>; // 400 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>; // 256MB at 0
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,prtlvt-localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x8020 0x40>;
+
+ ranges = <0x0 0x0 0xfe00 0x0200>;
+
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <0 0x0 0x400>;
+ bank-width = <4>;
+ device-width = <1>;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-immr";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x8000 0x40>;
+ reg = <0x8000 0x40>;
+ bus-frequency = <6600>; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell =
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+ };
+
+ // 512x PSCs are not 52xx PSCs compatible
+ // PSC0 serial port A aka ttyPSC0
+ [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "fsl,mpc5121-psc-uart";
+ // Logical port assignment needed until driver
+ // learns to use aliases
+ port-number = <0>;
+ cell-index = <0>;
+ reg = <0x11000 0x100>;
+ interrupts = <0x28 0x8>; // actually the fifo irq
+ interrupt-parent = < &ipic >;
+ };
+
+ // PSC1 serial port A aka ttyPSC1
+ [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "fsl,mpc5121-psc-uart";
+ // Logical port assignment needed until driver
+ // learns to use aliases
+ port-number = <1>;
+ cell-index = <1>;
+ reg
MPC5121e Freescale BSP...
Hi everyone, I have an ADS5121 evaluation module from Freescale, and wonder if there's any Freescale engineer on this list working on the linux BSP for this processor/SoC/platform? I have downloaded the latest alpha release of the BSP and found it to be completely unusable. I took some time to fix the framebuffer driver, and make console-fb work, I even sent patches to our Freescale contact, while I already suspected it to be completely useless, since the BSP is already lacking behind several months from actual Freescale code, and all those issues are most probably fixed already. Only problem: I can't seem to get the latest versions of it. I heared rumors they'll release a new version next week or so, but I fear it will also lack behind development, and fixing bugs myself or contributing code will be a useless waste of time! Is there any Freescale engineer on this list that can help out, or at least clarify the reasons behind closed-doors open-source software development?? On the other hand, I also whish to contact other furtunate owners of PPC5121e-based hardware to join forces on linux-kernel driver development. If Freescale won't collaborate, I'd even consider forking their code, if necessary. Greetings, -- David Jander Protonic Holland. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
eraseblock-size independent flash rootfs
Hi, I have been looking for a practical way to build an embedded system with a root filesystem which can be modified file-by-file eventually (to apply small software patches for example), but is independent of flash attributes such as erase-block size (which happens to change sometimes from one production series to another without much notice, for instance S29GL256M11 with 64k blocks to S29GL256N90 with 128k blocks). The problem with using plain jffs2 until now is that we cannot make one jffs2 image for both hardware versions, since the image has to be generated specifying the erase-block size. I am considering on using a read-only filesystem like squashfs or cramfs and, layered on top of it, a read-only filesystem like jffs2 for modifications. The jffs2 partition could just start out as empty flash, so it doesn't matter much if the device has 64k erase-blocks or 128k eraseblocks... it just has to start at an 128k boundary. I have to make the following choices and I am curious if anybody has something to tell against or in favour of any of them: 1.- Which read-only fs to use: squashfs or cramfs? Squashfs seems newer and better performing, so I guess I'll go with that one. 2.- Which union-fs to use: unionfs, aufs or mini_fo? Don't know which to choose. Unionfs is in latest -mm trees and also supports 2.4 kernels (one of our products still runs on 2.4.xx), so chances are it gets part of the main tree some day... but aufs seems more popular, and many developers seem to switch from unionfs to aufs lately, but I don't seem to find much information about this. Any suggestions are welcome. Greetings, -- David Jander ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CAN YOU HELLP ME
On Wednesday 20 June 2007 04:20:09 volcano wrote: > hello my dear friend: >I have read the u-boot last week ,and thank you for all your kind > help.My linux code is based on MPC8260,so I want to continue the read of > the linux2.6.18 based on mpc8260.can you give me some kind suggestions > about how to read all these codes clearly.,and if some reference is given > would be welcome. I suppose you want to have something as a guide to the linux-kernel source-code, right? Well, I haven't found anything like that exactly, but luckily the source-code is mostly quite easy to understand, and after fiddling for a while you'll get the hang of it. Here you might find some useful information on books and on-line material over the linux kernel: http://www.linux.org/dist/kernel.html It is also helful to check the lkml (linux-kernel-mailing list) every now and then, to see what's "hot". The kernel itself is in constant changes that happen so quickly, that after finishing a guide like this, you would probably already need to change it. Therefore it is the intention to make the linux-kernel sources as readable as possible, so that the code is self-explanatory. The code itself is the manual. Greetings, -- David Jander ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Freescale MPC5121e support anybody?
Hi all, Now that there are official details about this very promising looking chip, is there anyone preparing linux support for it (maybe from Freescale)? http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC512X I can imagine this being the perfect killer-SOC for many embedded-linux applications... Just curious, -- David Jander ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xubuntu and Xenomai on the Lite5200 (IceCube)...
On Monday 30 October 2006 18:58, Grant Likely wrote: >[...] >> > Congratulations, that's good work! Especially the bit about > documenting what you did! I've been meaning to play w/ xenomai for a > while now. Thanks. I hope this makes searching-time shorter for you. I wish I could remember more details about what I exactly changed to make the kernel compile after backporting bestcomm and FEC... I vaguely remember adding "#include " to at least two files... > Care to help with the port to arch/powerpc now? :P I would really like to, but I have very limited time to dedicate to such things. If I get the chance to do something about it, I'll do it, I promise. The time will come when I'll have to port our own board-support stuff to arch/powerpc... so... Greetings, -- David Jander ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: AW: Xubuntu and Xenomai on the Lite5200 (IceCube)...
On Monday 30 October 2006 16:32, Achim Machura wrote: > Hello, David, > > We have had the same problem, > > after enabling pci in the kernelconfig, > usb is working. Duh. And how is one supposed to know that? Thanks for the tip ;-) Greetings, -- David Jander ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Xubuntu and Xenomai on the Lite5200 (IceCube)...
Hi all, I got the task to help make Linux run on the IceCube, with support for MSCAN, FEC and USB. After a rather exciting jurney I managed to get kernel 2.6.18 working with bestcomm DMA and FEC support backported from DENX's git 2.6.19-rcsomething, and Xenomai installed upon that. Btw, before Wolfgang Denk starts complaining why I didn't use his 2.4 kernel, it's because I wasn't smart enough to get USB working. If it does work, please tell me how, I just get errors when plugging in a USB device "kernel: usb.c: USB device not accepting new address=2 (error=-110)". This seems to work fine in 2.6, though. It was not easy, so I wrote everything down (I hope I didn't forget anything important): http://yopesblog.blogspot.com/2006/10/how-to-run-ubuntu-and-xenomai-on.html If anyone wants to tell me what I did wrong (probably a lot), please tell me. I am posting this to the list hoping someone else will benefit from it. I certainly would have. Greetings, -- David Jander ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
frequent sig 11 with malloc() on mpc8xx
On Thursday 04 May 2006 16:46, Wolfgang Denk wrote: > Ummm... I have yet to see a single case where moving to 2.6 improved > the stability for a MPC8xx system :-( Our case. Jffs2's gc thread stopped crashing. This might have more to do with mtd/jffs2 than with the rest of the kernel, but it sure works better now. Nevertheless I am very interested in hearing about (potential) stability problems with with 2.6.14, 15 and 16 (besides not booting just because Marcelo couldn't resist screwing up on the last minute; problem which is being worked on ;-). Greetings, -- David Jander
Linux 2.6 sources for MPC852T processor
Hi, I did the following: $ patch -p1
Linux 2.6 sources for MPC852T processor
On Thursday 27 April 2006 01:32, Dan Malek wrote: > There is a horrible bug in the 8xx TLB miss handler that is in the > 2.6.16 > sources. I don't know when it appeared. Enable the CPU6 Errata > workaround to see if that solves the problem and please report back > to me. I'm working on a solution. I received instructions from Marcelo to reverse two patches he sent me this morning, that did solve the problem. In fact those patches changed some TLB-related assembly code in head_8xx.S Greetings, -- David Jander
Linux 2.6 sources for MPC852T processor
On Wednesday 26 April 2006 11:50, Chandrasekhar Nagaraj wrote: > Hi, > I have a customized board based on the MPC852T based processor. > I intend to develop a BSP for this board. > > Does 2.6.16 from the kernel.org support this processor? First of all, please avoid HTML in e-mail messages. It is hard to read, and normally banned on mailing list such as this one. Yes, MPC852T is supported, although I might add that I have been using 2.6.14 and 2.6.15 sucessfully with our own MPC852T-based board, but 2.6.16 did not boot and as of today I don't know why, or whether this is an issue at all with boards other than ours. > > In the 2.6.16 sources I found support for CONFIG_8xx. Does this mean > that 852T processor is also supported? Yes. Look at BSP stuff for other 8xx boards to learn how to port yours. Keep an eye on the new platform_bus stuff, that's currently being implemented for different drivers and subsystmes for powerpc (this could be the reason, our own BSP stuff stopped working with 2.6.16, btw). Also a transition from /arch/ppc and /arch/ppc64 towards the common /arch/powerpc is in progress, and therefore some things might be in a state of flux between released versions of the kernel. As of today (kernel 2.6.16) the architecture you need to use is still /arch/ppc. Good luck! Greetings, -- David Jander
[PATCH] fix cpm_uart driver for PQ1...
Hi, This patch fixes the following three problems: 1. Memory mapping virtual<-->dma is broken in the case that CONFIG_CONSISTENT_START > CPM_ADDR. 2. SCC uart sends a break sequence each time it is stopped with the CPM_CR_STOP_TX command. That means that each time an application closes the serial device, a break is transmitted. 3. Implemented default BRG routing for PQ1 (in the same sense as it is done for PQ2). Signed-off-by: David Jander Regards, David. -- next part -- A non-text attachment was scrubbed... Name: cpm_uart_patch.diff Type: text/x-diff Size: 6578 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060425/b91f30b5/attachment.diff
Upgrading cramfs root file system while running (DENX wrote that is not possible)
Hi, On Thursday 20 April 2006 23:03, Antonio Di Bacco wrote: > Yes, I also thought this too. Anything important should stay already in RAM > but there is a chance that something bad could happen. Probably the best What do you mean with "something bad could happen"? The only thing I can think of is pulling the power plug while flash is being erased or written. What else could go wrong? We do the following: system running from read-only jffs2 partition. Sometimes that partition is remounted read-write and single files are replaced, but in some occasions we need to upgrade the whole fs. In that case a CGI lodas the image into a ramdisk, and the upgrade process is started. For upgrade, 'eraseall' and 'dd' (from busybox) are needed. First, all unnecessary processes are killed (the webserver stays alive to be able to report the status when finished), then "dd" is called for a dummy operation (to have it cached). After that the upgrade tool calls "eraseall" on the rootfs partition, and then "dd" again to copy the image. At that point no critical flash-read access should be requested since dd is already in cache (it's busybox, so it's almost always in RAM anyway). When dd is finished, the only other thing that's needed is to either be able to send some last html strings to the web-server to complete the progress page and tell the user, that it's ok to pull the plug, or reset the system, we don't care if the rest of the system goes belly-up, since the fs was mounted read-only anyway, and the upgrade is finished. Of course this isn't failsafe, so there should always be a way to recover if the rootfs gets trashed, but most of the time it's acceptable that service personel is required in that situation. Until now, it has never been required though. > thing is what you suggested as second option but I have not so much ram. My > CGI writes the downloaded new software in RAM and then I should directly > jump to u-boot without leaving Linux the chance to mix things up and then > u-boot should copy the RAM to the flash. It seems a strange procedure but > what else could be done with 4MB flash and 16 MB ram? Run from initrd? Maybe an uncomressed filesystem on a ramdisk to be able to do XIP (execute in place)? Greetings, -- David Jander
kernel 2.6.15: cpm_uart driver broken?
:initbd\n", pinfo->port.line);
@@ -689,14 +680,15 @@
* virtual address for us to work with.
*/
mem_addr = pinfo->mem_addr;
+ dma_offset = pinfo->dma_offset;
bdp = pinfo->rx_cur = pinfo->rx_bd_base;
for (i = 0; i < (pinfo->rx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, dma_offset);
bdp->cbd_sc = BD_SC_EMPTY | BD_SC_INTRPT;
mem_addr += pinfo->rx_fifosize;
}
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, dma_offset);
bdp->cbd_sc = BD_SC_WRAP | BD_SC_EMPTY | BD_SC_INTRPT;
/* Set the physical address of the host memory
@@ -706,12 +698,12 @@
mem_addr = pinfo->mem_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos *
pinfo->rx_fifosize);
bdp = pinfo->tx_cur = pinfo->tx_bd_base;
for (i = 0; i < (pinfo->tx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, dma_offset);
bdp->cbd_sc = BD_SC_INTRPT;
mem_addr += pinfo->tx_fifosize;
}
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, dma_offset);
bdp->cbd_sc = BD_SC_WRAP | BD_SC_INTRPT;
}
@@ -1041,7 +1033,7 @@
* If the buffer address is in the CPM DPRAM, don't
* convert it.
*/
- cp = cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo->dma_offset);
*cp = *s;
@@ -1058,7 +1050,7 @@
while ((bdp->cbd_sc & BD_SC_READY) != 0)
;
- cp = cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp = cpm2cpu_addr(bdp->cbd_bufaddr,
pinfo->dma_offset);
*cp = 13;
bdp->cbd_datlen = 1;
==
cpm_uart_cpm2.c may need the same changes as cpm_uart_cpm1.c.
> These modifications further remove features that have been
> part of past kernels, and it has to stop.
Hmmm. What do you mean? The driver is broken, we want to fix it.
Greetings,
--
David Jander
Protonic Holland.
tel.: +31 (0) 229 212928
fax.: +31 (0) 229 210930
Factorij 36 / 1689 AL Zwaag
kernel 2.6.15: cpm_uart driver broken?
Hi Kenneth, On Tuesday 18 April 2006 21:19, Kenneth Poole wrote: > Regarding DMA allocation for CPM uarts, we had a similar issue with our > MPC857T and MPC885 boards. I think the real problem is that > bus_to_virt() and virt_to_bus() don't work on 8xx platforms for > addresses allocated using dma_alloc_coherent(). We had a previous > discussion Pantelis Antoniou and he agreed that the use of bus_to_virt() > and virt_to_bus() should be deprecated. This is also recommended in the > whitepaper series that discussed porting device drivers from 2.4 to 2.6. You are right! I hadn't noticed the (implicit) use of virt_to_bus() in cpm_uart_core.c. In the case that "((unsigned long)addr >= CPM_ADDR)", the address isn't translated, that's why the uart keeps sending lots of 0xff's instead of real data: There is empty flash at that adress (after 0xff10)! This also explains why the system hangs when I set CONFIG_CONSISTENT_START to 0xfd10, because then the CPM will access unadressed space. Vitaly: Is it true that your ADS boards both have IMMAP_ADDR < CONFIG_CONSISTENT_START ? That would explain why those do work. On the PQ2's dma_alloc_coherent(), behaves differently, so they might also work. In fact, bus_to_virt(), which is also used, does nothing more than adding KERNELBASE to the address, so a!=bus_to_virt(virt_to_bus(a)) if 'a' is obtained by anything other than kmalloc(). So if 'a' is obtained from dma_alloc_coherent(), will bus_to_virt(virt_to_bus(a)) at least yield a correctly mapped virtual address? I am asking, because line 263 of cpm_uart_core.c does exactly this, and it smells ;-) > What we did was use dma_alloc_coherent() in cpm_uart_cpm1.c, saving > dma_addr in the pinfo structure. The in cpm_uart_core.c, we use dma_addr > as the base address for the cbd_bufaddr values in each of the > descriptors. The software, when accessing the DMA buffers, uses mem_addr > as the base, applying the same offset computed previously for the dma > addresses. This technique is used in other drivers all over 2.6. Sounds like the correct thing to do, but do you (by any chance) have a patch for this change, to share? Thanks a lot to everyone for their comments and help. Greetings, -- David Jander
kernel 2.6.15: cpm_uart driver broken?
On Tuesday 18 April 2006 15:22, Vitaly Bordug wrote: >[..] > Well, existing code works just fine on 885ads and 866ads, that use SMC1 and > SMC2 as UARTs. Interesting. > > I'm pretty sure the following is wrong, but I can't seem to fix it > > either. This seems to apply for both PQ and PQ2 type uarts: > > from drivers/serial/cpm_uart/cpm_uart_cpm1.c (line 190): > > That's wrong - cpm_uart_cpm1.c applies to PQ only... I know. cpm_uart_cpm2.c contains the same code, so it should be as broken as the cpm_uart_cpm1.c. >[...] > Well, since it works on other boards, and kmalloc stuff seems to sorta work > as well, then I guess reason is screwed DMA thing for your board. > Check/alter CONFIG_CONSISTENT_* things and see if it will help. I did not touch de defaults. What are the rules to change them? What do I have to look out for? CONFIG_CONSISTENT_START = 0xff10 and I suspect a problem here if I was using MTD (currently disabled) since flash is at physical adress 0xfe00-0x on my board. Isn't MTD going to io_remap that area to that same virtual adress? How's that supposed to work then? I changed CONFIG_CONSISTENT_START to 0xfd10 and now the system freezes when I write to the serial port :-( > And, try to just replace dma_alloc_.. with kmalloc (not changing rx_buf > etc.) and reproduce the same behavior you had. BTW, rx_buf and tx_buf are > never used actually in the code, hereby there is no difference what values > they contain... Argh. Code looks obviously broken, but since it isn't used, it just works. That is not good! We should fix that either way then. Thanks, -- David Jander
kernel 2.6.15: cpm_uart driver broken?
Hi all,
Situation 1: MPC852T with SMC1 as uart/console, and SCC3/SCC4 as additional
uarts. SMC1 works fine, but SCC3/4 don't. On transmission attempt, both UARTS
transmit a byte 0x00 instead of what was intended to be transmitted.\
Situation 2: The same as above, but console on either SCC3 or SCC4. The uart
being initialized as console works ok, the other two don't.
I'm pretty sure the following is wrong, but I can't seem to fix it either.
This seems to apply for both PQ and PQ2 type uarts:
from drivers/serial/cpm_uart/cpm_uart_cpm1.c (line 190):
if (is_con) {
/* was hostalloc but changed cause it blows away the */
/* large tlb mapping when pinning the kernel area*/
mem_addr = (u8 *) cpm_dpram_addr(cpm_dpalloc(memsz, 8));
dma_addr = 0;
} else
mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
GFP_KERNEL);
pinfo->dp_addr = dp_offset;
pinfo->mem_addr = mem_addr;
pinfo->dma_addr = dma_addr;
pinfo->rx_buf = mem_addr;
AFAICS pinfo->rx_buf is the pointer to a buffer as seen from the CPM's point
of view, so it should hold a physical adress, not a virtual address. It seems
to me that it should be more like this (lines marked with ** are changed):
if (is_con) {
/* was hostalloc but changed cause it blows away the */
/* large tlb mapping when pinning the kernel area*/
mem_addr = (u8 *) cpm_dpram_addr(cpm_dpalloc(memsz, 8));
** dma_addr = mem_addr;
} else
mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
GFP_KERNEL);
pinfo->dp_addr = dp_offset;
pinfo->mem_addr = mem_addr;
pinfo->dma_addr = dma_addr;
** pinfo->rx_buf = dma_addr;
This does not work either, but I suspect this is a different problem, because
if I change dma_alloc_coherent() for something using kmalloc() and then
dma_addr=virt_to_phys(mem_addr), uarts begin to work, but trasmit mixed old
and new data from the buffers due to the cache getting in the way. At least
reception seems to work ok then.
So, why doesn't dma_alloc_coherent() work the way one would expect?
Obviously, changing "if (is_con)" into "if (1)" all three uarts work
correctly, but I guess we want to save on DP_RAM usage if ever possible.
What else is wrong here?
Greetings,
--
David Jander
Trouble with 2.6.16 on ppc8xx ?
Hi all, I just cg-update'd to the HEAD of the denx 2.6.x kernel tree (2.6.16 as released). Our board-support stuff was succesfully moved along from 2.6.14 (when everything but the SCC3 and SCC4 uarts worked just fine). I compiled a kernel without any special drivers, just console on ttyCPM0, but after "Uncompressing Kernel Image ... OK" there is no more output and no further activity on ethernet (it should boot from nfs-root) or any other device. After "cg-seek DENX-v2.6.15; make clean uImage", it works again (everything seems fine, system boots). Our board is based on a MPC852T and until now we used "MPC86X" as the BOARD_CHIP_NAME and it worked just fine with 2.6.14 and 2.6.15, but not with 2.6.16 as described above. When doing "cg-diff" and carfully examining it's output, I can only see our board-support stuff (not very much, not very special) and some custom drivers that are disabled anyway. Any clue about where to start looking? I didn't find any suspicious changes in arch/ppc/mm, arch/ppc/syslib and arch/ppc/kernel. Neither in drivers/serial/cpm_uart. Which change from 2.6.15 to 2.6.16 could have broken 8xx support for us? Is there perhaps a known issue with 2.6.16 and ppc8xx I am unaware of? Greetings, -- David Jander
Stable Linux kernel 2.6 for MPC8XX
On Tuesday 14 March 2006 15:01, Dan Malek wrote: > On Mar 14, 2006, at 2:50 AM, David Jander wrote: > > I don't know why, but while everyone still says 2.6 is slower, I am > > consistently getting results that seem to prove the opposite. Why? > > Because this is a compiler test and not an OS test. The > newer ELDK with 2.6 has better compilers. No. Please read the cited e-mail entirely before jumping to such a conclusion. I used the same ELDK for both kernels, and I didn't recompile the nbench binary ever again after the first time. The reasons are different, still unknown and apparently my fault. See my previous post responding to WG. Sorry to all for the confusion, looks like I must learn to be more careful when benchmarking. To keep the answer short: nbench performs exactly the same on both kernels, as one would expect, since nbench doesn't stress the kernel. I was looking at incorrect results, trying to blame the cache/tlb management... I was just wrong, sorry. Greetings, -- David Jander
Stable Linux kernel 2.6 for MPC8XX
On Tuesday 14 March 2006 09:34, you wrote: >[...] > > I don't know why, but while everyone still says 2.6 is slower, I am > > consistently getting results that seem to prove the opposite. Why? > > Is the TLB/cache stuff better optimized for 8xx in 2.6? > > IMHO it is quite a difference. > > Could you please provide more information on the kernel configuration > e.g. the .config files and the size of the kernel images? I didn't find the .config files anymore, so I repeated the tests. Now I have to offer my appologies, since the results show that both kernels perform the same :-( It is not that I forgot to turn on cache copyback, since that gives a different pattern (see attached results for 2.4.25). For the sake of completeness, here are the results and info for both tests. See also the attached .config files. For kernel 2.4 there are two results: with and wthout cache copyback, to see if that was the problem with the results in my first post. It wasn't. For kernel 2.6.14, there are also two results, one with low-latency and HZ=1000, the other without low-latency and HZ=100, to see how much CPU power faster scheduling takes quite noticeable it seems. Please compare ppc-kernel_2.6.14-prt.result with prtppc-2.4.25-nbench-copyback.result. These results look much more like one would expect: very similar, since nbench doesn't really stress the kernel. My appologies again, for the apparently incorrect benchmark resluts in my previous post. P.S.: There is only one config file attached for 2.6.14. The only difference is the latency setting and HZ as mentioned above. Greetings, -- David Jander -- next part -- # # Automatically generated by make menuconfig: don't edit # # CONFIG_UID16 is not set # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_HAVE_DEC_LOCK=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_ADVANCED_OPTIONS is not set # # Loadable module support # # CONFIG_MODULES is not set # # Platform support # CONFIG_PPC=y CONFIG_PPC32=y # CONFIG_6xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E500 is not set # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set CONFIG_8xx=y # CONFIG_PPC_STD_MMU is not set CONFIG_SERIAL_CONSOLE=y CONFIG_NOT_COHERENT_CACHE=y # CONFIG_ADDER_II is not set # CONFIG_AMX860 is not set # CONFIG_BSEIP is not set # CONFIG_CCM is not set # CONFIG_DBOX2 is not set # CONFIG_DAB4K is not set # CONFIG_FADS is not set # CONFIG_FPS850L is not set # CONFIG_FPS860L is not set # CONFIG_HERMES_PRO is not set # CONFIG_IP860 is not set # CONFIG_IVML24 is not set # CONFIG_IVMS8 is not set # CONFIG_KUP4K is not set # CONFIG_KUP4X is not set # CONFIG_LANTEC is not set # CONFIG_LWMON is not set # CONFIG_MBX is not set # CONFIG_NSCU is not set # CONFIG_NC650 is not set # CONFIG_PCU_E is not set # CONFIG_QUANTUM is not set # CONFIG_RBC823 is not set # CONFIG_RMU is not set # CONFIG_RPXCLASSIC is not set # CONFIG_RPXLITE is not set # CONFIG_SM850 is not set # CONFIG_SPD823TS is not set # CONFIG_TQM823L is not set # CONFIG_TQM823M is not set # CONFIG_TQM850L is not set # CONFIG_TQM850M is not set # CONFIG_TQM855L is not set # CONFIG_TQM855M is not set # CONFIG_TQM860M is not set # CONFIG_TQM862M is not set # CONFIG_TQM860L is not set CONFIG_PRTPPC=y # CONFIG_UC100 is not set # CONFIG_VIPER860 is not set # CONFIG_WINCEPT is not set # CONFIG_PRT_8UARTS is not set CONFIG_PRT_IOADDR=0xf810 CONFIG_PRT_IOSIZE=0x0003 CONFIG_PRT_UARTADDR=0xf810 # CONFIG_DUMMY_KEYB is not set # CONFIG_ALL_PPC is not set # CONFIG_SMP is not set # CONFIG_MATH_EMULATION is not set CONFIG_EMBEDDEDBOOT=y # # General setup # # CONFIG_BIGPHYS_AREA is not set CONFIG_HIGHMEM=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 CONFIG_TASK_SIZE=0x8000 # CONFIG_ISA is not set # CONFIG_EISA is not set # CONFIG_SBUS is not set # CONFIG_MCA is not set # CONFIG_PCI_QSPAN is not set # CONFIG_PCI is not set CONFIG_NET=y CONFIG_SYSCTL=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_KERNEL_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_OOM_KILLER is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set # # Parallel port support # # CONFIG_PARPORT is not set # CONFIG_GEN_RTC is not set CONFIG_PPC_RTC=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="ip=on" # # Embedded options # # CONFIG_EMBEDDED is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_CISS_MONITOR_THREAD is not set # CONFIG_BLK_DEV_DAC960 is no
Stable Linux kernel 2.6 for MPC8XX
On Friday 10 March 2006 16:33, Wolfgang Denk wrote: > > I believe most of those observations and measurements are not valid > > anymore. Kernel 2.6 for 8xx has come a long way since this article was > > written. It might have been true back then, but it surely isn't anymore. > > So did you actually run any benchmarks? Specilations on what might be > or should be are not really helpful. Of course I did. Otherwise I wouldn't say this. Here's some benchmark data from nbench (sorry didn't try lmbench yet): The same ELDK (version 3.1.1) for both kernels, running on exactly the same board (MPC852T 100MHz, with 32Mbyte SDRAM and 32Mbyte Flash running from NFS root). I removed some FPU benchmarks, as they are pretty meaningless for this board and take an ethernity otherwise. Results for Kernel 2.4.25 (Denx CVS from around sept-oct or so, 2005): TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT: 30.438 : 0.78 : 0.26 STRING SORT : 1.5842 : 0.71 : 0.11 BITFIELD: 7.9506e+06 : 1.36 : 0.28 FP EMULATION: 3.258 : 1.56 : 0.36 IDEA: 108.89 : 1.67 : 0.49 HUFFMAN : 26.281 : 0.73 : 0.23 LU DECOMPOSITION: 0.32765 : 0.02 : 0.01 ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 1.052 FLOATING-POINT INDEX: 0.257 Now the results for 2.6.14 (Denx git released 2.6.14): TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT: 32.654 : 0.84 : 0.28 STRING SORT : 1.7408 : 0.78 : 0.12 BITFIELD: 8.3466e+06 : 1.43 : 0.30 FP EMULATION: 3.506 : 1.68 : 0.39 IDEA: 115.3 : 1.76 : 0.52 HUFFMAN : 27.855 : 0.77 : 0.25 LU DECOMPOSITION: 0.35932 : 0.02 : 0.01 ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 1.115 FLOATING-POINT INDEX: 0.265 I don't know why, but while everyone still says 2.6 is slower, I am consistently getting results that seem to prove the opposite. Why? Is the TLB/cache stuff better optimized for 8xx in 2.6? IMHO it is quite a difference. Btw, I also wrote different small "speed-measurement" tools (to measure loop-speed, memory throughput for different block sizes, etc...) and they all show aproximately the same increase. I was careful to strip both kernels of all unnecessary drivers and features that could hamper performance. If you wish I could try to dig up the .config files for you, but I am not sure I'll find them anymore (I did this when 2.6.14 was just released). Greetings, -- David Jander Protonic Holland.
Stable Linux kernel 2.6 for MPC8XX
On Wednesday 08 March 2006 15:29, Fillod Stephane wrote: > >I would want to use a linux kernel 2.6 on a custom MPC8xx board. > >Which stable kernel release must or can I use ? > > http://www.denx.de/wiki/bin/view/Know/Linux24vs26 I believe most of those observations and measurements are not valid anymore. Kernel 2.6 for 8xx has come a long way since this article was written. It might have been true back then, but it surely isn't anymore. Kernel 2.6 is bigger than 2.4, that's a fact, but application performance is actually slightly higher with 2.6.14 than it is with 2.4.25. The overall robustness and "niceness" of the code is also a totally different story now. 2.6 software architecture is definitely better, and many drivers are much more stable. Implementing board support and drivers in 2.6 is also much easier and cleaner than in 2.4. Greetings, -- David Jander Protonic Holland.
How to quickly write cleanmarkers to jffs2 partitions?
On Monday 06 March 2006 13:21, Jaap-Jan Boor wrote: > On Fri, 2006-03-03 at 10:08 +0100, Mathieu Deschamps wrote: > > Hi, > > > > "When preparing a flash partition for JFFS2, it is recommended to put > > cleanmarkers to the erased blocks. > > This might be done my means of "-j" option of the "flash_eraseall" MTD > > utility. Otherwise, JFFS2 will re-erase the blocks > > which contain all 0xFF and have no cleanmarker. This is an unneeded > > wasting of time." > > > > Source : http://www.linux-mtd.infradead.org/faq/jffs2.html > > > > does this may be relevant ? > > This is correct, however flash_eraseall does also (as it's > name suggests, erase all flash blocks, which takes > some time on NOR flash. If you 'know' the flash is erased, > it's not needed. > I used flash_eraseall to write the cleanmarkers, but without > erasing blocks (and called that utility cleanmark) Thanks to all for the suggestions. Is "cleanmark" an open-source tool? Would you share it? Greetings, -- David Jander
How to quickly write cleanmarkers to jffs2 partitions?
Hi, I was wondering if there is a trick or common technique I am ignoring to make this more efficient: This is for a 2.4 kernel based system. In production we use either u-boot or a NFS mounted linux system to erase flash and write jffs2 partitions to it. The jffs2 images are small (not padded to full partition size to save programming time), but the partitions are rather big (12 Mbyte in one case). Problem is that when booting for the first time, one has to wait several minutes (during which the system is more or less useless and busy) to get all cleanmarkers written to flash by the jffs2 gc thread. This huge delay is rather unacceptable for production, so we are looking for a work-around. One option would be to make jffs2 images that are padded to full partition size, but that also isn't very efficient, considering the image is only about 100k in beginning and the partition is 12 Mbyte in size. That would take a lot of time programming flash (less time than having the jffs2 driver fix this nevertheless). Another option is making a little program that writes cleanmarkers in every eraseblock starting from the first completely empty one in a partition before mounting that partition for the very first time after flashing. Since this seems to me like a common situation, I'd like to know if anybody knows about a better solution, or if anybody has already dealt with this before. Greetings, -- David Jander Protonic Holland. tel.: +31 (0) 229 212928 fax.: +31 (0) 229 210930 Factorij 36 / 1689 AL Zwaag
How to check which CPU we are using? PPC?
On Wednesday 08 February 2006 14:04, jeanwelly wrote: > Hi, > Acutally I am asking "Are there any command that os or BSP provided in > shell to print the CPU information?". Thanks a lot! One guess: cat /proc/cpuinfo Will that be it? Geetings, -- David Jander
Qt, forks and threads = segmentation faults?
Hi Russell, On Saturday 28 January 2006 01:30, Russell McGuire wrote: > This is a more general question, and if anyone knows of a more specialized > list this should be posted to, I'd be happy to do so... > > Small picture of hardware: > DENX Linux 2.4.25 / PowerPC MPC8280 / 32 MBs of RAM > > I am using QT Embedded for a small GUI that does BSD sockets, also using > DENX's SM501 video driver. Everything is quite stable, recently I added a > additional process to the application using fork() for the listening > 'accept' call for the sockets. > > After many tests I decided that due to the nature of the fork() command and > the GUI half of the program, that this was a large waste of memory, as I > was duplicating the entire GUI system. So I started looking alternatives, > and have landed at the 'pthread' library. It shouldn't be a waste of memory, since Linux uses copy-on-write for memory pages. That means, although it looks like your child process wates a lot of memory (same initial VSS size as parent), it actually shares its memory with the parent until the child starts modifying memory contents (write fault occurs). At that moment the page being written to is copied, and the write access succeeds on the copied page. So fork() is nowadays quite efficient in linux systems. exactly as efficient as creating a thread. > However, now I have lots of segmentation faults, particularly when I send a > message using QT's postEvent commands back to the main thread. Eeek. You might want to compile QT with thread support compiled in (don't know if that helps though). Anyway, it is probably a better idea to stick with fork() (see above). > I was curious if anyone had any better idea of a more stable or perhaps a > suggestion on why I am able to only get about 30 seconds of run time out of > the app using pthread, verses fork() seems to be much stabler. Use fork(). Greetings, -- David Jander
u-boot debugging
On Saturday 21 January 2006 07:34, Atul Sabharwal wrote: > You have a conflict of interest as you are just pissed with Metrowerks > as they are your competitors. Open source is about free speech and > not for people with vested interests. You seem to be one of the guys > with vested interest. Everybody has their interests. Even OSS programmers have interests, if not always of economical nature. I don't think Mr. Denk has any more reasons to "be pissed" with Metrowerks than you might have reasons to "be pissed" with DENX or Abatron. > You cannot repress people and tell them *oxymorons* or ninkampoops... > If you do the cost benefit analysis between BDI and Metrowerks debugger, > its the same. And their UI is better than ddd and works with a BDI also. > So, if you consider all aspects, its a better product. That is a very subjective observation. Here is a slightly more objective one for you: BDI can use almost any UI that supports gdb, and there are quite a lot. Not only DDD. Does Metrowerks offer you that amount of choice? > And opensource is used all over the globe including the Asian subcontinent. > And there are still sites which use hubs as people dont have the excess > money > to throw away on legacy products. Just sitting in your small cube does not > give > insight to global technology trends... Well, I suppose using a 10Mbps switch shouldn't cost much more than a 100Mbps hub, and you almost said it yourself, that it would be more efficient in a crowded network ;-) What I really wonder is what the choice between a switch and a hub has to do with "global technology trends". I detect an increasing amount of resentment in your words, and that is not good as far as my experience goes. Greetings, -- David Jander
VFS: Cannot open root device "31:03" or unknown-block(31,3)
On Friday 06 January 2006 16:08, Wolfgang Denk wrote: > This is a serious misunderstanding. There is no such thing like a > specific kernel version which is supported by the ELDK. True, but not entirely. ELDK-3.1.1 has a glibc compiled with support of a certain version of the kernel (I guess it's 2.4.xx), so newer kernels might run (because they are obviously backwards compatible), but some features of 2.6 cannot be used (e.g. support for the latest syscalls, different HZ, etc...) A second issue is the boot procedure. If you are a beginner with linux, you'd probably start booting from NFS root as it gets installed in the ELDK/ppc_xxx directory. That probably won't work very well with latest 2.6 kernels (device files missing, sysfs not mounted, shmfs has different name, etc...) A third issue is the compiler issue. Some newer kernels might not compile correctly anymore with older compilers. These three things are what I meant with "supported" or "not supported". > The ELDK is primarily a *toolkit* which works with arbitrary C and > C++ programs and with any version of the kernel tree (at least in > theory; very recent version s of the Linux kernel [ > 2.6.14] cannot > be compiled with ELDK 3.1.x any more, but this is a different issue). See what I mean? HappyPhot did just that: compile 2.6.14.2 with ELDK 3.1.1!!! > > > Do you know where to get the infomation about which kernel version it > > > supports? > > The ELDK supports *any* kernel version. Ok, let's talk about "recommended" kernel then. I would never recommend someone unexperienced to start with a combination of ELDK-3.1.1 and kernel 2.6.xx. > > The one that comes with that version of ELDK? Just a guess ;-) > > Wrong guess. But it'd still be the one with most chances of success unless there are known problems with that kernel on a Sandpoint board. Greetings, -- David Jander Protonic Holland.
VFS: Cannot open root device "31:03" or unknown-block(31,3)
On Friday 06 January 2006 15:09, HappyPhot wrote: > > I see you are using DENX ELDK 3.1.1 and a kernel which AFAIK is not > > supported > > by this version of ELDK. Are you sure this is supposed to work? It > > probably > > will, but I don't know what the "Sandpoint" is (it looks like a PowerPC > > processor of the MPC7xx series to me), so I couldn't tell. > > Do you know where to get the infomation about which kernel version it > supports? The one that comes with that version of ELDK? Just a guess ;-) Greetings, -- David Jander
powerpc vs ppc build
On Wednesday 04 January 2006 23:44, Jeff Angielski wrote: > Is there a summary of the differences between the ppc and powerpc builds > for the 2.6 kernels? Or something describing what the community, in > general, is trying to fix/address with the different schemes - besides > the merging of ppc and ppc64? Looks to me like ppc and ppc64 are deprecated and "phased out" in favour of powerpc. If you look at the contents of both the include/asm-ppc and include/asm-powerpc directories over the last revisions for example, you'll see files moving from asm-ppc to asm-powerpc. Now, they are in a kind of flux still, so you'll probably find yourself doing silly things like "ln -s include/asm-powerpc/* include/asm-ppc/" to keep things working and compiling nicely. I do hope this is over soon. Greetings, -- David Jander
VFS: Cannot open root device "31:03" or unknown-block(31,3)
On Thursday 05 January 2006 04:29, you wrote: > Hi, David, > I get the complete bootlog and .config here. Please see the > attached files. I copy the bootlog into .config. > And my NFS can mount root file system ok, but can not > execute any program. Once the program load into system and > run, the system crash. > I am new in this field and thank you for your help. > Regards, > /HappyPhot in your .config: > CONFIG_JFFS2_FS=m This is wrong. You have to choose "y", not "m" (for module). This way jffs2 is compiled as a module. That means, that jffs2 filesystem will not be available until the module is loaded with "insmod jffs2" of something similar. That in turn means that your system has to start up first in order to be able to do this, but since you can't start because your root filesystem is on jffs2, you have created yourself a "chicken and egg" problem. If you choose "y" then jffs2 support will be compiled into the kernel, and thus be available before booting. In your bootlog: > Linux version 2.6.14.2 (happy at sddlinux1) (gcc version 3.3.3 (DENX ELDK > 3.1.1 > 3.3.3-10)) #29 Sun Jan 1 22:34:28 CST 2006 > Motorola SPS Sandpoint Test Platform I see you are using DENX ELDK 3.1.1 and a kernel which AFAIK is not supported by this version of ELDK. Are you sure this is supposed to work? It probably will, but I don't know what the "Sandpoint" is (it looks like a PowerPC processor of the MPC7xx series to me), so I couldn't tell. Greetings, -- David Jander
VFS: Cannot open root device "31:03" or unknown-block(31,3)
On Monday 02 January 2006 15:48, HappyPhot wrote: > Hi, > I've suffered for many days and "google" almost every where. > I would like to boot from the flash with jffs2 (i.e. using jffs2 as my > root /) . But it alyaws shows: > VFS: Cannot open root device. (whole message is as below) > > Anybody knows what may cause this ? Please help and > thank you. >[...] You omitted the interesting part of the log output, the bootarguments at the very beginning. What is the value of root= ? Maybe you made the typical mistake of specifying /dev/mtd3 instead of /dev/mtdblock3, or you didn't compile in support for mtd access as a block device? Greetings, -- David Jander
Which CAN driver to port to for PPC
On Thursday 29 December 2005 13:17, Wolfgang Grandegger wrote: > > That's great. I've always been convinced it is the right way to go. > > I remember I've said so to a friend in March 2002. Unfortunately, > > I had no time to do it the right way, due to short deadlines and > > tight budget. I'm happy Robert did it. > > FYI, there is also a RTDM/Xenomai based version of the SJA1000 > socket-based CAN driver at > http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddon/ > As RTDM/Xenomai is avaiable for PowerPC as well, it might be an option. This is great! I have been trying out xenomai with 2.6.14 on our MPC8xx hardware, and it looks impressive. Still wonder why xenomai hasn't gotten the publicity it deserves. Somehow I had overlooked the example RTDM CAN driver, though. I also see Robert Schwebel as a member of OSADL, so I am eagerly waiting for a news-update on that site also (www.osadl.org). This could indeed get very interesting, I can't wait to see how Roberts implementation looks like. Thanks to all for the discussion and work on this matter, -- David Jander Protonic Holland.
Which CAN driver to port to for PPC
Hi again, On Wednesday 28 December 2005 14:19, Alessandro Rubini wrote: > > The problem I see with Ocan is that it has a very different API than all > > the others. > > I know. When I started the project there only was one driver, and > it was already very complex. But it lacked the select method(now > poll), and had other serious design problems. So I started mine, > without advertising it. Most of the time, that is the reason. There is something, but it's broken, and to fix it is much more work that re-doing it. Problem is: some people are already using it, and code is beeing grown on top of it. It seems a standard open-source dilemma. > Now I have a few happy users, and they want to keep my API in their > applications, so I'm stuck with it. Tough indeed. But according to Newton's laws, if we apply some force to it, pointing in the right direction, eventually it'll move there, no matter how big the object is. Let's try and find out where that direction is ;-) > Yes, that is how things should be, in an ideal world. Sorry for trying to be a bit of an idealist ;-) > It would. Anyone willing to lead this effort? [no offence or humor > intended, I am interested in following it, but can't lead it myself] I have too little time and too little experience to do such a thing, but I'd happily contribute and follow. Regards, -- David Jander Protonic Holland.
Which CAN driver to port to for PPC
Hi again, On Wednesday 28 December 2005 11:44, Wolfgang Grandegger wrote: > AFAIK, there is no _generic_ embedded CAN driver available which even > supports real-time extensions. Yes, lincan does. Well, it supports RTlinux and OCERA's RTlinux (GPL) modifications, which somehow reinvent ADEOS (or is it the other way around?), but since RTlinux is an option only for i386, and anyway almost dead right now, you could say it doesn't support real-time extensions. The problem of saying "Peak-CAN for SJA1000" and "OCAN for intel" is that you can basically forget about writing portable code because they are both very different. Maybe you should have a look at Pavel Pisa's lincan. After trying it out you might end up as confused as I am, because it doesn't look that bad at all, it's almost platform independent, supports all kernels (2.2 to latest 2.6), and supports a great amount of cards with intel and/or philips chips (yes, both of them on one card is also an option). The driver is designed with performance and throughput in mind, but I am not so sure about the API which is still a little too simple (maybe that's actually good) and doesn't support properly checking chip- or bus-status yet. Also honorable is their effort of staying compatible with at least one other player: can4linux. Greetings, and thanks for the comments, Btw, how's ELDK-4 coming along? -- David Jander Protonic Holland.
Which CAN driver to port to for PPC
Hi all, On Tuesday 27 December 2005 22:49, Alessandro Rubini wrote: > I need to port ocan to support SJA1000 on an ARM device, as a client > asked for it. Also, another client asked for a 2.6 port, so all of > this will happen pretty soon (2-3 weeks). I don't know if that makes > any difference. That could of course make a difference eventually. The problem I see with Ocan is that it has a very different API than all the others. I know of at least two others, which try to be compatible (or at least easily portable between) with each other: lincan and can4linux. I am not sure but I think they started from the same base, and somehow agreed to stay API-compatible. Ocan's API on the other hand, seems to be tailored around the intel controller, and doing little more than offering a user-space interface to the chip, much in the same way as one is used to programming small microcontrollers with integrated CAN periferals. I wonder how the port to SJA1000 will turn out, since I believe it would have to emulate some 82527-specific stuff, in order to offer a compatible API. The advantage OCan might have, is probably better control of timing, since AFAIK, one can avoid using queues, which give additional delays if the queue is not empty; somehting often not wanted in real-time applications. Also one difficulty in designing a good CAN driver model, is the fact that CAN offers up to the link-layer in hardware, and the rest is application specific, so it is hard to do much in the driver without hampering some possible application. I am convinced though, that there should be a chip/card-independent API to the application-programmer, and that effort should be done to converge into the same direction. Programmers now really have a tough time choosing, and that is as bad as having no choice at all IMHO. So, wouldn't it be better to try to unite forces and at least offer similar API's, or even better, develop a standard linux CAN framework? I guess there is little chance something like this will ever become part of the kernel, but right now the situation is really awful. CAN is quite popular for embedded systems, but even embedded systems developers like to write portable code. Regards, P.S.: Alessandro: I have copy of "LDD1" on my desk, and I like it a lot. Thanks! -- David Jander Protonic Holland.
Which CAN driver to port to for PPC
Hi, We have developed CAN hardware based on the Philips SJA1000 controller hooked to a MPC8xx based processor board. Now we want to write driver support for it. My first try was lincan-0.3.1, which seemed quite well written at first glance. Porting was easy too, and the driver works fine on our board with the latest kernel (2.6.14). But this driver lacks a proper way of checking the status of the CAN controller from userspace :-( Not that nice after all! Then I see on the DENX website, mention of Rubini's OCAN (mostly useless to us), and Peak's PCAN drivers (there is a port for MPC5200 on DENX's site). No word about lincan, though. The reason I suppose is, someone already figured out that lincan is not a good choice for whatever reason (status reportability ??), right? Before beginning to re-invent wheels and re-discover known problems in certain CAN driver architectures, could someone please point me to the right place to start looking for answers (if that place exists) or just give the answer, opinion or experience with one of PeakCAN, lincan, can4linux, etc...? I am again puzzeled about which way to go. Thanks for any advice, -- David Jander Protonic Holland.
POSIX High Resolution Timers in LinuxPPC 2.4
Hi Tim, On Friday 16 December 2005 23:34, Martin, Tim wrote: > Could someone give me a brief history lesson on POSIX high resolution > timers (e.g. timer_create() function) implemented in the Linux kernel on > the PowerPC 405 architecture? Specifically: > > Confirm they are in the mainline 2.6 kernel now (e.g. kernel.org)? > > Were they ever a part of the "mainline" 2.4 linuxppc kernel (e.g > ppc.bkbits.net)? > > If no, were they ever available as a patch? The stuff at > sourceforge.net/projects/high-res-timers stops at 2.4.20 and looks like it > was only ever working for i386, not ppc. I asked a related question a while back, and got no answer (yet). I did find this though, which you might have overlooked: http://prdownloads.sourceforge.net/high-res-timers/ppc-hrt-2.6.10.patch?download I am equally puzzled about whether this has made it into mainstream, is about to, or never will. I don't even know if it actually works. Greetings, -- David Jander Protonic Holland.
HR posix timers on mpc8xx??
Hi all, With 2.6 now relatively stable running on mpc8xx, I was wondering if someone has tried to patch in support for High-resolution Posix-timers, as from here: http://sourceforge.net/projects/high-res-timers It sounds really attractive, and I wonder why this still isn't officially part of 2.6? There is a patch for 2.6.10 for ppc, but I wonder if someone managed to port it to 2.6.14 (or later) and runs it on an mpc8xx. Greetings, -- David Jander
Which way to store log in flash on mpc8xx?
Hi, On Tuesday 29 November 2005 02:06, David Ho wrote: > Hi, just catching up on this problem as I have another unit that > showed the same symptom. > My system looks like this > > MPC852T > 128Mbytes SDRAM > 64Mbytes Flash > > Flash partitions > 2*1.25Mbytes partitions for Kernel > 61.5Mbytes for rootfs and applications. > Remaining 1Mbyte for U-boot, u-boot env and spare. > > I get that same problem as well. kernel BUG at gc.c: 139 > > I have compiled Perl, Openssl, Openssh, etc running NFS so SDRAM is > definitely not the issue. I have done almost the same (compiling Perl didn't succeed because of an out-of memory condition), and never had any other reason to suspect hardware problems. After getting some advice from peoble at mtd-list, I switched to 2.6.14 for our new developments, and jffs2 seems a lot more stable now. I can only recommend you to consider switching. Besides consuming a little more RAM and Flash, 2.6.14 is miles ahead in terms of almost anything else, plus it's a bit faster on 8xx than 2.4.25!! I have to warn you though, that it still seems not to be as rock-solid as one might want for an embedded system: We have a stress test running for a few weeks now simulating power-failures during writes to files on jffs2, and mtd has some occasional hick-ups. Those hick-ups seem to be far less serious than gc.c crashing, but we will have to take them into account in our application. This is the situation: Sometimes the test application crashes giving a write-error on the mtd device, preceded by an error message from the mtd-driver (and jffs2, but the problem seems to come from mtd). The error message is like "MTD do_write_buffer(): software timeout", which normally means a flash programming error, most probably due to sector beeing worn out, but I don't think that is the case, since those problems began appearing quite early and went away all by them selves. Flash doesn't magically "fix" itself over time, does it? Maybe it's a problem in the AMD flash driver (our device is a Spansion Mirror-bit S29GL256M11) > David: have you gotten any new insights since? Yes, see above. Please keep me informed if you get to know something more about the problem ;-) If you want more detail about what tests we are doing, and the problems we had so far, feel free to ask, or read my posts to the MTD list. Right now its 46268 power-cycles and counting. Greetings, -- David Jander Protonic Holland.
USB Keyboard Support
On Thursday 24 November 2005 10:31, Igor Luri wrote: > the first console argument defines where is stdout and the second > console argument defines where is the stdout and stdin. With this > configuration you can duplicate stdout, you can see the output on two > devices, screen and serial line. Wow. Everyday we learn something new ;-) Sorry, and thanks for the tip! Greetings, -- David Jander
USB Keyboard Support
> root=/dev/nfs rw ip=on console=tty console=ttyS0 init=/sbin/init I suppose putting two "console=" statements on the commandline doesn't do much more than just removing the first one. Greetings, -- David Jander
Strange results with changing HZ
On Monday 21 November 2005 08:44, Wojciech Kromer wrote: > My system is: > - 2.4.25 kernel from denx.de > - uclibc (gcc 3.4.2) + busybox > - changed HZ to 1000 > - rebuild kernel only > > AFAIR there souldn't be any need to recompile user apps. Just an uneducated guess, but are you sure uclibc doesn't depend on HZ at all? Some things might be just straight syscalls, others might be implemented in userspace (inside uclibc)... for example alarm(1) programming an alarm on jiffies+1/HZ, and HZ being compiled in from kernel headers ? I may just be talking rubbish though. Greetings, -- David Jander
[PATCH 2.6.14] mm: 8xx MM fix for
On Thursday 10 November 2005 08:48, David Jander wrote: >[...] > Hmmm. This is a lot in the line of the tests I did with (the more generic > benchmark) nbench. After looking at those results (see my other post in > this thread) I already suspected something like this. Sorry, I obviously did not mean this thread, but the following post on another thread: http://ozlabs.org/pipermail/linuxppc-embedded/2005-November/020775.html Regards, -- David Jander
[PATCH] 2.6: PRTPPC board-support was: Re: about MPC 8XX SPI Driver
On Thursday 10 November 2005 07:50, EMAIL wrote: > Anybody know where can found 'CPM SPI Driver' for MPC852T.I found a > cpm_spi.c at /arch/ppc/8260_io directory in Linux 2.4.25.But I don't > know how to program application to > handle this driver. Do you want it for 2.4 or 2.6? (I have both running on a mpc852T). Here's a patch for 2.6.14 (denx-git tree). Sorry to send you the complete patch for prtppc board support, but the spi driver makes up most part of it, so it wouldn't be much smaller anyway ;-) Regards, -- David Jander Protonic Holland. -- next part -- A non-text attachment was scrubbed... Name: linux-2.6.14-20051107-prt.patch Type: text/x-diff Size: 33276 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051110/40832fa7/attachment.patch
[PATCH 2.6.14] mm: 8xx MM fix for
On Wednesday 09 November 2005 13:04, Marcelo Tosatti wrote:
>[...]
>
> ** 2.6.14 DataTLBHandler jump direct ("two exceptions"):
>
> first batch:
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> second batch:
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> ** 2.6.14 vanilla ("three exceptions"):
>
> first batch:
> avg: 288ms
> avg: 285ms
> avg: 287ms
> avg: 287ms
> avg: 288ms
>
> second batch:
> avg: 288ms
> avg: 288ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> ** 2.4.17 (root on RAMDISK):
>
> avg: 309ms
> avg: 313ms
> avg: 312ms
> avg: 311ms
> avg: 310ms
Hmmm. This is a lot in the line of the tests I did with (the more generic
benchmark) nbench. After looking at those results (see my other post in this
thread) I already suspected something like this.
> The v2.6.14's kernel jump-direct is more consistent at 287ms,
> while vanilla 2.6.14 oscillates between 285 and 288ms, but
> no significant difference between the two.
>
> v2.6's fault handling is clearly faster than 2.4's (note that the compiler
> is also different, 2.4 uses gcc 2.95 and 2.6 gcc 3.3).
I don't think the compiler does much difference here though. In my test the
exact same compiler was used for both kernels, and the same rootfs and binary
of nbench. gcc-3.3.3. I did also use oprofile to get an idea of where the
code spent its most cpu time during nbench, and AFAIR flush_dcache_icache()
took quite a chunk of it, so I assume page fault latency is of importance
there too, and might account for the huge difference between 2.4 and 2.6.
Greetings,
--
David Jander
fix swapping on 8xx?
>> I think Dan might be in the camp that says a properly designed embedded >> system won't need to swap. > > I'm actually in the camp that knows the majority of systems > running Linux aren't workstations and don't have disk drives. > It would be nice to have selectable features for such applications. Well, me too, but there are people out there trying to do strange stuff. I remember myself even once trying to get swapping to work over nfs, because I wanted to compile perl5 natively (overnight of course), since cross-compiling perl is quite a bit of pain. Perl intends to "include-together" enormous source files, that exhausted the whole 64Mbyte RAM on my embedded board ;-) Needless to say, swap over nfs did never work reliably enough to even start compiling. >>> It sounds tempting indeed, but should you really notice a performance >>> increase out of this? > > Yes. Most importantly it adds some predictability which is quite > measurable on this class of processor. It was a coding mistake way back > in 2.2 that actually exposed this. I was taking some liberties by > updating more status in the PTE than I should have, and Paulus > made me fix it in 2.4 :-) It basically eliminates TLB faults associated > with system status tracking, since we aren't paging there isn't any need > to track page aging and such. If you are paging, it still > functions properly, you may just not pick the most suitable pages to > steal. FYI, I have some benchmark results of yesterday's git of kernel-2.6 (with _tlbie(address); just moved out of the two innermost if()'s in the function update_mmu_cache()) compared to kernel 2.4.25 from denx, made with "nbench". The results are quite interesting, and contradicting (older) benchmark results, Wolfgang made a few months back: kernel-2.6.14-git-20051107: --- TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT: 32.654 : 0.84 : 0.28 STRING SORT : 1.7408 : 0.78 : 0.12 BITFIELD: 8.3466e+06 : 1.43 : 0.30 FP EMULATION: 3.506 : 1.68 : 0.39 IDEA: 115.3 : 1.76 : 0.52 HUFFMAN : 27.855 : 0.77 : 0.25 LU DECOMPOSITION: 0.35932 : 0.02 : 0.01 kernel-2.4.25-devel-denx: - TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT: 30.438 : 0.78 : 0.26 STRING SORT : 1.5842 : 0.71 : 0.11 BITFIELD: 7.9506e+06 : 1.36 : 0.28 FP EMULATION: 3.258 : 1.56 : 0.36 IDEA: 108.89 : 1.67 : 0.49 HUFFMAN : 26.281 : 0.73 : 0.23 LU DECOMPOSITION: 0.32765 : 0.02 : 0.01 This is all on the same hardware: MPC852T + 32Mbyte SDRAM running from NFS. kernel 2.6 is faster all the way through!! The results so far are pretty encouraging I'd say. Maybe something like lmbench would help to shed more light on details important for kernel testing, like context-switch overhead, mm, etc... Nbench is quite useless here (a single task doing all sorts of nonsense, almost no critical syscalls), but that's what makes the enormous differences even more remarkable IMO. Maybe something is broken in 2.4? Greetings, -- David Jander
fix swapping on 8xx?
On Tuesday 08 November 2005 01:55, Dan Malek wrote: > On Nov 7, 2005, at 10:10 AM, Marcelo Tosatti wrote: > > The following is an attempt to fix swapping on 8xx by not touching > > _PAGE_ACCESSED bit if the page is not present. > > Ugh I suppose. I hate assembler code macros ... > Somehow, "swapping" and "8xx" just don't belong together. Well, at least it sounds ugly together, but it is also at least conceiveable. There seem to be people who use PCMCIA for an IDE interface, so swapping may become desireable in some cases. > I'm tempted to add a configuration option that is the complete > opposite of this and assumes are really embedded system. > Mark pages as always accessed, data pages as always dirty, > and you can eliminate lots of TLB faults in systems that are > fairly static. It sounds tempting indeed, but should you really notice a performance increase out of this? Greetings, -- David Jander
[PATCH 2.6.14] mm: 8xx MM fix for
On Monday 07 November 2005 09:44, Marcelo Tosatti wrote: > Seems the bug is exposed by the change which avoids flushing the > TLB when not necessary (in case the pte has not changed), introduced > recently: >[...] Brilliant! I just checked, and now it boots again. Btw, it did boot before this patch, but taking about 2 or 3 hours to get halfway through the init scripts ;-) Thanks for the good work! -- David Jander
problems on isp1362 driver
On Friday 15 July 2005 02:14, David Zhang wrote: >[...] > We are using Philips ISP1362 USB controller on WinCE 4.2. It seems that we > are encountering "ATL interrupt" missing problem. I am wondering if any of > you ever had the similar problem. Where does this driver come from? Does it have anything to do with linux kernel versions of that driver? If so, which one, 2.4 or 2.6? I don't know WinCE, much less how drivers work in WinCE. Please specify what's the relationship (or expected relationship) with linux. In any case, you'd have to tell more details about the problem you're experiencing, otherwise it's unlikely someone here can help you. I am using the isp116x HCD driver from kernel 2.6 now with a isp1160 chip, and it runs fine. I suppose you are talking about the Host part of the 1362? Greetings, -- David Jander
[PATCH] ppc32: Put CPM1 config option
On Thursday 03 November 2005 19:39, Pantelis Antoniou wrote: >[...] > +config CPM1 > + bool > + depends on 8xx > + default y > + help > + The CPM1 (Communications Processor Module) is a coprocessor on > + embedded CPUs made by Motorola. Selecting this option means that > + you wish to build a kernel for a machine with a CPM1 coprocessor > + on it (8xx, 827x, 8560). Not that the help of a hidden bool is of much importance, but what have the mpc827x and mpc8560 to do with a CPM1? Those are PQ2 processors AFAIK. Why does this option have a help anyway? Greetings, -- David Jander
Kernel 2.6 on MPC8xx performance trouble...
On Monday 31 October 2005 14:08, David Jander wrote: > On Monday 31 October 2005 13:58, Mark Chambers wrote: > >[...] > > > > > No, sir, no cache detected ! > > > > > > Where do I have to look now? > > > > Could the cache be in writethrough mode? (Instead of writeback) > > Good point. I just checked the same test, but reading instead of writing. > Same result, no cache detected. > > I know how to change cache policy in u-boot, but does the kernel change > that? If so, where? Sorry for the stupid question. I did not remember it was there right before my eyes. It seems I just got lost in the new menu structure of the Kconfig. And yes, cache was in writethrough mode!! It seems as though this option disables cache entirely, because after turning it on, I suddenly get 2.4-type speed measurements. With CONFIG_8xx_COPYBACK undefined, both reading and writing gives results as if there was simply no cache. Shouldn't it at least speed up memory-read access? Sorry to everone for wasting their time with this stupid mistake of mine. Thanks for all the help anyway. Greetings, -- David Jander
Kernel 2.6 on MPC8xx performance trouble...
On Monday 31 October 2005 13:58, Mark Chambers wrote: >[...] > > No, sir, no cache detected ! > > > > Where do I have to look now? > > Could the cache be in writethrough mode? (Instead of writeback) Good point. I just checked the same test, but reading instead of writing. Same result, no cache detected. I know how to change cache policy in u-boot, but does the kernel change that? If so, where? Greetings, -- David Jander
Kernel 2.6 on MPC8xx performance trouble...
On Friday 28 October 2005 22:37, Wolfgang Denk wrote: >[...] > > They are just integers with fixed start values. These are in the loop, so > > it's not an empty loop and hopefully the compiler won't out-optimize it > > so easily (that is of course without specifying any optimization flags). > > Please don't tell me it's a lousy benchmark, because I already know that! > > Be it as lousy as it is, I shouldn't get _those_ results IMHO. > > Indeed, you should not get such results. If you compare with the > lmbench results of our 2.4/2.6 comparison, you will notice that we > did NOT see such behaviour. There was a perfromnce degradation for > pure integer tests, due to increased system overhead, but far from a > factor of 2. > See http://www.denx.de/wiki/pub/Know/Linux24vs26/lmbench_results I have seen them, and my conclusion is: Your kernel was working ok, while mine, a newer one, is broken. As you can see in the other e-mail I just posted (replying to Marcelo), at least the CPU cache seems to be disabled. Might this have something to do with processor model (mis-) identification? I had to apply the "ppc_sys: do not BUG if system ID is unknown" patch from Marcelo Tosatti a few days back in order to be able to boot in the first place. I had a look at ppc_sys system identification for 8xx and it looked a little bit nonsensical to me, since all 8xx report the same ID. Maybe the intention was to set the ID "by hand" in board support and setup. Problem is: there is still no real board-support infrastructure for mpc8xx, like there is for mpc82xx for example. What are the plans for 8xx? Should I try to emulate what others have done for some PQ2 platforms, i.e. create a arch/ppc/platforms/myplatform.c file and implement board_init()? Greetings, -- David Jander Protonic Holland.
Kernel 2.6 on MPC8xx performance trouble...
On Friday 28 October 2005 17:30, Marcelo Tosatti wrote: >[...] > David, > > Do you have CONFIG_PIN_TLB enabled? > > If you do, please patch this in: > > http://www.kernel.org/git/?p=linux/kernel/git/marcelo/8xx-fixes;a=commitdif >f;h=a41ba028534c45280170c05c23609ea84f34b38a > > And select DEBUG_PIN_TLBIE. Ok, done that... no change. I don't get any of those debug messages, so I guess that was not the problem. I have made another test in the meantime, trying to check if cache is working. The test is pretty simple: see how fast I can fill a block of memory whose size is increasing by a power of two. You should expect to see a step-like decrease in speed when surpassing the size of the data cache (4kbyte). The results are very suspicious: kernel-2.4: Memsize512 : 39.342773 Mbyte/s Memsize 1024 : 41.871094 Mbyte/s Memsize 2048 : 43.212891 Mbyte/s Memsize 4096 : 40.117188 Mbyte/s Memsize 8192 : 28.148438 Mbyte/s Memsize 16384 : 28.484375 Mbyte/s Memsize 32768 : 28.656250 Mbyte/s Memsize 65536 : 28.687500 Mbyte/s This looks quite healthy: above 4kbyte we see a clear drop in performance, so we just learned that our data-cache is most probably 4kbyte in size, wow! Kernel-2.6: Memsize512 : 21.033691 Mbyte/s Memsize 1024 : 22.047852 Mbyte/s Memsize 2048 : 22.601562 Mbyte/s Memsize 4096 : 22.882812 Mbyte/s Memsize 8192 : 23.007812 Mbyte/s Memsize 16384 : 23.093750 Mbyte/s Memsize 32768 : 23.125000 Mbyte/s Memsize 65536 : 23.125000 Mbyte/s No, sir, no cache detected ! Where do I have to look now? Greetings, -- David Jander Protonic Holland.
Kernel 2.6 on MPC8xx performance trouble...
On Friday 28 October 2005 11:36, Roger Larsson wrote:
> >[...]
> > Result: The test takes 3 seconds on kernel-2.6 and 1.5 seconds on
> > kernel-2.4. Here is what "time" has to say about it:
> >
> > real0m3.119s
> > user0m3.080s
> > sys 0m0.040s
> >
> > The test loop is pretty brain-dead, but that doesn't matter right now.
> > This is it:
> > []
> > gettimeofday(&tv0,NULL);
> > for(t=0L; t<1000L; t++)
> > {
> > a+=b; /* Do something */
> > }
> > gettimeofday(&tv,NULL);
> > [...]
> >
> > Any ideas?
> > Am I misconfiguring something? Is 2.6 support for mpc8xx still broken
> > (cache/tlb, mm, etc) or is 2.6 supposed to perform THAT bad??
>
> Have you verified the system measured time with wall clock (wrist watch)?
> System time could be wrong on one of the systems.
Yes. Wall-clock==gettimeofday-clock on both systems.
> What is 'a' and 'b'? The only other explanation I can see is that your
> "Do something" is more memory heavy than you think - array calculations?
> (Cache problems should probably give a worse result, but you could check
> that those config registers are the same).
They are just integers with fixed start values. These are in the loop, so it's
not an empty loop and hopefully the compiler won't out-optimize it so easily
(that is of course without specifying any optimization flags). Please don't
tell me it's a lousy benchmark, because I already know that! Be it as lousy
as it is, I shouldn't get _those_ results IMHO.
I have downloaded nbench (hopefully a more serious benchmark for raw computing
power), and the results are as follows (I deliberately excluded tests that
don't make sense (ie. use FP)):
Kernel 2.4.25:
TEST: Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
:--:-:
NUMERIC SORT: 30.438 : 0.78 : 0.26
STRING SORT : 1.5842 : 0.71 : 0.11
BITFIELD: 7.9506e+06 : 1.36 : 0.28
FP EMULATION: 3.258 : 1.56 : 0.36
IDEA: 108.89 : 1.67 : 0.49
Kernel 2.6.14-r5:
TEST: Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
:--:-:
NUMERIC SORT: 21.042 : 0.54 : 0.18
STRING SORT : 0.88215 : 0.39 : 0.06
BITFIELD: 6.0979e+06 : 1.05 : 0.22
FP EMULATION: 1.6453 : 0.79 : 0.18
IDEA: 110.25 : 1.69 : 0.50
Now, the strange thing is, IDEA is the only test where 2.6 is slightly faster
(results are consistent over repeated runs). Compiler options are: "-s
-static -Wall -O3 -msoft-float", FP-emulation in the kernel is never
activated.
I think I will need to look closer at how the "IDEA"-test works, but first
I'll have to run the nbench sources through "indent", because they are pretty
unreadable as is ;-)
I also downloaded oprofile, and am studying its manual right now. Hopefully
using this might get me a clue. If anybody already happens to know the
answer, please shout!
Greetings,
--
David Jander
Kernel 2.6 on MPC8xx performance trouble...
Hi all,
Many people have said it before: 2.6 has a performance penalty specially for
embdedded systems.
But now that I have 2.6 running on our 100MHz MPC852T based board, I was
shocked to see the result:
The most simple task doing nothing but a closed loop of integer math runs at
_half_ the speed compared to kernel 2.4.25!
Here are the conditions for the test:
- Bogomips are the same, so the CPU definitely runs at the same clock-rate
(and not half) as with "2.4".
- Enabling and disabling preemption doesn't have any impact (as expected for
such kinds of tasks).
- Setting HZ to 100 or 1000 also has only about 3% impact on speed.
- The binary of the test program is the same in both cases (no re-compile with
other optimizations by accident).
- The hardware is the same (exact same board).
- Certain hardware drivers that are not ported to "2.6" yet were present in
"2.4" but (obviously) not in "2.6", but non of them could have a _positive_
impact on performance.
- Kernel versions are 2.4.25 (denx-devel) and 2.6.14-rc5 (denx-git 20051027).
Result: The test takes 3 seconds on kernel-2.6 and 1.5 seconds on kernel-2.4.
Here is what "time" has to say about it:
real0m3.119s
user0m3.080s
sys 0m0.040s
The test loop is pretty brain-dead, but that doesn't matter right now.
This is it:
[]
gettimeofday(&tv0,NULL);
for(t=0L; t<1000L; t++)
{
a+=b; /* Do something */
}
gettimeofday(&tv,NULL);
[...]
Any ideas?
Am I misconfiguring something? Is 2.6 support for mpc8xx still broken
(cache/tlb, mm, etc) or is 2.6 supposed to perform THAT bad??
Greetings,
--
David Jander
MPC8xx support in 2.6 and [PATCH] USB host controller selection...
Hi all, I am trying to figure out if kernel-2.6.x is already a (stable) option for MPC8xx processors. Any hints? experience? I just rsynced DENX's git tree (cg-clone will crash on a 404 error). Problems I have found until now: - Processor identification is still shady. Thanks to Marcello's patch yesterday, it now boots up without problems, but this definitely needs to be done. Who is working on this part? - USB Kconfig file for 2.6 kernel is broken. It is not correct to assume that you either have a PCI interface or a processor with internal HCI. Proof: We have a board based on MPC852T (no internal UHCI) which can plug into an (optional) daughter board with a ISP1160 on it. See attached patch. Maybe the patch should be sent elsewere since it has not much to do with PPC, so can someone please tell me where? Greetings, -- David Jander -- next part -- A non-text attachment was scrubbed... Name: usb-hcd-selection.patch Type: text/x-diff Size: bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051027/6125be9e/attachment.patch
jffs2 robustness against powerfailure
On Monday 17 October 2005 14:37, David Woodhouse wrote: > On Fri, 2005-10-14 at 11:35 +0200, David Jander wrote: > > We have a custom embedded linux board, based on a MPC852T processor, > > running 2.4.25 kernel from denx. Jffs2 has certain backported patches > > after cvs from 03/2005. > > That sounds like a recipe for pain. March 2005 wasn't a good time to > take a snapshot from CVS; that just happens to be the time that we > stopped bothering to make it build in obsolete kernels. That's why I posted to the linuxppc-embedded list, because I know there are quite some people using the same version (denx CVS kernel), and might have had issues of this kind also, although I mostly hear that it seems pretty stable and doesn't give problems. > If you want _stable_ JFFS2 code, you should use the code which is in the > 2.4.31 kernel, or use the code which is in the 2.6 kernel (perhaps > updated from current CVS). 2.6 is not an option yet for mpc8xx architecture, so I'll have to stick with either what I have now or 2.4.31, but I fear the tradeoff of using vanilla 2.4.31 jffs2 will be much slower fs, prohibitively long mount-times, etc... am I right? >[...] > Please could you reproduce on a sane kernel and show the output of the > checkfs program during your test just before the power down, and also if > possible take an image of the contents of the flash _before_ mounting it > again after the power cycle. I'd like to see precisely the log nodes > which were present on the flash. If it's difficult to take a snapshot > before remounting, then running with CONFIG_JFFS2_FS_DEBUG=1 and > capturing all the KERN_DEBUG output via a serial console would suffice. I am still busy doing experiments, please have a little patience. Until now I have turned on debug info in the same kernel as before, and get literally tons of log info. My monitor script had a bug, so the board was reset a little to soon in several occasions (shouldn't harm, should it), so now I have an image of jffs2 which on boot of the system produces a BUG() in gc.c line 139. This is not what I am looking for right now, and I still have to discard any possibilities that this could have happened due to other problems (RAM issues, etc). Once I finish sorting this out, I'd be glad to send you a few megabytes of debug output along with a "broken" jffs2 image if you like. Actually I'd be very grateful if you could take some time to look at it and give me your opinion, because I am still slightly clueless about jffs2. Greetings, -- David Jander
jffs2 robustness against powerfailure
On Friday 14 October 2005 16:33, Mark Chambers wrote: >[...] > Well, I can tell you this, from bitter experience: Chips do strange stuff > when power is > coming or going. One thing that can happen is addresses get messed up, so > writes go > to the wrong place. You say your hardware is good, but it may not have > been thoroughly characterized for power-down behavior. Probably the same > chip that > generates a power-up reset generates a reset when power is falling, check > if the trip > voltage is high enough. There's a hardware watchdog which monitors both power-supplies and asserts reset in case of failure. It's reliable and it works. But that all doesn't matter. You seem to oversee three facts: 1.- The file being written to at the moment of power failure is always the file that has a CRC failure (if that happens) afterwards, not other files. So "writes go to the wrong place" is quite unlikely. 2.- If a piece of flash get's corrupted, there's always the jffs2's CRC that should trip and detect that block as invalid. 3.- If there really were writes to the wrong place, I'd expect that to be noticeable by looking at the files. There is random data being written to the files, but fortunately not that random: It's all 32-bit integers from 0...1. That makes the chances of corrupt random data, or valid data written to the wrong place not being noticed actually quite small! It looks to me very much like a jffs2 bug or design flaw, maybe a race-condition, but since I don't know jffs2 internals that much, I can't tell for sure. Isn't this a known issue? > You could rule a power problem out by running your tests where you reset > the processor (shorting hreset or poreset somewhere) but not power-cycling > the board, and see if > the failures are the same. I could do that, but I fear it will give the same results. Ok, for sciences sake I'll do that experiment. Sincerely, -- David Jander
jffs2 robustness against powerfailure
Hi, We have a custom embedded linux board, based on a MPC852T processor, running 2.4.25 kernel from denx. Jffs2 has certain backported patches after cvs from 03/2005. I wanted to try some stress-testing the flash using jffs2 and the "checkfs" tool which comes as part of the jffs2 sources. I setup a "power-cycle-box" as described in the README and started logging everything the system produced. Since jffs2 claims to be robust against power-failures I set the threshold for maximum number of corrupt files allowed to 0. The test procedure rewrites all testfiles using a single write() call for each file, so that should be ok. After 279 power-cycles, it stopped with a CRC error in "file13". Of course "file13" was the one being written to when power was cut off the last time. Question: Is this a known shorcoming of jffs2, or must I assume that my hardware is broken? The latter is relatively unlikely, once I try to explain the contents of the file: diskles9:/flash # hexdump file13 000 0300 036d 0942 20b0 010 08dd 0715 1da1 043c 020 05c2 228d 10ad 1c35 ... 2e0 14f1 0d94 1911 12dd 2f0 09e9 0686 2380 2294 300 18f1 01be 25bb 1af9 310 1b94 02b0 2511 1f79 320 1f97 0b53 1eb7 10bb 330 2529 2130 0361 0ff8 340 1428 10ab 0364 1b89 350 b110 As one can easily see, the first int (0x0300) indicates the file-length, after which the 16-bit CRC should be placed. At offset 300 in the file there seems to be just more random data (a CRC of 0x is unlikely and known wrong in this case). At the end of the file (offset 0x350) there is something that looks more like a checksum. Apparently the previous file was 0x0352 bytes long and the new file was going to be 0x0302 bytes long, but was never written completely. How comes I get a to see a valid file containing a mix of old and new data if it was written with a single write() call? Shouldn't jffs2 throw away the new incomplete node and keep the old version of the file? Can anyone explain what happened here?? Greetings, -- David Jander
serial console
On Tuesday 04 October 2005 17:16, Vitaly Bordug wrote: > Yes, but PQ2FADS use cpm_uart and hence the commandline should be > console=ttyCPM0,115200 You are totally right. I did that same mistake once in the past and again now. Shame on me ;-) Now that I remeber, this might give trouble if you happen to use a normal uart (16550 or similar) also, and devfs. I had to slightly hack serial.c in my version of the kernel for this combination to work. I don't remeber right now exactly what I did, but it had to do with "SERIAL_DEV_OFFSET" and major/minor numbers ;-) Anyway, I don't think your board has this combination. Greetings, -- David Jander
serial console
On Tuesday 04 October 2005 08:54, KokHow Teh wrote: > Hi; > I have debian linux running on my PQ2FADS-ZU with devfs and serial > driver compiled in. I have read Documentation/serial-console.txt and I have > tried both passing "console=" option as well as without passing that to the > kernel and both don't give me the expected results. > When I pass "console=tts/0,115200n8" to the kernel, I don't get any > console output until the login prompt which I set to 115200 in > /etc/inittab. When I don't pass "console=" option to the kernel, I get > console output all the way until "Freeing unused kernel memory:" and the > console output is garbled and I don't see any login prompt. Here is the > /dev/* content: I don't know exactly what I am talking about right now, but the string "tts/0" in the console-line sounds suspicious to me. AFAIK when using devfs still device names on the kernel-commandline have to be old-style. Just a guess: try using "console=ttyS0,115200n8" and see if this helps. Greetings, -- David Jander
Hello-new comer ask a start question.
Hi, On Monday 26 September 2005 23:41, Jerry Zhou wrote: > I am a new comer. Welcome ;-) > I have bring up a MPC850 board by vxWorks BSP, and I want to bring it up by > linux, would you please tell me how to start? Have a look at: http://www.denx.de/ And wade through the archives of this list. Greetings, -- David Jander
Which way to store log in flash on mpc8xx?
Hi again, On Monday 19 September 2005 21:21, Wolfgang Denk wrote: >[...] > Are you 100% sure your system is stable and wihout any memory errors? > Never seen any other erros or crashes? It has been running for several weeks without reboot processing data, and we have never had any other strange things, nor data corruption, crashes, or whatever. > > My big question: Is it at all possible that gc.c comes to that BUG() in > > line 139 because of anything other than a bug in jffs2-code? > > Yes, for example when your SDRAM initialization is broken and/or > other memory corruption happens. Then you would expect to have other symptoms too, don't you? Well, we don't have any other symptoms of SDRAM errors. Although, I have seen PC's with faulty SDRAM that behave as if the HD was broken, but the fine tool "memtest86" finally revealed the truth ;-) Is there something like memtest86 for linux-ppc (i.e. written in portable C)? >[...] > I don't think it's a flash error. If there is data corruption, then > it's more likely the SDRAM. Hmm, but there is no data corruption. I have not seen one file on flash that had other data than intended, and that inspite of the GC freaking out. > > The logs of almost all files in fs/jffs2/ which I have say that the > > actual version corresponds to the CVS-snapshot of March 13, 2005, and > > that the previous version of April 2004 is broken. > > Which files were modified _after_ March 13, 2005? > > (A hint to what command options or tools to use to browse cvs-logs more > > easily at this point is appreciated... I am using cervisia). > > cvsps is really helpful, see http://www.cobite.com/cvsps/cvsps-2.1.tar.gz > > Also there are web interfaces to our kernel tree; > for CVS see > http://81.169.171.120/cgi-bin/cvsweb/ > for git see > http://81.169.171.120/cgi-bin/gitweb.cgi Thanks for the tips. The gitweb interface looked quite impressive! > Make sure to use at least the version tagged as LABEL_2005_05_09_1245 > or later. We have that version. I have been trying to figure out what changed up until that label, but the only thing I found that looked relevant was: "Re-implement PatchSets 260, 263 and 303" That commit only changed 3 files, non of them directly related to jffs2 code, and only seemed to add support for FUJITSU flash chips. What am I missing? MTD developers say that cvs from march-2005 _is_ broken, so there must be some evident bug-fixes in your tree since then otherwise it is still broken (whatever it was). Of course, maybe I'm just blind ;-) > > I know about the problems jffs2 has with logfiles and alikes. I am still > > thinking about what would be the most robust way of coping with this, and > > until now, oversized partitions with log-rotation on size seems to do the > > trick. I don't want to loose log-data on power-loss so I don't feel so > > comfortable with buffering much of it in RAM. > > The problem with your approach is the number of erase cycles which > will cause the flash to die sooner than you may want. That's true, but under normal use, you'll have maybe 5..10 lines a day added to a given logfile, maybe even less, and since the partition is relatively huge, wear-levelling in the jffs2 driver should do the obvious I believe. It's not optimal, but it should work reliably AFAICT. Regards, -- David Jander Protonic Holland.
Which way to store log in flash on mpc8xx?
Hi again, Thanks for helping, On Monday 19 September 2005 17:37, Wolfgang Denk wrote: >[...] > Can you provide a little more details? The MTD / JFFS2 code in this > kernel is not too old, andwe use it in a couple of projects without > such problems. Ok, good you asked, because I am willing to debug the problem until I get to the point where it fails, but I will need help, because I am not at home in jffs2 source-code nor its CVS history. Here are more details: Kernel: Denx CVS from around july 2005 or something. AFAIK there are no further modifications other than BSP-specific stuff to the MTD code since that day, so I won't bother upgrading any further right now. Hardware: MPC852T custom board with a 32Mbyte mirror-bit flash-chip (x16 bus) Software: System based on ELDK-3.1.1. Intended flash-layout and use: rootfs : 10Mb, ro, hardly ever changed app: 6Mb, ro, changed on software-upgrade by replacing partition. log+config : 12Mb, rw The log+config partition is extremely oversized, because we are aware of the inefficiency of jffs2 for such purposes, we have the available space and we want to stay out of trouble. Syslog writes to 4 log-files which are limited in size to 50..100kbyte each. Logs are then rotated and one rotated copy is kept. Maximum flash use is around 800kbyte for logs + 50kbyte for config data. On a 12Mbyte partition, that shouldn't get us into trouble AFAIK. > > waiting for GC. I have debugged that problem a little bit, and > > definitely, the FLASH access works ok, and the chip is new. No CRC- or > > read-errors, but still gc.c crashes. > > Can you provide soem more information for debugging? Unfortunately right now I don't have debug messages, because since I installed a kernel with debugging turned on in the jffs2 driver, the problem hasn't repeated. I am working on that. What happened: System boots, all fs are mounted. The first app that writes something to the log-partition (in this case a config file that is overwritten) causes the GC thread for that partition to crash with a BUG() in line 139 of gc.c, and the application freezes forever. Since GC is dead, all further write-accesses to that partition also hang forever. The problem seems to ocurr after a few times power-cycling the board. We never intended it to shut-down nicely, if it is at all ever shut-down, so it must be able to survive quite a few power-cycles without breaking. After a few more power-cycles, the problem is gone again. Each time GC kicks in, it does something, but it crashes before finishing the job, so each time the numbers reported by the printk() in line 138 change, and eventually it work again. My big question: Is it at all possible that gc.c comes to that BUG() in line 139 because of anything other than a bug in jffs2-code? I mean, if hardware really was a problem, then I should also get at least CRC-errors from jffs2, shouldn't I? IMHO at least, jffs2 should be robust enough to not crash on flash-errors, shouldn't it? Also, I am pretty certain that the hardware is good but you never know... > > The version of mtd/jffs2 drivers in that kernel seem to be from > > march/2005 cvs code, but when I read the following, I get even more > > scared: > > http://www.linux-mtd.infradead.org/source.html#kernelversions > > Don't worry. We backported the MTD / JFFS2 code. See the history of > changes on our CVS or git server. I am having trouble finding the right history, but that could be due to the fact that I am not very good at CVS (we use subversion which is slightly different) ;-) The logs of almost all files in fs/jffs2/ which I have say that the actual version corresponds to the CVS-snapshot of March 13, 2005, and that the previous version of April 2004 is broken. Which files were modified _after_ March 13, 2005? (A hint to what command options or tools to use to browse cvs-logs more easily at this point is appreciated... I am using cervisia). > > This must be a very common task (to store logfiles in flash), but I just > > can't seem to find the right way to do it. > > Note that log files may cause a lot of trouble when using a JFFS2 > file system. Youmay want to addd a buffering layer, like pramfs in a > dedicated RAM area (SRAM ideally). I know about the problems jffs2 has with logfiles and alikes. I am still thinking about what would be the most robust way of coping with this, and until now, oversized partitions with log-rotation on size seems to do the trick. I don't want to loose log-data on power-loss so I don't feel so comfortable with buffering much of it in RAM. Best Regards, -- David Jander Protonic Holland.
Which way to store log in flash on mpc8xx?
Hi all, I am looking for a reliable way to store logfiles in flash. The logfiles are written by syslogd. The problem is that I am running on a MPC8xx processor, and kernel 2.6 is not quite there yet for that processor, so I have to stick with 2.4. Kernel of choice seems to be denx linuxppc_2_4_devel, but I cannot trust the version of jffs2 used in that kernel anymore. Somtimes gc.c crashes with a BUG() in line 139, and sometimes processes are frozen for a looong time waiting for GC. I have debugged that problem a little bit, and definitely, the FLASH access works ok, and the chip is new. No CRC- or read-errors, but still gc.c crashes. The version of mtd/jffs2 drivers in that kernel seem to be from march/2005 cvs code, but when I read the following, I get even more scared: http://www.linux-mtd.infradead.org/source.html#kernelversions So, I need something different. jffs (1) maybe ? This must be a very common task (to store logfiles in flash), but I just can't seem to find the right way to do it. Any advice is highly appreciated. Sincerely, -- David Jander Protonic Holland.
Question about ELDK and i18n...
Hi,
I am using ELDK-3.1, and I am not getting i18n to work. I have looked at
recent changelog of ELDK and newer (CVS) versions don't seem to fix any bug
in that direction.
The installation seems ok, the locale-files are all there as it seems.
I have tried this as a test:
# LANG=es_ES strace tar
in the output, I can see these relevant lines:
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
- This does not matter.
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
- OK, good. locale.alias is read
open("/usr/lib/locale/es_ES/LC_IDENTIFICATION", O_RDONLY) = 3
- Also looks fine, read the locales identification.
open("/usr/lib/locale/es/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such
file or directory)
- Here I am puzzled. Why? Maybe this is not important.
Then there are no more calls to open or stat with files in "/usr/lib/locale"
nor "/usr/share/locale" as argument, and I can't figure out why. What am I
doing wrong? Is this version of glibc in ELDK broken?
Best regards,
--
David Jander
How reliable is jffs2 really (denx cvs devel kernel)?
On Tuesday 19 July 2005 20:37, you wrote: >[...] > You probably want to ask this on the MTD mailing list; don't forget > to mention the exact version of the MTD / JFFS2 code you're using > (see CVS history). I already thought it might be a good idea to subscribe to that list. Any hint about how I can figure out exactly which version of MTD code I have? The version of linuxppc_2_4_devel I have is about 2 months old, do I have to expect important changes concerning MTD since then? While we are there, what other solution would you suggest for this problem: We need to log data into flash. Right now I use an oversized jffs2 partition, log via syslogd and logrotate on size. I am getting the impression that this is not workable for mission critical things. At least not with the kernel and MTD code I have. Others must have the same problem, so here's my question: Which way to do such a thing? Write my own filesystem? Greetings, -- David Jander
How reliable is jffs2 really (denx cvs devel kernel)?
Hi, I have seen some strange problems with jffs2. I have been victim of the BUG() in fs/jffs2/gc.c, line 139. I have been battling with kgdb to see what happens there. Here are my findings until now (I am still working on this): c->checked_ino starts counting from 0 c->highest_ino is 92 () Isn't this a little low? Flash partition size is 15Mbyte, it probably has been mistreated by writing large files (logfiles) line by line, wasting a lot of space until it gets almost full. When debugging the for(;;) loop, used size starts from a few kb counting up, dirty size is around 5 Mb and unchecked size is about 9.9Mb, so when it gets past inode 92 it most probably has still a lot of unchecked space.===> BUG(). Googleing for this bug, I have found discouraging e-mails (luckily most of them from 2003 or older) saying that this is common and nobody (back then) seemed to know where it came from. Bugs in fjjs2 code, etc This is scaring me. Anybody knows more about this problem, why it is caused, and hopefully how to prevent this? Thanks, -- David Jander
problems on isp1362 driver
On Friday 17 June 2005 21:12, Wolfgang Denk wrote: > in message <01c57347$04a45d00$07070a0a at luj> you wrote: > > We are using Philips ISP1362 usb controller on our ppc-embedded system. > > We have ported the phlips's driver, PHCI, to ppc. The Philips linux > > driver is that of 2002. > > You cannot do that. The Philips driver comes uner a proprietary > license which is incompatible with the GPL. You must not use their > driver in the context of a Linux kernel or any other GPLed software. > You are either violating the GPL, or the Philips license. Be > careful!!! IANAL, but I think theoretically at least, it should be possible, if you manage to craft sort of a "GPL abstraction layer" around the philips driver, to shield it from "GPL influence" in the kernel, just like Nvidia and others do. To the letter of the GPL that is not possible, but AFAIK the linux kernel license grants an exception that permits binary-only drivers for instance. Anyway, it probably is a bad and dangerous idea to try to pull this off. As for me, I decided it is much safer to stay as far away as possible from the philips source. Looking at it could be fatal for an OSS-coder like me (my eyes could get poisoned). Here goes a big "BOOOO" to Philips for doing this in the first place :-( Greetings, -- David Jander
jffs2 freezing in gc for long time...
On Thursday 16 June 2005 15:12, Per Hallsmark wrote: > A hot tip would be to configure either syslog to log to a logserver > or at least mount a tmpfs filesystem on /var/log. We do this already the old way, with a ramdisk mounted on /var, and the rw-jffs2 partition mounted on /flash, then /var/log/xxx is a link to a directory in /flash/log/, where I place "persistent" log files. /var/log/messages and friends reside on the ramdisk only. /tmp is a symlink to /var/tmp. Well, the use of tmpfs is indeed easier, so thanks anyway for the tip. > Running a syslog could wear out the flash quite quickly, especially > during the development phases... That's true, but we need some logfiles (logged via syslogd) to be persistent and survive reboots at any moment, but we can't afford a system freeze just because the GC-routine needs to run. I still need to study syslogd, to see what it does when writing becomes blocked for a long time. Does syslogd buffer? For how much data? Will I loose data in the end or will the calling process hang? If someone has experience with this, and knows the answer to some of these questions, I'd be glad to hear it. Greetings, -- David Jander
jffs2 freezing in gc for long time...
Hi list, I have the following situation: CPU: MPC852T-100MHz Flash: 32Mbyte mirror-bit, 15Mbyte jffs2 partition rw-mouted Kernel: 2.4.25 (linuxppc_2_4_devel CVS from denx from a month ago or so, with custom patches not concerning MTD at all). For completeness, it contains the file fs/jffs2/gc.c version: gc.c,v 1.145 2005/02/09 09:09:01 Sometimes, I get this: During boot, mounting is quick, but when starting syslogd, it freezes for some 20 minutes, then syslogd returns an error (exit!=0) but the daemon keeps running in background, as well as the garbage collection thread from jffs2 for some additional minutes. During that time, everything like "ls -l" on a certain directory of the flash partition freezes (status D is ps aux) until the GC thread has finished. I can understand that GC has to occur at some time, but is it normal that it takes THAT long??? Is there a newer version of the MTD driver that does not present these symptoms? If this is supposed to work like that, I would say jffs2 is pretty useless for any embedded system, so it is not supposed to be like that, right? RIGHT?? What am I doing wrong? Is the flash partition too big? Shouldn't I be using jffs2? Any advice is appreciated... Greetings, -- David Jander
Status of isp116x driver... (on mpc8xx)?
On Wednesday 11 May 2005 15:28, Wolfgang Denk wrote: >[...] > > Is the isp1160 chip really supported by the driver? tested? > > We only use (and tested) this driver with a ISP1361 ... Ok. The sources of your driver and the one from Roman Weissgaerber look very different, so I can't really tell: did you start from scratch and picked some things from RW's driver, or did you modify (beyond recognition) and extend his driver? I ask, because now I have RW's driver (version 0.9.6) working almost 100% alright. The issues we still have are most probably related to bus-timing problems (the ISP1160 is connected via a CPLD on an 8-bit wide bus controlled by UPMA!) and occur sporadically. Your driver OTOH still doesn't manage to receive Atl packets that are not entirely filled with zeroes ;-) > > Is someone using a isp116x on a mpc8xx and can tell his experience on > > getting it working? > > Sorry, we don't have any experience with a 1160. The driver in our > tree works fine with the 1362, both as host driver and as device (as > a gadget driver). I'll work on the problem, and if I get your driver working, I'll send a patch that hopefully fixes 116x support again ;-) Greetings, -- David Jander Protonic Holland.
Status of isp116x driver... (on mpc8xx)?
Hi, I connected a Philips ISP1160 usb host controller to a MPC852T-based custom board. I am using CVS kernel from DENX. I added some stuff to hcd-1161.h and hcd-1161.c to support our hardware, and it seems to work at first. The controller is recognized, initialized and everything seems fine, but when I connect a device to one of the two ports, every time the function fnvIsp1161AtlRead() is called, it reads in a 72 byte-long block of zeroes. Then I get "not enough configurations..." (error=-22). If I printk-out the contents of the buffer status register (REG_BUFF_STS) at that point, it is zero (=no data read). Nevertheless, putting a scope on the physical USB wires, I can see quite some amount of non-zero data flying by. Is the isp1160 chip really supported by the driver? tested? Are access timings very critical? I see some ugly iodelay_hcd() calls here and there, are they necessary? why? What about the other (older??) hc_isp116x.c driver floating around somewhere on the net, from Roman Weissgaerber? I found version 0.9.6 (apparently for kernel 2.4.22) somewhere, made some adaptations to get it loaded in our kernel but it either oopses after initializing the hc, or simply freezes. Whats the relationship between this and the driver hacked by Wolfgang Denk? Is someone using a isp116x on a mpc8xx and can tell his experience on getting it working? Greetings, -- David Jander Protonic Holland.
porting linux on power pc mpc8xx
Hi Prinson, On Friday 29 April 2005 12:32, prinson varghese wrote: > I am new to the embedded system development .How i can port linux kenel to > power pc MPC 8XX It is already ported to most known mpc8xx devices. You should start off, going through the archives of this mailing-list, and visit this site: http://www.denx.de There you can download actual sources of linux-2.4 kernels. My advice, use linux_2_4_devel cvs tree if you have no particular reason to use another tree. What processor do you use? What board? Is it a custom design or an existing board? You might be interested in u-boot also (the most commonly used bootloader for these kind of embedded processors). > and where i can get the kernel for the same? www.denx.de, but probably also from www.mvista.com, and many others. > awaiting rpaly ASAP I am OK with this, but "ASAP" does not sound as polite as you should be addressing a mailing list ;-) Sincerely, -- David Jander Protonic Holland.
Which kernel to use?
On Friday 01 April 2005 15:34, Buday Gergely Istv?n wrote: > I have a gadget built around a ppc xpc850xxztb processor with 2M flash and > 8M ram. The opsys is Hard Hat, but I'd like to change it to an > openembedded-based solution. Where can I get sources for a proper kernel > that works with this system? Have a look at www.denx.de Take the development branch of 2.4 from that site and stop sticking the finger in that wound ;-) Greetings, -- David Jander
[PATCH] Include support for physmap driver in mpc8xx setup...
Hi, I'd like to hear comments about this. I am working with a fairly recent denx kernel tree (linuxppc_2_4_devel) and have noticed that apparently support for physmap MTD mapping driver is missing. Since physmap.c version 1.29 on, flash start address, size and buswidth have to be setup by the board support package, but mpc8xx uses a centralized .c file (arch/ppc/m8xx_setup.c) and include-files from arch/platforms/*, so there is no way of specifying flash geometry. I suggest something like this to solve the problem. If there is a better place to put this, please let me know. - begin patch -- ---?arch/ppc/kernel/m8xx_setup.c.orig +++?arch/ppc/kernel/m8xx_setup.c @@?-35,6?+35,9?@@ ?#include? ?#include? ?#include? +#if?defined(CONFIG_MTD_PHYSMAP)?&&?defined(CONFIG_MTD) +#include? +#endif ? ?#include? ?#include? @@?-510,4?+513,8?@@ ?#if?defined(CONFIG_IDE_8xx_PCCARD)?||?defined(CONFIG_IDE_8xx_DIRECT) m8xx_ide_init(); ?#endif +#if?defined(CONFIG_MTD_PHYSMAP)?&&?defined(CONFIG_MTD) + /*?we?use?generic?physmap?mapping?driver?and?we?use?partitions?*/ + physmap_configure(CONFIG_MTD_PHYSMAP_START,?CONFIG_MTD_PHYSMAP_LEN,? CONFIG_MTD_PHYSMAP_BUSWIDTH,?NULL); +#endif ?} -- end patch --- Greetings, -- David Jander Protonic Holland.
Freeing unused kernel memory: 56k init
On Sunday 20 February 2005 16:25, srinivas.surabhi at wipro.com wrote: > When I tried to debug for the reason of "Freeing unused kernel memory: > 56k init " hang problem the following is the printk outputs... > > Entering kernel_read > > Entering elf_map > > map_addr was 0x30026000 Heh? Weired address. I'd expect something above 0xc000 > Failed due to bad address No wonder > >From the above can anything be concluded ? > > One more doubt was, is it mandatory that the Virtual memory has to > enabled while building the Mounta Vista linux kernel ? Why because there > was an option to enable the kernel base address and if it is enabled it > asks for what is the address for the Kernel Virtual base address? If I > give 0x0 it works otherwise the Kernel itself is not at all booting. Ok, don't say no more! Do not ever change that address unless you know exactly what you are doing. It should be 0xc000 usually. If the kernel doesn't boot, something else is wrong. The linux kernel uses virtual memory, that's why it needs an MMU for instance. That way, the memory the kernel uses and runs in is always mapped at address 0xc000. > Till the statement "Freeing unused kernel memory: 56k init" is coming > only if and if the 0x0 was given for the kernel virtual base address. That's actually pretty funny. I'd never thought about doing such an experiment and expecting it to do something :-) Greetings, -- David Jander Protonic Holland.
Freeing unused kernel memory: 56k init - hang problem
On Friday 18 February 2005 05:16, srinivas.surabhi at wipro.com wrote: > Is there any patch for ppc-8260 for the hang problem after the following > output on the serial console. > > "Freeing unused kernel memory: 56k init" I don't know about any known "hang problem" or such, but at that point, normally your root filesystem is mounted and /sbin/init is executed. So if it hangs there, probably something is wrong with your root filesystem. Could you tell more about what board/kernel/sdk/etc... you are using? Where is "/" supposed to be mounted from? NFS? flash? initrd? Greetings, -- David Jander Protonic Holland.
Which kernel tree for future 8xx development?
Hi, Which (of the many) is the most recommended 2.4.x tree for mpc8xx devices (specially the MPC852T). We are developing our own board-support stuff and drivers (it's a custom board designed by us). Currently we have linuxppc-2_4_devel from DENX cvs and linuxppc-2_4_devel from bitkeeper, which seems to be a newer kernel version, but with much less different boards supported and less features for motorola powerpc processors. What's the status of CPM driver stuff for instance? We started on DENX kernel sources and switched to bitkeeper because of some misinterpreted advice I received from this list about an unrelated problem, only to find apparently less mpc8xx support. Now I am observing myself doing apparently absurd things as for example taking arch/ppc/8260_io/cpm_spi.c from DENX and putting it into arch/ppc/8xx_io/ from bitkeeper and hacking until it works (again). It still doesn't. Where on earth is the original driver (which was for MPC860, not MPC8260)!?? Before we port all of our stuff once again from one tree to another, can someone please give me a good advice on which way to go now and in forseeable future? One day I'd like to be able to make all our board-support stuff into something useful for others and go beg for inclusion in the main sources but where? Greetings, -- David Jander Protonic Holland.
QSlinux dead?
Hi, I am looking for some pointers to people who work on QSlinux, or if it's dead, who know where I can ge the source. I went to www.qslinux.org, but the links there are mostly dead, all e-mail sent to addresses listed on the support page of snmc (the makers of qs) bounce back. Does anybody on this list know what's happening to SNMC (QSlinux)? They claim to have developed several MPC8xx drivers, released under GPL, but as of today I am unable to find a trace of them. Only thing left is calling the phone number listed on their site, but I figured that I might better ask around here first. Greetings, -- David Jander
The RS485 driver problem...
Hi, If you want to connect a RS485 transceiver to a normal UART, you always have the problem of dealing with enabling/disabling transmitter and recveiver. I have seen hardware that misuses RS-232 hardware handshaking lines (RTS/CTS) for this purpose. What I have not been able to find is a linux driver or software solution to this problem. Has anybody used the CPM uarts (or even a standard 16C550 uart) for this purpose? How? Greetings, -- David Jander Protonic Holland.
FW: cpm_spi.c under kernel 2.6
On Wednesday 19 January 2005 17:49, annamaya wrote: > That reminds me that I need to make the spi driver > available somewhere all the time. But I am not sure > when I will be able to do that. Meanwhile, you should > be able to start of with the old driver for the 8xx > that should be around somewhere under the rubble. :-) > Or, you can start off with the sample code in u-boot > that was derived from the original driver. I just wanted to add, that if anyone is going to get busy again with the 8xx SPI driver(s) in u-boot and linux-2.4, I'd like to know, since I am too. In u-boot there are two 8xx-SPI-drivers, one software and one in hardware, and they seem both broken now (I'm still using CVS versions around 1.1.2 somewhere maybe I should cvs update :-) Specifically spi_xmit() get each other in the way. There are two such functions in u-boot, both non-static and with (very) different prototypes, so I am starting to figure out the best way of fixing that mess. Is anyone busy with the same task? Greetings, -- David Jander Protonic Holland.
Linux 2.6-10.rc3 8xx - Only 3 characters are printed well in __ init start_kernel() upon kernel booting - why ?
On Sunday 16 January 2005 20:54, Povolotsky, Alexander wrote:
>[...]
> > to prove it I added printk("ALEX\n"); in __init start_kernel() prior to
> > printk(linux_banner);
> >
> > ...
> > lock_kernel();
> > page_address_init();
> > printk("ALEX\n");
> > printk(linux_banner);
> > setup_arch(&command_line);
> > setup_per_cpu_areas();
> > ...
> >
> > after gunzip
> > done.
> > Now booting the kernel
> > ALE??8??X??x??~??
> >? ??
> >
> >
> >
> > Why would first 3 characters come out right ?
> > Any ideas ?
My fairly uneducated guess: The system hangs before the last character comes
out of the uart buffer. Try adding a delay just after printk.
The garbage could be anything produced by a piece of hardware gone wild.
Greetings,
--
David Jander
Protonic Holland.
MPC8xx: Using SCM/SCC and standard 16C550 Uarts together...
On Wednesday 12 January 2005 10:59, Demke Torsten-atd012 wrote: > I dont know exactly the state of the DENX kernel, but in the standard > kernel the 8xx UART driver and the 16550 driver are using the same > device numbers (TTY_MAJOR) and device names (/dev/ttySx). > You have to change one of them. You are right! What now? I cannot go around and change TTY_MAJOR! Is it true then, that you normally cannot have a mix of non-16550 uarts and 16550 uarts on the same system, without doing nonstandard things with major numbers? Should maybe arch/ppc/8xx_io/uart.c use another major number? Greetings, -- David Jander Protonic Holland.
