[PATCH] Add USB hooks into NanoBone DTS file

[Mark Jackson]

Add USB hooks into NanoBone DTS file

Signed-off-by: Mark Jackson <m...@newflow.co.uk>
---
 arch/arm/boot/dts/am335x-nano.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-nano.dts 
b/arch/arm/boot/dts/am335x-nano.dts
index 5ed4ca6..b86937a 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -375,6 +375,23 @@
wp-gpios = < 18 0>;
 };
 
+ {
+   status = "okay";
+};
+
+_ctrl_mod {
+   status = "okay";
+};
+
+_phy {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   dr_mode = "host";
+};
+
 #include "tps65217.dtsi"
 
  {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Update Nanobone dts file

[Mark Jackson]

Update dts file to reflect:-
(1) new flash memory layout
(2) add missing phy-mode property

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 arch/arm/boot/dts/am335x-nano.dts | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-nano.dts 
b/arch/arm/boot/dts/am335x-nano.dts
index a346645..dfa610f 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -297,8 +297,8 @@
||--0x004F- Kernel end
||--0x0050- File system start
||
-   ||--0x014F- File system end
-   ||--0x0150- User data start
+   ||--0x01FF- File system end
+   ||--0x0200- User data start
||
||--0x03FF- User data end
||--0x0400- Data storage start
@@ -327,12 +327,12 @@
 
partition@4 {
label = rootfs;
-   reg = 0x0050 0x0100; /* 16MB */
+   reg = 0x0050 0x01b0; /* 27MB */
};
 
partition@5 {
label = user;
-   reg = 0x0150 0x02b0; /* 43MB */
+   reg = 0x0200 0x0200; /* 32MB */
};
 
partition@6 {
@@ -353,11 +353,13 @@
 
 cpsw_emac0 {
phy_id = davinci_mdio, 0;
+   phy-mode = mii;
dual_emac_res_vlan = 1;
 };
 
 cpsw_emac1 {
phy_id = davinci_mdio, 1;
+   phy-mode = mii;
dual_emac_res_vlan = 2;
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] Update Nanobone dts file

[Mark Jackson]

Update dts file to reflect:-
* new flash memory layout
* add missing phy-mode property
* dual_emac now just a boolean
* rename mcp to microchip
* update gpio definition

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 arch/arm/boot/dts/am335x-nano.dts | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-nano.dts 
b/arch/arm/boot/dts/am335x-nano.dts
index a346645..5ed4ca6 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -213,7 +213,9 @@
pinctrl-0 = i2c0_pins;
 
gpio@20 {
-   compatible = mcp,mcp23017;
+   compatible = microchip,mcp23017;
+   gpio-controller;
+   #gpio-cells = 2;
reg = 0x20;
};
 
@@ -222,7 +224,7 @@
};
 
eeprom@53 {
-   compatible = mcp,24c02;
+   compatible = microchip,24c02;
reg = 0x53;
pagesize = 8;
};
@@ -297,8 +299,8 @@
||--0x004F- Kernel end
||--0x0050- File system start
||
-   ||--0x014F- File system end
-   ||--0x0150- User data start
+   ||--0x01FF- File system end
+   ||--0x0200- User data start
||
||--0x03FF- User data end
||--0x0400- Data storage start
@@ -327,12 +329,12 @@
 
partition@4 {
label = rootfs;
-   reg = 0x0050 0x0100; /* 16MB */
+   reg = 0x0050 0x01b0; /* 27MB */
};
 
partition@5 {
label = user;
-   reg = 0x0150 0x02b0; /* 43MB */
+   reg = 0x0200 0x0200; /* 32MB */
};
 
partition@6 {
@@ -343,7 +345,7 @@
 };
 
 mac {
-   dual_emac = 1;
+   dual_emac;
status = okay;
 };
 
@@ -353,11 +355,13 @@
 
 cpsw_emac0 {
phy_id = davinci_mdio, 0;
+   phy-mode = mii;
dual_emac_res_vlan = 1;
 };
 
 cpsw_emac1 {
phy_id = davinci_mdio, 1;
+   phy-mode = mii;
dual_emac_res_vlan = 2;
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rts-gpio DT binding

[Mark Jackson]

On 19/03/14 14:59, Felipe Balbi wrote:
 Hi,
 
 On Wed, Mar 19, 2014 at 09:15:03AM +, Mark Jackson wrote:

[snip]


 Okay ... it comes back to me now.

 When using RS485 drivers, we're not actually using RTS as a Ready
 To Send, we're really using it as an enable RS485 driver.

 I just used the RTS mnemonic as we're now wanting to send some
 data so please now enable the RS485 driver, rather than the normal
 I'm ready for your to send me some data.

 So it's the opposite function.

 Maybe it was a poor choice of abbreviation ?

 As I said before, RS485 drivers might have active or active low
 enables, so we might need to invert the RTS polarity.  This is
 not handled by the hardware RTS signal.

 Is that a good enough explanation ?
 
 fair, but considering you can toggle RTS by hand with writes to MCR
 register, I still don't see the need for remuxing the lines as GPIOs.
 
 Just don't use auto-RTS and toggle the line by hand with MCR, no ?

TBH I hadn't realised you could do that, so I guess you could.

But my solution seems more flexible as it would allow you to add an RTS
signal to UART0 and UART5 which don't have any hardware handshaking lines.

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rts-gpio DT binding

[Mark Jackson]

On 18/03/14 16:55, Felipe Balbi wrote:
 Hi Mark,
 
 I'm looking at the omap-serial driver and saw that you added rts-gpio
 binding in commit 4a0ac0f55b18dc297a87a85417fcf068658bf103 (OMAP: add
 RS485 support) but, as it turns out, gpio0_13 and gpio2_15 are both
 actual RTS signals.
 
 Instead of adding that extra GPIO handling, why didn't you just mux
 those signals as RTS and enable auto-RTS/auto-CTS feature ?
 
 It looks to me like that's highly unnecessary binding.

I agree !!

I think it was to allow delays pre- and post- sending the comms data.

Several RS485 drivers require a warm up time before they will
transmit data correctly, and also need a cool down time to prevent
clipping of the last few bits of data.

IIRC the built-in RTS handling did not allow for this.

It also allows the RTS signal to be inverted, again required for
some RS485 driver chips.

However, I'll dig into why I did this and report back.

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Help needed to force USB host mode on AM335x CPU

[Mark Jackson]

We have a custom AM335x board where the USB0_ID pin has been left floating.

By default, this puts the USB controller into peripheral mode, but we need
to force it into host mode.

This can be achieved in s/w by setting some bits in the relevant USB mode
register (see TRM 16.5.2.35).

This mode register's offset is already defined in musb_dsps.c

static const struct dsps_musb_wrapper am33xx_driver_data = {
...
.mode   = 0xe8,
...
};

I can manually set this register to the correct value in musb_host.c and
the USB all seems to work as expected.

int musb_host_setup(struct musb *musb, int power_budget)
{
int ret;
struct usb_hcd *hcd = musb-hcd;

/* Force HOST mode */
unsigned long __iomem *p;
p = ioremap(0x474010e8, 4);
*p = 0x80;  /* IDDIG = 0, IDDIG_MUX = 1 */

MUSB_HST_MODE(musb);
...
};

Ideally I'd like to add an entry in my dts file to flag for this force mode
to be setup, such as:-

usb@47401000 {
status = okay;
dr_mode = host;
ti,force-host;  /* force host mode */
};

Can anyone point me in the right direction as to where to put this extra code ?

I see there's a musb_am335x.c file, but that just seems to be a wrapper.

Any help would be greatly apperciated.

Regards
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Allow MUSB DSPS to use force host mode

[Mark Jackson]

The IDDIG input pin is normally used to determine the USB mode
(i.e. HOST or DEVICE).

On some systems (e.g. AM335x) leaving this pin floating allows
the USB mode to be set via software.

This patch adds support for this via the device tree.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 .../devicetree/bindings/usb/am33xx-usb.txt |2 ++
 drivers/usb/musb/musb_dsps.c   |   14 ++
 include/linux/usb/musb.h   |1 +
 3 files changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index 20c2ff2..560b7ff 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -47,6 +47,8 @@ USB
 - dmas: specifies the dma channels
 - dma-names: specifies the names of the channels. Use rxN for receive
   and txN for transmit endpoints. N specifies the endpoint number.
+- ti,force-host: specifies that the IDDIG input be ignored and the device be
+  put into host mode regardless.
 
 The controller should have an usb alias numbered properly in the alias
 node.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..6439809 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,7 @@ struct dsps_musb_wrapper {
unsignedotg_disable:5;
 
/* bit positions for mode */
+   unsignediddig_mux:5;
unsignediddig:5;
/* miscellaneous stuff */
u8  poll_seconds;
@@ -387,6 +388,15 @@ static int dsps_musb_init(struct musb *musb)
 
musb-isr = dsps_interrupt;
 
+   /* Force host mode, rather than relying on IDDIG input */
+   if (musb-config-force_host) {
+   val = dsps_readl(reg_base, wrp-mode);
+   /* clear IDDIG bit, set IDDIG_MUX bit */
+   val = ~(1  wrp-iddig);
+   val |= (1  wrp-iddig_mux);
+   dsps_writel(musb-ctrl_base, wrp-mode, val);
+   }
+
/* reset the otgdisable bit, needed for host mode to work */
val = dsps_readl(reg_base, wrp-phy_utmi);
val = ~(1  wrp-otg_disable);
@@ -512,6 +522,9 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
pdata.power = get_int_prop(dn, mentor,power) / 2;
config-multipoint = of_property_read_bool(dn, mentor,multipoint);
 
+   if (of_property_read_bool(dn, ti,force-host))
+   config-force_host = true;
+
ret = platform_device_add_data(musb, pdata, sizeof(pdata));
if (ret) {
dev_err(dev, failed to add platform_data\n);
@@ -607,6 +620,7 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.mode   = 0xe8,
.reset  = 0,
.otg_disable= 21,
+   .iddig_mux  = 7,
.iddig  = 8,
.usb_shift  = 0,
.usb_mask   = 0x1ff,
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..a0a81c5 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -75,6 +75,7 @@ struct musb_hdrc_config {
unsignedhigh_iso_rx:1;  /* Rx ep required for HD iso */
unsigneddma:1 __deprecated; /* supports DMA */
unsignedvendor_req:1 __deprecated; /* vendor registers required 
*/
+   unsignedforce_host:1;   /* force host mode */
 
u8  num_eps;/* number of endpoints _with_ ep0 */
u8  dma_channels __deprecated; /* number of dma channels */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Allow MUSB DSPS to use force host mode

[Mark Jackson]

On 22/11/13 16:38, Michael Grzeschik wrote:
 Hallo,
 
 On Fri, Nov 22, 2013 at 03:55:59PM +, Mark Jackson wrote:
 The IDDIG input pin is normally used to determine the USB mode
 (i.e. HOST or DEVICE).

 On some systems (e.g. AM335x) leaving this pin floating allows
 the USB mode to be set via software.

 This patch adds support for this via the device tree.

 Signed-off-by: Mark Jackson m...@newflow.co.uk
 ---
  .../devicetree/bindings/usb/am33xx-usb.txt |2 ++
  drivers/usb/musb/musb_dsps.c   |   14 ++
  include/linux/usb/musb.h   |1 +
  3 files changed, 17 insertions(+)

 diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
 b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
 index 20c2ff2..560b7ff 100644
 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
 +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
 @@ -47,6 +47,8 @@ USB
  - dmas: specifies the dma channels
  - dma-names: specifies the names of the channels. Use rxN for receive
and txN for transmit endpoints. N specifies the endpoint number.
 +- ti,force-host: specifies that the IDDIG input be ignored and the device be
 +  put into host mode regardless.
 
 You should always CC devicetree-discuss if adding new bindings. Why
 another binding anyway? We have the common binding dr_mode already.
 Please use this and of_usb_get_dr_mode from drivers/usb/usb-common.c
 instead.

Sure ... that's a nicer solution.

I'll do that for v2

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Allow MUSB DSPS to use force host mode

[Mark Jackson]

On 22/11/13 16:33, Sebastian Andrzej Siewior wrote:
 On 11/22/2013 04:55 PM, Mark Jackson wrote:
 The IDDIG input pin is normally used to determine the USB mode
 (i.e. HOST or DEVICE).

 On some systems (e.g. AM335x) leaving this pin floating allows
 the USB mode to be set via software.
 
 So you have a board where musb is used only as host or only as device
 and the ID pin not on ground or 3.3V?
 What are the side effects? I remember correctly Bin wanted to avoid
 settings this if it could be avoided.

Yes ... we have a host only USB port and an unconnected ID pin.

AFAIK it defaults to device mode so I can't see any devices that get
plugged into the USB port.

If I tweak the s/w to force host mode on, then everything appears to
work okay.

I guess it's more of a hardware oversight that we left the pin floating
but in the real world, I guess someone may want this feature to they
can change the usb port type ?

Either way, I need to fix the current h/w (which can be done via s/w)
hence the patch.

Mark J.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Allow MUSB DSPS to use force host mode

[Mark Jackson]

On 22/11/13 17:01, Sebastian Andrzej Siewior wrote:
 On 11/22/2013 05:49 PM, Mark Jackson wrote:
 and the ID pin not on ground or 3.3V?
 What are the side effects? I remember correctly Bin wanted to avoid
 settings this if it could be avoided.

 Yes ... we have a host only USB port and an unconnected ID pin.
 
 Is it too late to connect that pin?

Unfortunately, yes.

The USB portion of the CPU board has not been needed until now, and
although I did know about the unconnected pin, I also knew it could be
fixed in s/w, so I wasn't too concerned.

 AFAIK it defaults to device mode so I can't see any devices that get
 plugged into the USB port.

 If I tweak the s/w to force host mode on, then everything appears to
 work okay.

 I guess it's more of a hardware oversight that we left the pin floating
 but in the real world, I guess someone may want this feature to they
 can change the usb port type ?
 
 This is something I would prefer to avoid if possible. We have the
 dr_mode attribute in DT. Based on that one we act as a device or host.
 Now if you decide (via dr_mode) either for host or device that means we
 have to set that bit. Where I feel a little uncomfortable is when
 someone having OTG runs in hostmode and attaches a host.
 

 Either way, I need to fix the current h/w (which can be done via s/w)
 hence the patch.
 I've seen many projects where this pin has been forgotten and it could
 not be changed in SW and they patched the HW. Usually this is noticed
 in the early phase and a wire is just soldered and the redesign has it
 fixed. So I don't think that this is a big issue.
 Do you insists on having this change merged upstream?

No ... I didn't think it would be such an issue, so I'm happy to keep this
as a local patch if that's any better.

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] Add support for Newflow NanoBone board

[Mark Jackson]

On 25/09/13 09:04, Mark Jackson wrote:
 NanoBone Specification:
 ---
 CPU:
   TI AM335x
 
 Memory:
   256MB DDR3
   128MB NOR flash
   128KB FRAM
 
 Ethernet:
   2 x 10/100 connected to SMSC LAN8710 PHY
 
 USB:
   1 x USB2.0 Type A
 
 I2C:
   2Kbit EEPROM (Microchip 24AA02)
   RTC (Maxim DS1338)
   GPIO Expander (Microchip MCP23017)
 
 Expansion connector:
   6 x UART
   1 x MMC/SD
   1 x USB2.0
 
 Signed-off-by: Mark Jackson m...@newflow.co.uk
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

snip

Any chance someone could accept / comment on this patch ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] Add support for Newflow NanoBone board

[Mark Jackson]

NanoBone Specification:
---
CPU:
  TI AM335x

Memory:
  256MB DDR3
  128MB NOR flash
  128KB FRAM

Ethernet:
  2 x 10/100 connected to SMSC LAN8710 PHY

USB:
  1 x USB2.0 Type A

I2C:
  2Kbit EEPROM (Microchip 24AA02)
  RTC (Maxim DS1338)
  GPIO Expander (Microchip MCP23017)

Expansion connector:
  6 x UART
  1 x MMC/SD
  1 x USB2.0

Signed-off-by: Mark Jackson m...@newflow.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes in v3:
- Added MMC support
- Fixed regulator limits

Changes in v2:
- Reworked to use existing device nodes as suggested by Javier

 MAINTAINERS   |6 +
 arch/arm/boot/dts/Makefile|1 +
 arch/arm/boot/dts/am335x-nano.dts |  431 +
 3 files changed, 438 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-nano.dts

diff --git a/MAINTAINERS b/MAINTAINERS
index e61c2e8..8a4c9d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6062,6 +6062,12 @@ L:   linux-omap@vger.kernel.org
 S: Maintained
 F: drivers/gpio/gpio-omap.c
 
+OMAP/NEWFLOW NANOBONE MACHINE SUPPORT
+M: Mark Jackson m...@newflow.co.uk
+L: linux-omap@vger.kernel.org
+S: Maintained
+F: arch/arm/boot/dts/am335x-nano.dts
+
 OMFS FILESYSTEM
 M: Bob Copeland m...@bobcopeland.com
 L: linux-karma-de...@lists.sourceforge.net
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e95af3f..543e837 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -184,6 +184,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
+   am335x-nano.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb
diff --git a/arch/arm/boot/dts/am335x-nano.dts 
b/arch/arm/boot/dts/am335x-nano.dts
new file mode 100644
index 000..9907b49
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -0,0 +1,431 @@
+/*
+ * Copyright (C) 2013 Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+   model = Newflow AM335x NanoBone;
+   compatible = ti,am33xx;
+
+   cpus {
+   cpu@0 {
+   cpu0-supply = dcdc2_reg;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x1000; /* 256 MB */
+   };
+
+   leds {
+   compatible = gpio-leds;
+
+   led@0 {
+   label = nanobone:green:usr1;
+   gpios = gpio1 5 0;
+   default-state = off;
+   };
+   };
+};
+
+am33xx_pinmux {
+   pinctrl-names = default;
+   pinctrl-0 = misc_pins;
+
+   misc_pins: misc_pins {
+   pinctrl-single,pins = 
+   0x15c (PIN_OUTPUT | MUX_MODE7)  /* spi0_cs0.gpio0_5 */
+   ;
+   };
+
+   gpmc_pins: gpmc_pins {
+   pinctrl-single,pins = 
+   0x0 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad0.gpmc_ad0 */
+   0x4 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad1.gpmc_ad1 */
+   0x8 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad2.gpmc_ad2 */
+   0xc (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad3.gpmc_ad3 */
+   0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad4.gpmc_ad4 */
+   0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad5.gpmc_ad5 */
+   0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad6.gpmc_ad6 */
+   0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad7.gpmc_ad7 */
+   0x20 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad8.gpmc_ad8 */
+   0x24 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad9.gpmc_ad9 */
+   0x28 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad10.gpmc_ad10 */
+   0x2c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad11.gpmc_ad11 */
+   0x30 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad12.gpmc_ad12 */
+   0x34 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad13.gpmc_ad13 */
+   0x38 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad14.gpmc_ad14 */
+   0x3c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad15.gpmc_ad15 */
+
+   0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_wait0.gpmc_wait0 */
+   0x7c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn0.gpmc_csn0 */
+   0x80 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn1.gpmc_csn1 */
+   0x84 (PIN_OUTPUT | MUX_MODE0

[PATCH v3] Add support for Newflow NanoBone board

[Mark Jackson]

NanoBone Specification:
---
CPU:
  TI AM335x

Memory:
  256MB DDR3
  128MB NOR flash
  128KB FRAM

Ethernet:
  2 x 10/100 connected to SMSC LAN8710 PHY

USB:
  1 x USB2.0 Type A

I2C:
  2Kbit EEPROM (Microchip 24AA02)
  RTC (Maxim DS1338)
  GPIO Expander (Microchip MCP23017)

Expansion connector:
  6 x UART
  1 x MMC/SD
  1 x USB2.0

Signed-off-by: Mark Jackson m...@newflow.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes in v3:
- Added MMC support
- Fixed regulator limits

Changes in v2:
- Reworked to use existing device nodes as suggested by Javier

 MAINTAINERS   |6 +
 arch/arm/boot/dts/Makefile|1 +
 arch/arm/boot/dts/am335x-nano.dts |  431 +
 3 files changed, 438 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-nano.dts

diff --git a/MAINTAINERS b/MAINTAINERS
index e61c2e8..8a4c9d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6062,6 +6062,12 @@ L:   linux-omap@vger.kernel.org
 S: Maintained
 F: drivers/gpio/gpio-omap.c
 
+OMAP/NEWFLOW NANOBONE MACHINE SUPPORT
+M: Mark Jackson m...@newflow.co.uk
+L: linux-omap@vger.kernel.org
+S: Maintained
+F: arch/arm/boot/dts/am335x-nano.dts
+
 OMFS FILESYSTEM
 M: Bob Copeland m...@bobcopeland.com
 L: linux-karma-de...@lists.sourceforge.net
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e95af3f..543e837 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -184,6 +184,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
+   am335x-nano.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb
diff --git a/arch/arm/boot/dts/am335x-nano.dts 
b/arch/arm/boot/dts/am335x-nano.dts
new file mode 100644
index 000..9907b49
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -0,0 +1,431 @@
+/*
+ * Copyright (C) 2013 Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+   model = Newflow AM335x NanoBone;
+   compatible = ti,am33xx;
+
+   cpus {
+   cpu@0 {
+   cpu0-supply = dcdc2_reg;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x1000; /* 256 MB */
+   };
+
+   leds {
+   compatible = gpio-leds;
+
+   led@0 {
+   label = nanobone:green:usr1;
+   gpios = gpio1 5 0;
+   default-state = off;
+   };
+   };
+};
+
+am33xx_pinmux {
+   pinctrl-names = default;
+   pinctrl-0 = misc_pins;
+
+   misc_pins: misc_pins {
+   pinctrl-single,pins = 
+   0x15c (PIN_OUTPUT | MUX_MODE7)  /* spi0_cs0.gpio0_5 */
+   ;
+   };
+
+   gpmc_pins: gpmc_pins {
+   pinctrl-single,pins = 
+   0x0 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad0.gpmc_ad0 */
+   0x4 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad1.gpmc_ad1 */
+   0x8 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad2.gpmc_ad2 */
+   0xc (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad3.gpmc_ad3 */
+   0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad4.gpmc_ad4 */
+   0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad5.gpmc_ad5 */
+   0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad6.gpmc_ad6 */
+   0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad7.gpmc_ad7 */
+   0x20 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad8.gpmc_ad8 */
+   0x24 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad9.gpmc_ad9 */
+   0x28 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad10.gpmc_ad10 */
+   0x2c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad11.gpmc_ad11 */
+   0x30 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad12.gpmc_ad12 */
+   0x34 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad13.gpmc_ad13 */
+   0x38 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad14.gpmc_ad14 */
+   0x3c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad15.gpmc_ad15 */
+
+   0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_wait0.gpmc_wait0 */
+   0x7c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn0.gpmc_csn0 */
+   0x80 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn1.gpmc_csn1 */
+   0x84 (PIN_OUTPUT | MUX_MODE0

Re: PCF857x and 16-bit GPIO expanders

[Mark Jackson]

On 19/09/13 13:20, George Cherian wrote:
 On 9/19/2013 5:37 PM, Nishanth Menon wrote:
 On 09/19/2013 03:13 AM, George Cherian wrote:
 On 9/18/2013 11:06 PM, Felipe Balbi wrote:
 Hi,

 On Wed, Sep 18, 2013 at 07:18:04PM +0200, Laurent Pinchart wrote:
 On Wednesday 18 September 2013 13:16:27 Linus Walleij wrote:
 On Tue, Sep 17, 2013 at 9:07 PM, Felipe Balbi ba...@ti.com wrote:
 has anyone ever successfully using gpio-pcf857x.c driver with 16-bit
 gpio expanders ? We're having some issues here where toggling the last
 gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I
 can't come up with any explanation of why would it hang...
 Bouncing the question to George, Laurent and Kuninori...
 I've got a board with a PCF8575 chip, but it uses I/Os 8 to 14 only as 
 far as
 I know.

 I can try toggling I/O 15, but that will need to wait until next week as 
 I'm
 currently travelling without access to the hardware.
 alright, that'd help me a lot :-) Just want to make sure if we're having
 a board issue, or PCF8575 is a bit screwy ;-)
 Is it on dra7x-evm if so which pcf device (i2c address)?
 The pins i were interested were only 1 and 2 I never tried pin 15.

 Just tried toggling through sysfs and it works for me.
 When I look at the data sheet for PCF8575[1] Page 7, Figure 4 Write
 mode (output)
 I see the data writes are of the order:
 I2c 1's byte: address
 I2c 2'nd byte:P[7-0]
 I2c 3rd byte:P[17-10]
 
 I read it as an octal numbering.

Kind of ... looking at the pinout, you have pins:-

P00...P07
P10...P17

So that's Port 0, bits 0..7, and Port 1, bits 0..7.

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA resources

[Mark Jackson]

On 23/08/13 20:53, Joel Fernandes wrote:
 HWMOD removal for MMC and Crypto is breaking edma_start as the events are
 being manually triggered due to unused channel list not being clear. Atleast
 breakage has been seen on these peripherals, but it is expected Audio (McASP)
 maybe breaking too.
 
 This patch fixes the issue, by reading the dmas property from the DT node if
 it exists and clearing the bits in the unused channel list so that these 
 channels
 are not manually triggered.
 
 v2 changes:
 Reduced indendation by returning from if block.
 
 Reviewed-by: Sekhar Nori nsek...@ti.com
 Reported-by: Balaji T K balaj...@ti.com
 Cc: Pantel Antoniou pa...@antoniou-consulting.com
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
 Note:
 Patch should go in for -rc cycle as it fixes existing crypto drivers.
 
  arch/arm/common/edma.c | 22 +++---
  1 file changed, 19 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
 index 39ad030..3867e7e 100644
 --- a/arch/arm/common/edma.c
 +++ b/arch/arm/common/edma.c
 @@ -560,14 +560,30 @@ static int reserve_contiguous_slots(int ctlr, unsigned 
 int id,
  static int prepare_unused_channel_list(struct device *dev, void *data)
  {
   struct platform_device *pdev = to_platform_device(dev);
 - int i, ctlr;
 + int i = 0, ctlr;
 + u32 dma_chan;
 + const __be32 *dma_chan_p;
 + struct property *prop;
 +
 + if (dev-of_node) {
 + of_property_for_each_u32(dev-of_node, dmas, prop,
 +  dma_chan_p, dma_chan) {
 + if (i++  1) {
 + ctlr = EDMA_CTLR(dma_chan);
 + clear_bit(EDMA_CHAN_SLOT(dma_chan),
 +   edma_cc[ctlr]-edma_unused);
 + }
 + }
 + return;

This should return something here, otherwise we get:-

arch/arm/common/edma.c: In function 'prepare_unused_channel_list':
arch/arm/common/edma.c:577:3: warning: 'return' with no value, in function 
returning non-void [-Wreturn-type]

Mark J.

 + }
  
 - for (i = 0; i  pdev-num_resources; i++) {
 + /* For non-OF case */
 + for (; i  pdev-num_resources; i++) {
   if ((pdev-resource[i].flags  IORESOURCE_DMA) 
   (int)pdev-resource[i].start = 0) {
   ctlr = EDMA_CTLR(pdev-resource[i].start);
   clear_bit(EDMA_CHAN_SLOT(pdev-resource[i].start),
 - edma_cc[ctlr]-edma_unused);
 +   edma_cc[ctlr]-edma_unused);
   }
   }

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA resources

[Mark Jackson]

On 06/09/13 20:13, Mark Jackson wrote:
 On 23/08/13 20:53, Joel Fernandes wrote:
 HWMOD removal for MMC and Crypto is breaking edma_start as the events are
 being manually triggered due to unused channel list not being clear. Atleast
 breakage has been seen on these peripherals, but it is expected Audio (McASP)
 maybe breaking too.

 This patch fixes the issue, by reading the dmas property from the DT node 
 if
 it exists and clearing the bits in the unused channel list so that these 
 channels
 are not manually triggered.

 v2 changes:
 Reduced indendation by returning from if block.

 Reviewed-by: Sekhar Nori nsek...@ti.com
 Reported-by: Balaji T K balaj...@ti.com
 Cc: Pantel Antoniou pa...@antoniou-consulting.com
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
 Note:
 Patch should go in for -rc cycle as it fixes existing crypto drivers.

  arch/arm/common/edma.c | 22 +++---
  1 file changed, 19 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
 index 39ad030..3867e7e 100644
 --- a/arch/arm/common/edma.c
 +++ b/arch/arm/common/edma.c
 @@ -560,14 +560,30 @@ static int reserve_contiguous_slots(int ctlr, unsigned 
 int id,
  static int prepare_unused_channel_list(struct device *dev, void *data)
  {
  struct platform_device *pdev = to_platform_device(dev);
 -int i, ctlr;
 +int i = 0, ctlr;
 +u32 dma_chan;
 +const __be32 *dma_chan_p;
 +struct property *prop;
 +
 +if (dev-of_node) {
 +of_property_for_each_u32(dev-of_node, dmas, prop,
 + dma_chan_p, dma_chan) {
 +if (i++  1) {
 +ctlr = EDMA_CTLR(dma_chan);
 +clear_bit(EDMA_CHAN_SLOT(dma_chan),
 +  edma_cc[ctlr]-edma_unused);
 +}
 +}
 +return;
 
 This should return something here, otherwise we get:-
 
 arch/arm/common/edma.c: In function 'prepare_unused_channel_list':
 arch/arm/common/edma.c:577:3: warning: 'return' with no value, in function 
 returning non-void [-Wreturn-type]

Other than that I can confirm it fixes the issue for me ...

Tested-by: Mark Jackson m...@newflow.co.uk

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Add support for Newflow NanoBone board

[Mark Jackson]

On 11/08/13 14:25, Mark Jackson wrote:
 NanoBone Specification:
 ---
 CPU:
   TI AM335x
 
 Memory:
   256MB DDR3
   128MB NOR flash
   128KB FRAM
 
 Ethernet:
   2 x 10/100 connected to SMSC LAN8710 PHY
 
 USB:
   1 x USB2.0 Type A
 
 I2C:
   2Kbit EEPROM (Microchip 24AA02)
   RTC (Maxim DS1338)
   GPIO Expander (Microchip MCP23017)
 
 Expansion connector:
   6 x UART
   1 x MMC/SD
   1 x USB2.0
 
 Signed-off-by: Mark Jackson m...@newflow.co.uk
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Any comments on this patch set ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] OMAP: serial: Remove incorrect disabling of IER interrupt

[Mark Jackson]

The recent patch to add RS485 contained a bug whereby the IER
interrupt was cleared down incorrectly.

This patch fixes the problem.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 drivers/tty/serial/omap-serial.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 2706c11..2fa7b5c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1327,9 +1327,6 @@ serial_omap_config_rs485(struct uart_port *port, struct 
serial_rs485 *rs485conf)
pm_runtime_get_sync(up-dev);
spin_lock_irqsave(up-port.lock, flags);
 
-   up-ier = ~(UART_IER_RLSI | UART_IER_RDI);
-   serial_out(up, UART_IER, up-ier);
-
/* Disable interrupts from this port */
mode = up-ier;
up-ier = 0;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] OMAP: allow GPIO pin to enable/disable external UART driver chip.

[Mark Jackson]

On 13/08/13 21:12, Andrew Ruder wrote:
 Sorry for the late reply, I've been thinking about this for some time
 and was sad to see it didn't really evoke any sort of discussion :(.
 
 On Sat, Aug 10, 2013 at 02:58:08PM +0100, Mark Jackson wrote:
 When a UART transmitter is connected to (eg) a RS485 driver, it is
 necessary to turn the driver on/off as quickly as possible.  This is
 best achieved in the serial driver itself (rather than in userspace
 where the latency can be quite large).

 This patch allows the GPIO pin to be defined (via DT) that controls
 the enabling of the driver at the start of a message, and disables
 the driver when the message has been completed.

 Still to do:-
 Allow userspace to turn this feature on/off
 Do the same for the receiver (useful for 2 wire RS485)
 
 I've been wondering about this as well but I have a slightly different
 situation.  On my board the RTS line controls the RS485 transmit/receive
 direction.
 
 I don't know if you've found the Documentation/serial/serial-rs485.txt
 file but it describes, at the very least, a standard API For controlling
 several parameters related to RS485 including configurable delay between
 rts-start of data/end of data-rts.  Unfortunately it seems like only
 one driver really implements the full API (Atmel AT91) and I guess it
 needs to be bolted onto each serial driver individually (although it
 seems like a fairly general concept that could be handled at another
 level).
 
 That being said, maybe this patch would better be rethought as a way to
 specify a GPIO for the RTS line (I don't know enough about OMAP and
 whether or not it already provides for hardware flow control in its
 builtin UARTs and you just aren't using it for RS485 flow control?) and
 then in a separate patch implement this already documented user-kernel
 API?

I've actually submitted a newer version that does support the documented
API.  See http://permalink.gmane.org/gmane.linux.ports.arm.omap/102765

Does this address some of your questions ?

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] OMAP: add RS485 support

[Mark Jackson]

This patch adds RS485 support to the OMAP serial driver, as
defined in:-

Documentation/devicetree/bindings/serial/rs485.txt

When a UART transmitter is connected to (eg) a RS485 driver, it is
necessary to turn the driver on/off as quickly as possible.  This is
best achieved in the serial driver itself (rather than in userspace
where the latency can be quite large).

This patch allows a GPIO pin to be defined (via DT) that controls
the enabling of the driver at the start of a message, and disables
the driver when the message has been completed.

When RS485 is disabled, the RTS pin is set to on.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
Changes in v2:
- Rebased against Greg KH's tty-next

Changes in v2:
- Fix incorrect logic in serial_omap_config_rs485()

 drivers/tty/serial/omap-serial.c |  179 ++
 1 file changed, 179 insertions(+)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c751706..2706c11 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -40,8 +40,11 @@
 #include linux/pm_runtime.h
 #include linux/of.h
 #include linux/gpio.h
+#include linux/of_gpio.h
 #include linux/platform_data/serial-omap.h
 
+#include dt-bindings/gpio/gpio.h
+
 #define OMAP_MAX_HSUART_PORTS  6
 
 #define UART_BUILD_REVISION(x, y)  (((x)  8) | (y))
@@ -162,6 +165,9 @@ struct uart_omap_port {
int DTR_inverted;
int DTR_active;
 
+   struct serial_rs485 rs485;
+   int rts_gpio;
+
struct pm_qos_request   pm_qos_request;
u32 latency;
u32 calc_latency;
@@ -277,13 +283,42 @@ static void serial_omap_enable_ms(struct uart_port *port)
 static void serial_omap_stop_tx(struct uart_port *port)
 {
struct uart_omap_port *up = to_uart_omap_port(port);
+   struct circ_buf *xmit = up-port.state-xmit;
+   int res;
 
pm_runtime_get_sync(up-dev);
+
+   /* handle rs485 */
+   if (up-rs485.flags  SER_RS485_ENABLED) {
+   /* do nothing if current tx not yet completed */
+   res = serial_in(up, UART_LSR)  UART_LSR_TEMT;
+   if (!res)
+   return;
+
+   /* if there's no more data to send, turn off rts */
+   if (uart_circ_empty(xmit)) {
+   /* if rts not already disabled */
+   res = (up-rs485.flags  SER_RS485_RTS_AFTER_SEND) ? 1 
: 0;
+   if (gpio_get_value(up-rts_gpio) != res) {
+   if (up-rs485.delay_rts_after_send  0) {
+   mdelay(up-rs485.delay_rts_after_send);
+   }
+   gpio_set_value(up-rts_gpio, res);
+   }
+   }
+   }
+
if (up-ier  UART_IER_THRI) {
up-ier = ~UART_IER_THRI;
serial_out(up, UART_IER, up-ier);
}
 
+   if ((up-rs485.flags  SER_RS485_ENABLED) 
+   !(up-rs485.flags  SER_RS485_RX_DURING_TX)) {
+   up-ier = UART_IER_RLSI | UART_IER_RDI;
+   serial_out(up, UART_IER, up-ier);
+   }
+
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
 }
@@ -346,8 +381,26 @@ static inline void serial_omap_enable_ier_thri(struct 
uart_omap_port *up)
 static void serial_omap_start_tx(struct uart_port *port)
 {
struct uart_omap_port *up = to_uart_omap_port(port);
+   int res;
 
pm_runtime_get_sync(up-dev);
+
+   /* handle rs485 */
+   if (up-rs485.flags  SER_RS485_ENABLED) {
+   /* if rts not already enabled */
+   res = (up-rs485.flags  SER_RS485_RTS_ON_SEND) ? 1 : 0;
+   if (gpio_get_value(up-rts_gpio) != res) {
+   gpio_set_value(up-rts_gpio, res);
+   if (up-rs485.delay_rts_before_send  0) {
+   mdelay(up-rs485.delay_rts_before_send);
+   }
+   }
+   }
+
+   if ((up-rs485.flags  SER_RS485_ENABLED) 
+   !(up-rs485.flags  SER_RS485_RX_DURING_TX))
+   serial_omap_stop_rx(port);
+
serial_omap_enable_ier_thri(up);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
@@ -1262,6 +1315,79 @@ static inline void serial_omap_add_console_port(struct 
uart_omap_port *up)
 
 #endif
 
+/* Enable or disable the rs485 support */
+static void
+serial_omap_config_rs485(struct uart_port *port, struct serial_rs485 
*rs485conf)
+{
+   struct uart_omap_port *up = to_uart_omap_port(port);
+   unsigned long flags;
+   unsigned int mode;
+   int val;
+
+   pm_runtime_get_sync(up-dev);
+   spin_lock_irqsave(up-port.lock, flags);
+
+   up-ier = ~(UART_IER_RLSI | UART_IER_RDI);
+   serial_out(up, UART_IER

Re: [PATCH v2] serial: OMAP: add RS485 support

[Mark Jackson]

On 12/08/13 23:56, Greg KH wrote:
 On Sun, Aug 11, 2013 at 02:56:50PM +0100, Mark Jackson wrote:
 This patch adds RS485 support to the OMAP serial driver, as
 defined in:-

 Documentation/devicetree/bindings/serial/rs485.txt

 When a UART transmitter is connected to (eg) a RS485 driver, it is
 necessary to turn the driver on/off as quickly as possible.  This is
 best achieved in the serial driver itself (rather than in userspace
 where the latency can be quite large).

 This patch allows a GPIO pin to be defined (via DT) that controls
 the enabling of the driver at the start of a message, and disables
 the driver when the message has been completed.

 When RS485 is disabled, the RTS pin is set to on.

 Signed-off-by: Mark Jackson m...@newflow.co.uk
 ---
 Changes in v2:
 - Fix incorrect logic in serial_omap_config_rs485()

  drivers/tty/serial/omap-serial.c |  178 
 ++
  1 file changed, 178 insertions(+)
 
 This doesn't apply to my tty-next branch:
   checking file drivers/tty/serial/omap-serial.c
   Hunk #1 FAILED at 40.
   Hunk #2 succeeded at 162 (offset 6 lines).
   Hunk #3 succeeded at 280 (offset 5 lines).
   Hunk #4 succeeded at 378 (offset 6 lines).
   Hunk #5 succeeded at 1312 (offset 8 lines).
   Hunk #6 succeeded at 1405 (offset 8 lines).
   Hunk #7 succeeded at 1528 (offset 10 lines).
   Hunk #8 FAILED at 1638.
   Hunk #9 succeeded at 1705 (offset 6 lines).
   2 out of 9 hunks FAILED
 
 so I can't apply it, sorry.

It was applied on top of Linus' tree, if that makes any difference.

I'll rebase onto yours and re-post the patch.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] serial: OMAP: add RS485 support

[Mark Jackson]

On 13/08/13 11:54, Javier Martinez Canillas wrote:

snip

 
 Hi Mark,
 
 I've seen several attempts to add RS485 support to the omap serial
 driver and it is always nack-ed. There seems to be concerns about
 controlling the RTS by software when RS485 is not supported by the
 UART hardware. Please refer to [1] and [2] for more information.

H ... okay, I guess I'll just have to maintain our own code (as
did the OP in [1]).

Thanks for the info.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add support for Newflow NanoBone board

[Mark Jackson]

On 08/07/13 19:57, Mark Jackson wrote:
 NanoBone Specification:
 ---
 CPU:
   TI AM335x @ 720MHz
 
 Memory:
   256MB DDR3
   128MB NOR flash
   128KB FRAM
 
 Ethernet:
   2 x 10/100 connected to SMSC LAN8710 PHY
 
 USB:
   1 x USB2.0 Type A
 
 I2C:
   2Kbit EEPROM (Microchip 24AA02)
   RTC (Maxim DS1338)
   GPIO Expander (Microchip MCP23017)
 
 Expansion connector:
   6 x UART
   1 x MMC/SD
   1 x USB2.0
 
 Signed-off-by: Mark Jackson m...@newflow.co.uk
 ---
  MAINTAINERS   |6 +
  arch/arm/boot/dts/Makefile|1 +
  arch/arm/boot/dts/am335x-nano.dts |  388 
 +
  3 files changed, 395 insertions(+)
  create mode 100644 arch/arm/boot/dts/am335x-nano.dts

Any comments on this new board file ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] OMAP: add RS485 support

[Mark Jackson]

This patch adds RS485 support to the OMAP serial driver, as
defined in:-

Documentation/devicetree/bindings/serial/rs485.txt

When a UART transmitter is connected to (eg) a RS485 driver, it is
necessary to turn the driver on/off as quickly as possible.  This is
best achieved in the serial driver itself (rather than in userspace
where the latency can be quite large).

This patch allows a GPIO pin to be defined (via DT) that controls
the enabling of the driver at the start of a message, and disables
the driver when the message has been completed.

When RS485 is disabled, the RTS pin is set to on.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 drivers/tty/serial/omap-serial.c |  177 ++
 1 file changed, 177 insertions(+)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b6d1728..a1d8d47 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -40,9 +40,12 @@
 #include linux/pm_runtime.h
 #include linux/of.h
 #include linux/gpio.h
+#include linux/of_gpio.h
 #include linux/pinctrl/consumer.h
 #include linux/platform_data/serial-omap.h
 
+#include dt-bindings/gpio/gpio.h
+
 #define OMAP_MAX_HSUART_PORTS  6
 
 #define UART_BUILD_REVISION(x, y)  (((x)  8) | (y))
@@ -156,6 +159,9 @@ struct uart_omap_port {
int DTR_inverted;
int DTR_active;
 
+   struct serial_rs485 rs485;
+   int rts_gpio;
+
struct pm_qos_request   pm_qos_request;
u32 latency;
u32 calc_latency;
@@ -272,13 +278,42 @@ static void serial_omap_enable_ms(struct uart_port *port)
 static void serial_omap_stop_tx(struct uart_port *port)
 {
struct uart_omap_port *up = to_uart_omap_port(port);
+   struct circ_buf *xmit = up-port.state-xmit;
+   int res;
 
pm_runtime_get_sync(up-dev);
+
+   /* handle rs485 */
+   if (up-rs485.flags  SER_RS485_ENABLED) {
+   /* do nothing if current tx not yet completed */
+   res = serial_in(up, UART_LSR)  UART_LSR_TEMT;
+   if (!res)
+   return;
+
+   /* if there's no more data to send, turn off rts */
+   if (uart_circ_empty(xmit)) {
+   /* if rts not already disabled */
+   res = (up-rs485.flags  SER_RS485_RTS_AFTER_SEND) ? 1 
: 0;
+   if (gpio_get_value(up-rts_gpio) != res) {
+   if (up-rs485.delay_rts_after_send  0) {
+   mdelay(up-rs485.delay_rts_after_send);
+   }
+   gpio_set_value(up-rts_gpio, res);
+   }
+   }
+   }
+
if (up-ier  UART_IER_THRI) {
up-ier = ~UART_IER_THRI;
serial_out(up, UART_IER, up-ier);
}
 
+   if ((up-rs485.flags  SER_RS485_ENABLED) 
+   !(up-rs485.flags  SER_RS485_RX_DURING_TX)) {
+   up-ier = UART_IER_RLSI | UART_IER_RDI;
+   serial_out(up, UART_IER, up-ier);
+   }
+
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
 }
@@ -340,8 +375,26 @@ static inline void serial_omap_enable_ier_thri(struct 
uart_omap_port *up)
 static void serial_omap_start_tx(struct uart_port *port)
 {
struct uart_omap_port *up = to_uart_omap_port(port);
+   int res;
 
pm_runtime_get_sync(up-dev);
+
+   /* handle rs485 */
+   if (up-rs485.flags  SER_RS485_ENABLED) {
+   /* if rts not already enabled */
+   res = (up-rs485.flags  SER_RS485_RTS_ON_SEND) ? 1 : 0;
+   if (gpio_get_value(up-rts_gpio) != res) {
+   gpio_set_value(up-rts_gpio, res);
+   if (up-rs485.delay_rts_before_send  0) {
+   mdelay(up-rs485.delay_rts_before_send);
+   }
+   }
+   }
+
+   if ((up-rs485.flags  SER_RS485_ENABLED) 
+   !(up-rs485.flags  SER_RS485_RX_DURING_TX))
+   serial_omap_stop_rx(port);
+
serial_omap_enable_ier_thri(up);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
@@ -1254,6 +1307,77 @@ static inline void serial_omap_add_console_port(struct 
uart_omap_port *up)
 
 #endif
 
+/* Enable or disable the rs485 support */
+static void
+serial_omap_config_rs485(struct uart_port *port, struct serial_rs485 
*rs485conf)
+{
+   struct uart_omap_port *up = to_uart_omap_port(port);
+   unsigned long flags;
+   unsigned int mode;
+   int val;
+
+   pm_runtime_get_sync(up-dev);
+   spin_lock_irqsave(up-port.lock, flags);
+
+   up-ier = ~(UART_IER_RLSI | UART_IER_RDI);
+   serial_out(up, UART_IER, up-ier);
+
+   /* Disable interrupts from this port */
+   mode = up-ier

[PATCH v2] Add support for Newflow NanoBone board

[Mark Jackson]

NanoBone Specification:
---
CPU:
  TI AM335x

Memory:
  256MB DDR3
  128MB NOR flash
  128KB FRAM

Ethernet:
  2 x 10/100 connected to SMSC LAN8710 PHY

USB:
  1 x USB2.0 Type A

I2C:
  2Kbit EEPROM (Microchip 24AA02)
  RTC (Maxim DS1338)
  GPIO Expander (Microchip MCP23017)

Expansion connector:
  6 x UART
  1 x MMC/SD
  1 x USB2.0

Signed-off-by: Mark Jackson m...@newflow.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes in v2:
- Reworked to use existing device nodes as suggested by Javier

 MAINTAINERS   |6 +
 arch/arm/boot/dts/Makefile|1 +
 arch/arm/boot/dts/am335x-nano.dts |  401 +
 3 files changed, 408 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-nano.dts

diff --git a/MAINTAINERS b/MAINTAINERS
index 9705318..7549e99 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5998,6 +5998,12 @@ L:   linux-omap@vger.kernel.org
 S: Maintained
 F: drivers/gpio/gpio-omap.c
 
+OMAP/NEWFLOW NANOBONE MACHINE SUPPORT
+M: Mark Jackson m...@newflow.co.uk
+L: linux-omap@vger.kernel.org
+S: Maintained
+F: arch/arm/boot/dts/am335x-nano.dts
+
 OMFS FILESYSTEM
 M: Bob Copeland m...@bobcopeland.com
 L: linux-karma-de...@lists.sourceforge.net
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..0d99a55 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
+   am335x-nano.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb
diff --git a/arch/arm/boot/dts/am335x-nano.dts 
b/arch/arm/boot/dts/am335x-nano.dts
new file mode 100644
index 000..a8014ee
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -0,0 +1,401 @@
+/*
+ * Copyright (C) 2013 Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+   model = Newflow AM335x NanoBone;
+   compatible = ti,am33xx;
+
+   cpus {
+   cpu@0 {
+   cpu0-supply = dcdc2_reg;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x1000; /* 256 MB */
+   };
+
+   leds {
+   compatible = gpio-leds;
+
+   led@0 {
+   label = nanobone:green:usr1;
+   gpios = gpio1 5 0;
+   default-state = off;
+   };
+   };
+};
+
+am33xx_pinmux {
+   pinctrl-names = default;
+   pinctrl-0 = misc_pins;
+
+   misc_pins: misc_pins {
+   pinctrl-single,pins = 
+   0x15c (PIN_OUTPUT | MUX_MODE7)  /* spi0_cs0.gpio0_5 */
+   ;
+   };
+
+   gpmc_pins: gpmc_pins {
+   pinctrl-single,pins = 
+   0x0 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad0.gpmc_ad0 */
+   0x4 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad1.gpmc_ad1 */
+   0x8 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad2.gpmc_ad2 */
+   0xc (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad3.gpmc_ad3 */
+   0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad4.gpmc_ad4 */
+   0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad5.gpmc_ad5 */
+   0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad6.gpmc_ad6 */
+   0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad7.gpmc_ad7 */
+   0x20 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad8.gpmc_ad8 */
+   0x24 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad9.gpmc_ad9 */
+   0x28 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad10.gpmc_ad10 */
+   0x2c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad11.gpmc_ad11 */
+   0x30 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad12.gpmc_ad12 */
+   0x34 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad13.gpmc_ad13 */
+   0x38 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad14.gpmc_ad14 */
+   0x3c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad15.gpmc_ad15 */
+
+   0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_wait0.gpmc_wait0 */
+   0x7c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn0.gpmc_csn0 */
+   0x80 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn1.gpmc_csn1 */
+   0x84 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn2.gpmc_csn2 */
+   0x88

[PATCH v2] OMAP: add RS485 support

[Mark Jackson]

This patch adds RS485 support to the OMAP serial driver, as
defined in:-

Documentation/devicetree/bindings/serial/rs485.txt

When a UART transmitter is connected to (eg) a RS485 driver, it is
necessary to turn the driver on/off as quickly as possible.  This is
best achieved in the serial driver itself (rather than in userspace
where the latency can be quite large).

This patch allows a GPIO pin to be defined (via DT) that controls
the enabling of the driver at the start of a message, and disables
the driver when the message has been completed.

When RS485 is disabled, the RTS pin is set to on.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
Changes in v2:
- Fix incorrect logic in serial_omap_config_rs485()

 drivers/tty/serial/omap-serial.c |  178 ++
 1 file changed, 178 insertions(+)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b6d1728..d538329 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -40,9 +40,12 @@
 #include linux/pm_runtime.h
 #include linux/of.h
 #include linux/gpio.h
+#include linux/of_gpio.h
 #include linux/pinctrl/consumer.h
 #include linux/platform_data/serial-omap.h
 
+#include dt-bindings/gpio/gpio.h
+
 #define OMAP_MAX_HSUART_PORTS  6
 
 #define UART_BUILD_REVISION(x, y)  (((x)  8) | (y))
@@ -156,6 +159,9 @@ struct uart_omap_port {
int DTR_inverted;
int DTR_active;
 
+   struct serial_rs485 rs485;
+   int rts_gpio;
+
struct pm_qos_request   pm_qos_request;
u32 latency;
u32 calc_latency;
@@ -272,13 +278,42 @@ static void serial_omap_enable_ms(struct uart_port *port)
 static void serial_omap_stop_tx(struct uart_port *port)
 {
struct uart_omap_port *up = to_uart_omap_port(port);
+   struct circ_buf *xmit = up-port.state-xmit;
+   int res;
 
pm_runtime_get_sync(up-dev);
+
+   /* handle rs485 */
+   if (up-rs485.flags  SER_RS485_ENABLED) {
+   /* do nothing if current tx not yet completed */
+   res = serial_in(up, UART_LSR)  UART_LSR_TEMT;
+   if (!res)
+   return;
+
+   /* if there's no more data to send, turn off rts */
+   if (uart_circ_empty(xmit)) {
+   /* if rts not already disabled */
+   res = (up-rs485.flags  SER_RS485_RTS_AFTER_SEND) ? 1 
: 0;
+   if (gpio_get_value(up-rts_gpio) != res) {
+   if (up-rs485.delay_rts_after_send  0) {
+   mdelay(up-rs485.delay_rts_after_send);
+   }
+   gpio_set_value(up-rts_gpio, res);
+   }
+   }
+   }
+
if (up-ier  UART_IER_THRI) {
up-ier = ~UART_IER_THRI;
serial_out(up, UART_IER, up-ier);
}
 
+   if ((up-rs485.flags  SER_RS485_ENABLED) 
+   !(up-rs485.flags  SER_RS485_RX_DURING_TX)) {
+   up-ier = UART_IER_RLSI | UART_IER_RDI;
+   serial_out(up, UART_IER, up-ier);
+   }
+
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
 }
@@ -340,8 +375,26 @@ static inline void serial_omap_enable_ier_thri(struct 
uart_omap_port *up)
 static void serial_omap_start_tx(struct uart_port *port)
 {
struct uart_omap_port *up = to_uart_omap_port(port);
+   int res;
 
pm_runtime_get_sync(up-dev);
+
+   /* handle rs485 */
+   if (up-rs485.flags  SER_RS485_ENABLED) {
+   /* if rts not already enabled */
+   res = (up-rs485.flags  SER_RS485_RTS_ON_SEND) ? 1 : 0;
+   if (gpio_get_value(up-rts_gpio) != res) {
+   gpio_set_value(up-rts_gpio, res);
+   if (up-rs485.delay_rts_before_send  0) {
+   mdelay(up-rs485.delay_rts_before_send);
+   }
+   }
+   }
+
+   if ((up-rs485.flags  SER_RS485_ENABLED) 
+   !(up-rs485.flags  SER_RS485_RX_DURING_TX))
+   serial_omap_stop_rx(port);
+
serial_omap_enable_ier_thri(up);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
@@ -1254,6 +1307,78 @@ static inline void serial_omap_add_console_port(struct 
uart_omap_port *up)
 
 #endif
 
+/* Enable or disable the rs485 support */
+static void
+serial_omap_config_rs485(struct uart_port *port, struct serial_rs485 
*rs485conf)
+{
+   struct uart_omap_port *up = to_uart_omap_port(port);
+   unsigned long flags;
+   unsigned int mode;
+   int val;
+
+   pm_runtime_get_sync(up-dev);
+   spin_lock_irqsave(up-port.lock, flags);
+
+   up-ier = ~(UART_IER_RLSI | UART_IER_RDI);
+   serial_out(up, UART_IER, up-ier

[RFC] OMAP: allow GPIO pin to enable/disable external UART driver chip.

[Mark Jackson]

When a UART transmitter is connected to (eg) a RS485 driver, it is
necessary to turn the driver on/off as quickly as possible.  This is
best achieved in the serial driver itself (rather than in userspace
where the latency can be quite large).

This patch allows the GPIO pin to be defined (via DT) that controls
the enabling of the driver at the start of a message, and disables
the driver when the message has been completed.

Still to do:-
Allow userspace to turn this feature on/off
Do the same for the receiver (useful for 2 wire RS485)

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 drivers/tty/serial/omap-serial.c |   57 ++
 1 file changed, 57 insertions(+)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b6d1728..1d3d117 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -40,9 +40,12 @@
 #include linux/pm_runtime.h
 #include linux/of.h
 #include linux/gpio.h
+#include linux/of_gpio.h
 #include linux/pinctrl/consumer.h
 #include linux/platform_data/serial-omap.h
 
+#include dt-bindings/gpio/gpio.h
+
 #define OMAP_MAX_HSUART_PORTS  6
 
 #define UART_BUILD_REVISION(x, y)  (((x)  8) | (y))
@@ -156,6 +159,10 @@ struct uart_omap_port {
int DTR_inverted;
int DTR_active;
 
+   int txen_gpio;
+   int txen_inverted;
+   int txen_active;
+
struct pm_qos_request   pm_qos_request;
u32 latency;
u32 calc_latency;
@@ -272,8 +279,25 @@ static void serial_omap_enable_ms(struct uart_port *port)
 static void serial_omap_stop_tx(struct uart_port *port)
 {
struct uart_omap_port *up = to_uart_omap_port(port);
+   struct circ_buf *xmit = up-port.state-xmit;
 
pm_runtime_get_sync(up-dev);
+
+   // if txen currently active
+   if (up-txen_active) {
+   // do nothing if current tx not yet completed
+   int res = serial_in(up, UART_LSR)  UART_LSR_TEMT;
+   if (!res)
+   return;
+
+   // if there's no more data to send, turn off txen
+   if (uart_circ_empty(xmit)) {
+   gpio_set_value(up-txen_gpio,
+  up-txen_active == 
up-txen_inverted);
+   up-txen_active = 0;
+   }
+   }
+
if (up-ier  UART_IER_THRI) {
up-ier = ~UART_IER_THRI;
serial_out(up, UART_IER, up-ier);
@@ -300,6 +324,16 @@ static void transmit_chars(struct uart_omap_port *up, 
unsigned int lsr)
struct circ_buf *xmit = up-port.state-xmit;
int count;
 
+   // if txen in use
+   if (gpio_is_valid(up-txen_gpio)) {
+   // turn on txen ?
+   if (!uart_circ_empty(xmit)  (!up-txen_active)) {
+   gpio_set_value(up-txen_gpio,
+  up-txen_active == up-txen_inverted);
+   up-txen_active = 1;
+   }
+   }
+
if (up-port.x_char) {
serial_out(up, UART_TX, up-port.x_char);
up-port.icount.tx++;
@@ -1468,6 +1502,28 @@ static int serial_omap_probe(struct platform_device 
*pdev)
goto err_port_line;
}
 
+   // init tx enable signal
+   up-txen_gpio = -EINVAL;
+   up-txen_inverted = 0;
+   up-txen_active = 0;
+   if (pdev-dev.of_node)
+   {
+   enum of_gpio_flags flags;
+   up-txen_gpio = of_get_named_gpio_flags(pdev-dev.of_node,
+   txen-gpio, 0, flags);
+   up-txen_inverted = (flags == GPIO_ACTIVE_LOW);
+   if (gpio_is_valid(up-txen_gpio)) {
+   ret = gpio_request(up-txen_gpio, omap-serial);
+   if (ret  0)
+   goto err_txen;
+   ret = gpio_direction_output(up-txen_gpio,
+   up-txen_inverted);
+   if (ret  0)
+   goto err_txen;
+   } else
+   up-txen_gpio = -EINVAL;
+   }
+
up-pins = devm_pinctrl_get_select_default(pdev-dev);
if (IS_ERR(up-pins)) {
dev_warn(pdev-dev, did not get pins for uart%i error: %li\n,
@@ -1529,6 +1585,7 @@ err_add_port:
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
 err_ioremap:
+err_txen:
 err_port_line:
dev_err(pdev-dev, [UART%d]: failure [%s]: %d\n,
pdev-id, __func__, ret);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ARM: AM335x: Reboot broken in 3.11

[Mark Jackson]

Rebooting appears to have broken in 3.11 (at some point before rc1).

Here is the console output:-

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.11.0-rc1-6-gf550793 (mpfj@mpfj-nanobone) 
(gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #328 Thu Aug 8 14:36:16 BST 2013
...
Welcome to Buildroot
nanobone login: root
Password:
# reboot
#
[   23.867076] UBIFS: background thread ubifs_bgt0_0 stops
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot
[   25.924496] reboot: Restarting system

... and at this point the CPU seems to just freeze.

In 3v10, the board would reboot correctly back into uboot, etc.

I've also noticed that some of the output LEDs light up dim when the kernel
is booting on, and they come on full brightness at the reboot freeze point.
There are 4 LEDs affected and they are all connected to UART transmit pins.

Before I start bisecting, does anyone have any ideas ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] OMAP2+: Fix boot hang with earlycon enabled

[Mark Jackson]

On 22/07/13 11:01, Rajendra Nayak wrote:
 Boot on all OMAP2+ devices is broken with earlycon enabled
 as discussed here [1]
 
 There were 2 issues which were rootcaused
 1. Issue caused due to hwmod doing a reset of console uart while
 earlycon was using it (seen only on am335x devices)
 
 2. omap serial causing a NULL context restore with context loss
 count missing.
 
 This patch set attempts to fix both the issues and is one of the
 different approaches discussed [1] on how to fix these issues.
 
 Boot tested on omap4 panda es with and without earlycon (DT boot)
 Boot tested on am335x bone black with and without earlycon (DT boot)
 Boot tested on OMAP3 beagle XM with and without earlycon (non-DT boot)
 
 [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg91662.html
 
 Grygorii Strashko (1):
   serial: omap: enable PM runtime only when its fully configured
 
 Rajendra Nayak (3):
   ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL
   ARM: OMAP2+: Avoid idling memory controllers with no drivers
   ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device
 state
 
  arch/arm/mach-omap2/omap_device.c  |   18 
  arch/arm/mach-omap2/omap_hwmod.h   |   48 
 
  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |6 +--
  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |2 +-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |9 ++--
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +-
  arch/arm/mach-omap2/omap_hwmod_54xx_data.c |3 +-
  arch/arm/mach-omap2/serial.c   |   11 -
  drivers/tty/serial/omap-serial.c   |3 +-
  9 files changed, 81 insertions(+), 24 deletions(-)
 
This now fixes the boot hang for me so ...

Tested-by: Mark Jackson mpfj-l...@newflow.co.uk

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM: AM335x: Kernel oops when using EDMA and MMC

[Mark Jackson]

On 17/07/13 17:38, Joel Fernandes wrote:
 On 07/17/2013 10:55 AM, Mark Jackson wrote:
 I'm trying to get the MMC port working on our custom AM3352 CPU board.

 I have added MMC entries to out dts file (similar to [1]), and I've
 enabled CONFIG_TI_EDMA.

 Our board boots fine without an SD card inserted ...

 [0.00] Booting Linux on physical CPU 0x0
 [0.00] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj@mpfj-nanobone) 
 (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 
 2013
 ...
 [2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12.
 [2.797268] devtmpfs: mounted
 [2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000)
 ...
 Welcome to Buildroot
 nanobone login:

 But when I boot with a card already inserted, I get the following oops ...

 ...
 [1.827343] Unable to handle kernel NULL pointer dereference at virtual 
 address 000c
 [1.835868] pgd = c0004000
 [1.838774] [000c] *pgd=
 [1.842556] Internal error: Oops: 5 [#1] ARM
 [1.847063] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 
 3.11.0-rc1-00025-g95b9b72 #309
 [1.855511] Workqueue: kmmcd mmc_rescan
 [1.859556] task: cf06a080 ti: cf072000 task.ti: cf072000
 [1.865257] PC is at omap_hsmmc_start_command+0x74/0xf4
 [1.870761] LR is at omap_hsmmc_request+0xec/0x4dc
 [1.875806] pc : [c0305b70]lr : [c0306c64]psr: 6113
 [1.875806] sp : cf073ca0  ip :   fp : 0008
 [1.887885] r10: cf073de8  r9 : 0001  r8 : cf11d918
 [1.893382] r7 : 0003  r6 : cf33cc80  r5 : 0001  r4 : 0033
 [1.900250] r3 : 0002  r2 : cf073db8  r1 : cf073d84  r0 : cf33cc80
 [1.907122] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
 kernel
 [1.914813] Control: 10c5387d  Table: 80004019  DAC: 0015
 [1.920859] Process kworker/u2:0 (pid: 6, stack limit = 0xcf072238)
 [1.927454] Stack: (0xcf073ca0 to 0xcf074000)
 [1.932048] 3ca0: cf33c800 cf073d40 0003  c0076a8c cf073d40 
 48060220 48060220
 [1.940659] 3cc0: 0004 0004 0002 0002 cf073ec8 c0421a9c 
 c051835c cf073d40
 [1.949271] 3ce0: cf33c800 0001 0008 0008 0002 cf073db8 
 cf073ec8 c02f0f28
 [1.957882] 3d00: 0200 0064  cf073db8 cf073ec8 cf073d40 
 cf073d50 
 [1.966493] 3d20: cf33c800 c02f18a4 cf369800 cf369a80  cf360880 
 0008 c02f9964
 [1.975104] 3d40:  cf073d84 cf073db8  0001 0001 
 dead4ead 
 [1.983717] 3d60:  c0af722c c06aa3e4  c04ddadc cf073d74 
 cf073d74 c02f0dc4
 [1.992327] 3d80:  0033     
  00b5
 [2.000938] 3da0:     cf073db8 cf073d40 
 05f5e100 
 [2.009548] 3dc0: 0008 0001  0200   
 cf073d40 0001
 [2.018159] 3de0: cf073de8  c0cf1c02 0880 0008 8f360880 
  cf369800
 [2.026771] 3e00: cf33c800  cf369800 cf073e4c cf072000 c02f8740 
  0015
 [2.035382] 3e20: 0003 cf33c800   cf369800 cf073e4c 
 cf072000 c02f8b20
 [2.043994] 3e40: 0002 c02f25cc 0002 02544d53 41303447 1026c914 
 2600bbbd c0ff8000
 [2.052605] 3e60: c0455884 cf33c800  c0455884 c0455890  
 cf072000 c02f92bc
 [2.061217] 3e80: c0455890 00ff8000 0002 cf33cb14 cf33c800 c02f3a28 
 cf041ac0 cf33cb14
 [2.069829] 3ea0: cf050c00 cf051c00  c00507ec 0002  
 c0050778 c0050f10
 [2.078441] 3ec0:   c0af7268 c06aa1c4  c0518cd0 
 cf06a080 cf041ac0
 [2.087054] 3ee0: cf050c00 cf072000 cf050c30 cf041ad8 0089 c05d7b5c 
 cf050c00 c0050e4c
 [2.095665] 3f00:  cf072000 6113 cf04dda8  cf041ac0 
 c0050d08 
 [2.104276] 3f20:    c0056c94 c0429a18  
 0001 cf041ac0
 [2.112888] 3f40:  0001 dead4ead   c05ec0a0 
  
 [2.121499] 3f60: c04ddadc cf073f64 cf073f64  0001 dead4ead 
  
 [2.130112] 3f80: c05ec0a0   c04ddadc cf073f90 cf073f90 
 cf073fac cf04dda8
 [2.138724] 3fa0: c0056bf0   c0013588   
  
 [2.147334] 3fc0:       
  
 [2.155946] 3fe0:     0013  
 57e0c5db 5ffb7d3c
 [2.164565] [c0305b70] (omap_hsmmc_start_command+0x74/0xf4) from 
 [0003] (0x3)
 [2.172814] Code: 13a03801 0a1b e590c008 e5914000 (e59cc00c)
 [2.179314] ---[ end trace 6ec9899a56aef6aa ]---

 I have also noticed that when the kernel boots okay (without a card 
 inserted), if
 I then insert a card, nothing happens (even with CONFIG_MMC_DEBUG=y) ... 
 including
 no kernel oops.

 Can anyone shed light on what's

Re: [PATCH v2] ARM: dts: add AM33XX MMC support

[Mark Jackson]

On 27/06/13 04:32, Joel Fernandes wrote:
 From: Matt Porter mpor...@ti.com
 
 Adds AM33XX MMC support for am335x-bone, am335x-evm, and am335x-evmsk.
 Also added is the DMA binding definitions based on the generic DMA
 request binding.
 
 The HWMOD data removal was breaking MMC so some new properties like reg,
 interrupt etc were added.
 
 Changes to DTS:
 Interrupt and reg added by: Joel Fernandes jo...@ti.com
 Compatible added by Balaji TK balaj...@ti.com
 ti,needs-special-hs-handling added by Gururaja Hebbar gururaja.heb...@ti.com
 
 Signed-off-by: Matt Porter mpor...@ti.com
 Acked-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   26 +-
  arch/arm/boot/dts/am335x-bone.dts  |7 
  arch/arm/boot/dts/am335x-evm.dts   |7 
  arch/arm/boot/dts/am335x-evmsk.dts |7 
  arch/arm/boot/dts/am33xx.dtsi  |   38 
 
  5 files changed, 84 insertions(+), 1 deletion(-)

Excuse my ignorance, but which git repository is this against ?

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ARM: AM335x: Kernel oops when using EDMA and MMC

[Mark Jackson]

I'm trying to get the MMC port working on our custom AM3352 CPU board.

I have added MMC entries to out dts file (similar to [1]), and I've
enabled CONFIG_TI_EDMA.

Our board boots fine without an SD card inserted ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj@mpfj-nanobone) 
(gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 2013
...
[2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12.
[2.797268] devtmpfs: mounted
[2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000)
...
Welcome to Buildroot
nanobone login:

But when I boot with a card already inserted, I get the following oops ...

...
[1.827343] Unable to handle kernel NULL pointer dereference at virtual 
address 000c
[1.835868] pgd = c0004000
[1.838774] [000c] *pgd=
[1.842556] Internal error: Oops: 5 [#1] ARM
[1.847063] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 
3.11.0-rc1-00025-g95b9b72 #309
[1.855511] Workqueue: kmmcd mmc_rescan
[1.859556] task: cf06a080 ti: cf072000 task.ti: cf072000
[1.865257] PC is at omap_hsmmc_start_command+0x74/0xf4
[1.870761] LR is at omap_hsmmc_request+0xec/0x4dc
[1.875806] pc : [c0305b70]lr : [c0306c64]psr: 6113
[1.875806] sp : cf073ca0  ip :   fp : 0008
[1.887885] r10: cf073de8  r9 : 0001  r8 : cf11d918
[1.893382] r7 : 0003  r6 : cf33cc80  r5 : 0001  r4 : 0033
[1.900250] r3 : 0002  r2 : cf073db8  r1 : cf073d84  r0 : cf33cc80
[1.907122] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[1.914813] Control: 10c5387d  Table: 80004019  DAC: 0015
[1.920859] Process kworker/u2:0 (pid: 6, stack limit = 0xcf072238)
[1.927454] Stack: (0xcf073ca0 to 0xcf074000)
[1.932048] 3ca0: cf33c800 cf073d40 0003  c0076a8c cf073d40 
48060220 48060220
[1.940659] 3cc0: 0004 0004 0002 0002 cf073ec8 c0421a9c 
c051835c cf073d40
[1.949271] 3ce0: cf33c800 0001 0008 0008 0002 cf073db8 
cf073ec8 c02f0f28
[1.957882] 3d00: 0200 0064  cf073db8 cf073ec8 cf073d40 
cf073d50 
[1.966493] 3d20: cf33c800 c02f18a4 cf369800 cf369a80  cf360880 
0008 c02f9964
[1.975104] 3d40:  cf073d84 cf073db8  0001 0001 
dead4ead 
[1.983717] 3d60:  c0af722c c06aa3e4  c04ddadc cf073d74 
cf073d74 c02f0dc4
[1.992327] 3d80:  0033     
 00b5
[2.000938] 3da0:     cf073db8 cf073d40 
05f5e100 
[2.009548] 3dc0: 0008 0001  0200   
cf073d40 0001
[2.018159] 3de0: cf073de8  c0cf1c02 0880 0008 8f360880 
 cf369800
[2.026771] 3e00: cf33c800  cf369800 cf073e4c cf072000 c02f8740 
 0015
[2.035382] 3e20: 0003 cf33c800   cf369800 cf073e4c 
cf072000 c02f8b20
[2.043994] 3e40: 0002 c02f25cc 0002 02544d53 41303447 1026c914 
2600bbbd c0ff8000
[2.052605] 3e60: c0455884 cf33c800  c0455884 c0455890  
cf072000 c02f92bc
[2.061217] 3e80: c0455890 00ff8000 0002 cf33cb14 cf33c800 c02f3a28 
cf041ac0 cf33cb14
[2.069829] 3ea0: cf050c00 cf051c00  c00507ec 0002  
c0050778 c0050f10
[2.078441] 3ec0:   c0af7268 c06aa1c4  c0518cd0 
cf06a080 cf041ac0
[2.087054] 3ee0: cf050c00 cf072000 cf050c30 cf041ad8 0089 c05d7b5c 
cf050c00 c0050e4c
[2.095665] 3f00:  cf072000 6113 cf04dda8  cf041ac0 
c0050d08 
[2.104276] 3f20:    c0056c94 c0429a18  
0001 cf041ac0
[2.112888] 3f40:  0001 dead4ead   c05ec0a0 
 
[2.121499] 3f60: c04ddadc cf073f64 cf073f64  0001 dead4ead 
 
[2.130112] 3f80: c05ec0a0   c04ddadc cf073f90 cf073f90 
cf073fac cf04dda8
[2.138724] 3fa0: c0056bf0   c0013588   
 
[2.147334] 3fc0:       
 
[2.155946] 3fe0:     0013  
57e0c5db 5ffb7d3c
[2.164565] [c0305b70] (omap_hsmmc_start_command+0x74/0xf4) from 
[0003] (0x3)
[2.172814] Code: 13a03801 0a1b e590c008 e5914000 (e59cc00c)
[2.179314] ---[ end trace 6ec9899a56aef6aa ]---

I have also noticed that when the kernel boots okay (without a card inserted), 
if
I then insert a card, nothing happens (even with CONFIG_MMC_DEBUG=y) ... 
including
no kernel oops.

Can anyone shed light on what's wrong ?

Cheers
Mark J.

[1] https://lkml.org/lkml/2013/6/25/784

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org

Re: ARM: AM335x: Kernel oops when using EDMA and MMC

[Mark Jackson]

On 17/07/13 16:55, Mark Jackson wrote:
 I'm trying to get the MMC port working on our custom AM3352 CPU board.
 
 I have added MMC entries to out dts file (similar to [1]), and I've
 enabled CONFIG_TI_EDMA.
 
 Our board boots fine without an SD card inserted ...
 
 [0.00] Booting Linux on physical CPU 0x0
 [0.00] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj@mpfj-nanobone) 
 (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 
 2013
 ...
 [2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12.
 [2.797268] devtmpfs: mounted
 [2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000)
 ...
 Welcome to Buildroot
 nanobone login:

I have just noticed the following in the boot log:-

...
[1.225698] omap_hsmmc 4806.mmc: unable to obtain RX DMA engine channel 
3227000204
...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remove vlan tags in CPSW dual emac mode

[Mark Jackson]

On 15/07/13 13:45, Mugunthan V N wrote:
 On 7/13/2013 12:55 AM, Mark Jackson wrote:
 On 12/07/13 19:35, Mugunthan V N wrote:
 On 7/12/2013 7:27 PM, Mark Jackson wrote:
 [snip]

 Just to update this (old) thread ...

 I can still confirm that *without* the above patch, I am *unable* to use 
 both network
 ports on our AM335x board.

 [snip]

 So I'm not sure what's wrong, but it's *definitely* not correct.


 I am sure that current code in mainline works for Dual EMAC. I can test it
 again and share the images with you if are interested. But had tested with 
 DHCP
 on both the interfaces.
 Hmmm ... well it's not working for me.  What hardware are you testing it on ?

 I tried DHCP to start with, and switched to static IP when that failed.
 Then I recalled this patch and re-applied it ... hey presto !!

 Markus, are you still using this patch ?

 Today I have tested the Dual EMAC on my am335x-evmsk and its working fine with
 net/master branch.
 I had 3 patches additional to net/master in which two for basic boot of EVMsk
 and one for enabling Dual EMAC. I had pushed the branch in the below repo
 repo:
 git://git.ti.com/~mugunthanvnm/ti-linux-kernel/mugunth-connectivity-linux-feature-tree.git
 branch: dual-emac

Okay ... I can't test that at the moment as I can only boot from MMC as there's
currently no support for MMC booting in the mainline kernel.

So ... the code works for you, but not for me.

I guess the other difference is that I'm not using the same PHY (we use a 10/100
SMSC 8710A, not the GbE Atheros part).

Could that make any difference ?

Markus, are you still seeing the same issue ?  What PHY are you using ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remove vlan tags in CPSW dual emac mode

[Mark Jackson]

On 23/04/13 18:29, Mugunthan V N wrote:
 On 4/23/2013 9:48 PM, Markus Brunner wrote:
 If operating in dual emac mode all packets sent by the CPSW contain vlan 
 headers with the reserved VID 0,
 which gets stripped away by all somewhat recent Linux versions. Operating 
 systems without that behaviour will fail to communicate.
 This patch fixes that behaviour by disabling the VLAN_AWARE mode as already 
 described by the comment above.

 Signed-off-by: Markus Brunner systemprogrammierung.brun...@gmail.com
 Tested-by: Mark Jackson m...@newflow.co.uk

 ---
 --- linux-3.9-rc8.orig/drivers/net/ethernet/ti/cpsw.c2013-04-23 
 17:26:11.0 +0200
 +++ linux-3.9-rc8/drivers/net/ethernet/ti/cpsw.c2013-04-23 
 17:36:25.0 +0200
 @@ -751,9 +751,9 @@ static void cpsw_init_host_port(struct c
   /* switch to vlan unaware mode */
   cpsw_ale_control_set(priv-ale, priv-host_port, ALE_VLAN_AWARE,
CPSW_ALE_VLAN_AWARE);
   control_reg = readl(priv-regs-control);
 -control_reg |= CPSW_VLAN_AWARE;
 +control_reg = ~CPSW_VLAN_AWARE;
   writel(control_reg, priv-regs-control);
   fifo_mode = (priv-data.dual_emac) ? CPSW_FIFO_DUAL_MAC_MODE :
CPSW_FIFO_NORMAL_MODE;
   writel(fifo_mode, priv-host_port_regs-tx_in_ctl);
 Disabling VLAN aware mode will enable switching mode and the feature of
 separating the two down stream port is lost with this patch
 Please check TRM for more info in *14.3.2.10.2 Dual Mac Mode* chapter

Just to update this (old) thread ...

I can still confirm that *without* the above patch, I am *unable* to use both 
network
ports on our AM335x board.

My .dts file contains:-

mac: ethernet@4a10 {
dual_emac = 1;

cpsw_emac0: slave@4a100200 {
dual_emac_res_vlan = 1;
};

cpsw_emac1: slave@4a100300 {
dual_emac_res_vlan = 2;
};
};

cpsw_emac0 {
phy_id = davinci_mdio, 0;
};

cpsw_emac1 {
phy_id = davinci_mdio, 1;
};

My /etc/network/interfaces file is:-

auto lo eth0 eth1
iface lo inet loopback
iface eth0 inet static
address 10.0.101.3
netmask 255.255.0.0
gateway 10.0.0.1
iface eth1 inet static
address 10.1.101.3
netmask 255.255.0.0

So I'm not sure what's wrong, but it's *definitely* not correct.

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt

[Mark Jackson]

On 08/07/13 13:42, Mark Jackson wrote:
 On 18/01/13 05:14, Mugunthan V N wrote:
 On 1/18/2013 3:48 AM, Peter Korsgaard wrote:
 When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
 U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
 mode in U-Boot), nothing updates the ethernet hwaddr specified for the
 CPSW slaves, causing the driver to use a random hwaddr, which is some times
 troublesome.

 The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
 more sense to default to these rather than random ones. Add a fixup step
 which adds mac-address dt properties using the efuse addresses if the DTB
 didn't contain valid ones.

 Signed-off-by: Peter Korsgaard jac...@sunsite.dk


 This implementation looks fine.
 Acked-by: Mugunthan V N mugunthan...@ti.com
 
 Tested-by: Mark Jackson mpfj-l...@newflow.co.uk

Is this ever going to be put into the mainline code ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remove vlan tags in CPSW dual emac mode

[Mark Jackson]

On 12/07/13 19:35, Mugunthan V N wrote:
 On 7/12/2013 7:27 PM, Mark Jackson wrote:

[snip]

 Just to update this (old) thread ...

 I can still confirm that *without* the above patch, I am *unable* to use 
 both network
 ports on our AM335x board.


[snip]


 So I'm not sure what's wrong, but it's *definitely* not correct.


 I am sure that current code in mainline works for Dual EMAC. I can test it
 again and share the images with you if are interested. But had tested with 
 DHCP
 on both the interfaces.

Hmmm ... well it's not working for me.  What hardware are you testing it on ?

I tried DHCP to start with, and switched to static IP when that failed.
Then I recalled this patch and re-applied it ... hey presto !!

Markus, are you still using this patch ?

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt

[Mark Jackson]

On 18/01/13 05:14, Mugunthan V N wrote:
 On 1/18/2013 3:48 AM, Peter Korsgaard wrote:
 When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
 U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
 mode in U-Boot), nothing updates the ethernet hwaddr specified for the
 CPSW slaves, causing the driver to use a random hwaddr, which is some times
 troublesome.

 The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
 more sense to default to these rather than random ones. Add a fixup step
 which adds mac-address dt properties using the efuse addresses if the DTB
 didn't contain valid ones.

 Signed-off-by: Peter Korsgaard jac...@sunsite.dk

 
 This implementation looks fine.
 Acked-by: Mugunthan V N mugunthan...@ti.com

Tested-by: Mark Jackson mpfj-l...@newflow.co.uk

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Add support for Newflow NanoBone board

[Mark Jackson]

NanoBone Specification:
---
CPU:
  TI AM335x @ 720MHz

Memory:
  256MB DDR3
  128MB NOR flash
  128KB FRAM

Ethernet:
  2 x 10/100 connected to SMSC LAN8710 PHY

USB:
  1 x USB2.0 Type A

I2C:
  2Kbit EEPROM (Microchip 24AA02)
  RTC (Maxim DS1338)
  GPIO Expander (Microchip MCP23017)

Expansion connector:
  6 x UART
  1 x MMC/SD
  1 x USB2.0

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 MAINTAINERS   |6 +
 arch/arm/boot/dts/Makefile|1 +
 arch/arm/boot/dts/am335x-nano.dts |  388 +
 3 files changed, 395 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-nano.dts

diff --git a/MAINTAINERS b/MAINTAINERS
index 97762ad..d4e0da0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5952,6 +5952,12 @@ L:   linux-omap@vger.kernel.org
 S: Maintained
 F: drivers/gpio/gpio-omap.c

+OMAP/NEWFLOW NANOBONE MACHINE SUPPORT
+M: Mark Jackson m...@newflow.co.uk
+L: linux-omap@vger.kernel.org
+S: Maintained
+F: arch/arm/boot/dts/am335x-nano.dts
+
 OMFS FILESYSTEM
 M: Bob Copeland m...@bobcopeland.com
 L: linux-karma-de...@lists.sourceforge.net
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..0d99a55 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
+   am335x-nano.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb
diff --git a/arch/arm/boot/dts/am335x-nano.dts 
b/arch/arm/boot/dts/am335x-nano.dts
new file mode 100644
index 000..82add9b
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -0,0 +1,388 @@
+/*
+ * Copyright (C) 2013 Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+   model = Newflow AM335x NanoBone;
+   compatible = ti,am33xx;
+
+   cpus {
+   cpu@0 {
+   cpu0-supply = dcdc2_reg;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x1000; /* 256 MB */
+   };
+
+   am33xx_pinmux: pinmux@44e10800 {
+   pinctrl-names = default;
+   pinctrl-0 = misc_pins;
+
+   misc_pins: misc_pins {
+   pinctrl-single,pins = 
+   0x15c (PIN_OUTPUT | MUX_MODE7)  /* 
spi0_cs0.gpio0_5 */
+   ;
+   };
+
+   gpmc_pins: gpmc_pins {
+   pinctrl-single,pins = 
+   0x0 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad0.gpmc_ad0 */
+   0x4 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad1.gpmc_ad1 */
+   0x8 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad2.gpmc_ad2 */
+   0xc (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad3.gpmc_ad3 */
+   0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad4.gpmc_ad4 */
+   0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad5.gpmc_ad5 */
+   0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad6.gpmc_ad6 */
+   0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad7.gpmc_ad7 */
+   0x20 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad8.gpmc_ad8 */
+   0x24 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad9.gpmc_ad9 */
+   0x28 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad10.gpmc_ad10 */
+   0x2c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad11.gpmc_ad11 */
+   0x30 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad12.gpmc_ad12 */
+   0x34 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad13.gpmc_ad13 */
+   0x38 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad14.gpmc_ad14 */
+   0x3c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad15.gpmc_ad15 */
+
+   0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_wait0.gpmc_wait0 */
+   0x7c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn0.gpmc_csn0 */
+   0x80 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn1.gpmc_csn1 */
+   0x84 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn2.gpmc_csn2 */
+   0x88 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn3.gpmc_csn3 */
+
+   0x90 (PIN_OUTPUT | MUX_MODE0

Re: Boot hang regression 3.10.0-rc4 - 3.10.0

[Mark Jackson]

On 04/07/13 14:25, Mark Jackson wrote:
 Our custom AM335x board has been booting just fine under 3.10.0-rc4.
 
 I've just done a git pull to update to 3.10 (now that it's released)
 and the board now hangs.
 
 Before I start trying to bisect the issue, does anyone have an clues ?

Okay ... I've now bisected it to:-

a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
commit a630fbfbb1beeffc5bbe542a7986bf2068874633
Author: Tony Lindgren t...@atomide.com
Date:   Mon Jun 10 07:39:09 2013 -0700

serial: omap: Fix device tree based PM runtime

In the runtime_suspend function pdata is not being used, and
also blocks the function in device tree based booting. Fix it
by removing the unused pdata from the runtime_suspend function.

Further, context loss count is not being passed in pdata, so
let's just reinitialize the port every time for those case.
This can be further optimized later on for the device tree
case by adding detection for the hardware state and possibly
by adding a driver specific autosuspend timeout.

And doing this, we can then make the related dev_err into a
dev_dbg message instead of an error.

In order for the wake-up events to work, we also need to set
autosuspend_timeout to -1 if 0, and also device_init_wakeup()
as that's not being done by the platform init code for the
device tree case.

Note that this does not affect legacy booting, and in fact
might make it work for the cases where the context loss info
is not being passed in pdata.

Thanks to Kevin Hilman khil...@linaro.org for debugging
and suggesting fixes for the autosuspend_timeout and
device_init_wakeup() related initializiation.

Reviewed-by: Kevin Hilman khil...@linaro.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

:04 04 38900a5a2ed6dfeb812d93bf1918725021298884 
a38d3dcd46276dc27b87157fd0b1e292804c M  drivers


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Boot hang regression 3.10.0-rc4 - 3.10.0

[Mark Jackson]

On 04/07/13 16:14, Mark Jackson wrote:
 On 04/07/13 14:25, Mark Jackson wrote:
 Our custom AM335x board has been booting just fine under 3.10.0-rc4.

 I've just done a git pull to update to 3.10 (now that it's released)
 and the board now hangs.

 Before I start trying to bisect the issue, does anyone have an clues ?
 
 Okay ... I've now bisected it to:-
 
 a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
 commit a630fbfbb1beeffc5bbe542a7986bf2068874633
 Author: Tony Lindgren t...@atomide.com
 Date:   Mon Jun 10 07:39:09 2013 -0700
 
 serial: omap: Fix device tree based PM runtime

However, reverting the commit does *not* fix the issue, weird !!

But I have now tested:-

v3.10-rc4 - works
v3.10-rc5 - works
v3.10-rc6 - works
v3.10-rc7 - works
v3.10 - works
origin/master - hangs

Any ideas ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

AM335x: is AUTORTS mode supported ?

[Mark Jackson]

I'm struggling to determine if AUTORTS mode is currently supported in 3.10 ?

I have dug into the source code, and can see various references to the relevant 
bits
in the various UART registers, but I'm at a lose as to how to actually *enable* 
the
mode !!

In drivers/tty/omap-serial.c serial_omap_set_termios() we have:-

if (termios-c_cflag  CRTSCTS  up-port.flags  UPF_HARD_FLOW) {
/* Enable AUTORTS and AUTOCTS */
up-efr |= UART_EFR_CTS | UART_EFR_RTS;

/* Ensure MCR RTS is asserted */
up-mcr |= UART_MCR_RTS;
} else {
...
}

So it looks like I need to set the CRTSCTS and UPF_HARD_FLOW flags.

From userspace, I've tried:-

$ stty -F /dev/ttyO2 crtscts

But I've not idea how to enable UPF_HARD_FLOW !?!

Can anyone point me in the right direction ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unable to find JFFS2 partition ... but I know it's there !!

[Mark Jackson]

On 20/06/13 10:31, Mark Jackson wrote:
 I'm struggling to debug an issue where the kernel is unable to
 find a JFFS2 partition held in NOR flash (on CS0)

Fixed ... I finally worked out I needed to add:-

CONFIG_MTD_BLOCK
CONFIG_MTD_BLOCK2MTD

Sorry for the noise.

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

v3.9.0-rc8 : oops in tick_do_update_jiffies64+0xbc/0x110

[Mark Jackson]

I've been experiencing several crashes all pointing exactly the same place in 
the same tick routine (see below).

The exception stack trace at the end changes depending on when the oops 
occurs.

I've had the oops occur maybe 6 times in the last 50 reboots.

Any ideas ?

Mark J.
---
[0.00] Booting Linux on physical CPU 0x0

[0.00] Linux version 3.9.0-rc8-00034-gb395e3d-dirty 
(mpfj@mpfj-nanobone) (gcc version 4.8.0 (Buildroot 2013.05-git-00527-gc24e66a) 
) #30 Sun Apr 28 19:00:18 BST 2013

[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d

[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache

[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow 
AM335x NanoBone

[0.00] debug: ignoring loglevel setting.

[0.00] Memory policy: ECC disabled, Data cache writeback

[0.00] On node 0 totalpages: 65280

[0.00] free_area_init_node: node 0, pgdat c0597040, node_mem_map 
c0ac1000

[0.00]   Normal zone: 512 pages used for memmap

[0.00]   Normal zone: 0 pages reserved

[0.00]   Normal zone: 65280 pages, LIFO batch:15

[0.00] CPU: All CPU(s) started in SVC mode.

[0.00] AM335X ES1.0 (neon )

[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768

[0.00] pcpu-alloc: [0] 0 

[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768

[0.00] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off 
mem=256M rootwait=1 ubi.mtd=7,2048 rootfstype=ubifs root=ubi0:rootfs 
ignore_loglevel

[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)

[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)

[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)

[0.00] __ex_table already sorted, skipping sort

[0.00] Memory: 255MB = 255MB total

[0.00] Memory: 247788k/247788k available, 14356k reserved, 0K highmem

[0.00] Virtual kernel memory layout:

[0.00] vector  : 0x - 0x1000   (   4 kB)

[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)

[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)

[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)

[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)

[0.00]   .text : 0xc0008000 - 0xc0513f0c   (5168 kB)

[0.00]   .init : 0xc0514000 - 0xc0545d24   ( 200 kB)

[0.00]   .data : 0xc0546000 - 0xc0597c20   ( 328 kB)

[0.00].bss : 0xc0597c20 - 0xc0abca50   (5268 kB)

[0.00] NR_IRQS:16 nr_irqs:16 16

[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 
interrupts

[0.00] Total of 128 interrupts on 1 active controller

[0.00] OMAP clockevent source: GPTIMER1 at 2600 Hz

[0.00] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 
165191ms

[0.00] OMAP clocksource: GPTIMER2 at 2600 Hz

[0.00] Console: colour dummy device 80x30

[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., 
Ingo Molnar

[0.00] ... MAX_LOCKDEP_SUBCLASSES:  8

[0.00] ... MAX_LOCK_DEPTH:  48

[0.00] ... MAX_LOCKDEP_KEYS:8191

[0.00] ... CLASSHASH_SIZE:  4096

[0.00] ... MAX_LOCKDEP_ENTRIES: 16384

[0.00] ... MAX_LOCKDEP_CHAINS:  32768

[0.00] ... CHAINHASH_SIZE:  16384

[0.00]  memory used by lock dependency info: 3695 kB

[0.00]  per task-struct memory footprint: 1152 bytes

[0.001049] Calibrating delay loop... 363.72 BogoMIPS (lpj=1818624)

[0.119700] pid_max: default: 32768 minimum: 301

[0.120058] Security Framework initialized

[0.120187] Mount-cache hash table entries: 512

[0.133586] CPU: Testing write buffer coherency: ok

[0.135069] Setting up static identity map for 0xc03fda80 - 0xc03fdad8

[0.139239] devtmpfs: initialized

[0.204075] pinctrl core: initialized pinctrl subsystem

[0.210660] regulator-dummy: no parameters

[0.213362] NET: Registered protocol family 16

[0.214291] DMA: preallocated 256 KiB pool for atomic coherent allocations

[0.237564] gpiochip_add: registered GPIOs 0 to 31 on device: gpio

[0.238071] OMAP GPIO hardware version 0.1

[0.241695] gpiochip_add: registered GPIOs 32 to 63 on device: gpio

[0.245058] gpiochip_add: registered GPIOs 64 to 95 on device: gpio

[0.248148] gpiochip_add: registered GPIOs 96 to 127 on device: gpio

[0.267223] omap-gpmc 5000.gpmc: could not find pctldev for node 
/pinmux@44e10800/gpmc_pins, deferring probe

[0.267286] platform 5000.gpmc: Driver omap-gpmc requests probe deferral

[0.268044] No ATAGs?

[0.268069] hw-breakpoint: debug architecture 0x4 unsupported.

[0.316248] bio: create slab bio-0 at 0

[

Re: v3.9.0-rc8 : oops in tick_do_update_jiffies64+0xbc/0x110

[Mark Jackson]

On 29/04/13 16:41, Tony Lindgren wrote:
 * Mark Jackson mpfj-l...@newflow.co.uk [130429 01:38]:
 I've been experiencing several crashes all pointing exactly the same place 
 in the same tick routine (see below).

 The exception stack trace at the end changes depending on when the oops 
 occurs.

 I've had the oops occur maybe 6 times in the last 50 reboots.

 Any ideas ?
 
 Sounds like it might be an issue with the physical memory or
 the timings. It could also be related to the idle loop not
 restoring something right for deeper idle states that corrupts
 the memory. And that's why it would seem to appear while waking
 to a timer.

I am suspecting a borderline CPU.  We only have X AM3359 parts which
are all pre-production.

 Maybe disable PM and run memtester to see if that runs reliably?

I'll see if I can get it running on our platform.

Thanks
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BUG: Unable to handle kernel NULL pointer dereference (cpsw driver)

[Mark Jackson]

Just got this on my AM335x board.

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.9.0-rc8-00020-g6e8f1be-dirty 
(mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #210 Thu Apr 25 
13:00:09 BST 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow 
AM335x NanoBone
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off 
mem=256M rootwait=1 ubi.mtd=7,2048 rootfstype=ubifs root=ubi0:rootfs
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 247484k/247484k available, 14660k reserved, 0K highmem

...

[2.592307] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[2.598775] davinci_mdio 4a101000.mdio: detected phy mask fffc
[2.608358] libphy: 4a101000.mdio: probed
[2.612692] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, 
driver SMSC LAN8710/LAN8720
[2.622390] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, 
driver SMSC LAN8710/LAN8720
[2.632354] Detected MACID = 00:18:31:93:44:39
[2.639792] cpsw: Detected MACID = 00:18:31:93:44:3a
[2.647041] Unable to handle kernel NULL pointer dereference at virtual 
address 00bc
[2.655613] pgd = c0004000
[2.658475] [00bc] *pgd=
[2.662298] Internal error: Oops: 805 [#1] ARM
[2.667005] CPU: 0Not tainted  (3.9.0-rc8-00020-g6e8f1be-dirty #210)
[2.674109] PC is at rtnl_fill_ifinfo+0x380/0x7d0
[2.679090] LR is at dev_get_stats+0x64/0xb0
[2.683605] pc : [c0337610]lr : [c032be8c]psr: 4113
[2.683605] sp : cf04dca0  ip :   fp : 
[2.695742] r10: cf331800  r9 : cf3318b4  r8 : c05d2cdc
[2.701263] r7 : cf04dca8  r6 : cf31e000  r5 : cf04dd84  r4 : cf17fbc0
[2.708165] r3 : 00b8  r2 :   r1 : 0017  r0 : cf17fbc0
[2.715069] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[2.722797] Control: 10c5387d  Table: 80004019  DAC: 0015
[2.728870] Process swapper (pid: 1, stack limit = 0xcf04c238)
[2.735037] Stack: (0xcf04dca0 to 0xcf04e000)
[2.739649] dca0: 0010      
 
[2.748297] dcc0:       
 
[2.756949] dce0:       
 
[2.765600] dd00:       
 
[2.774251] dd20:       
 
[2.782901] dd40:       
 
[2.791548] dd60:       
 
[2.800197] dd80: 00d0 0001   cf31e000  
0010 cf17fbc0
[2.808847] dda0:  4000  c0339c38   
 
[2.817499] ddc0:   cf31e000 cf31e000 c05d2488 c032d128 
cf31e000 cf0ba010
[2.826151] dde0: cf31edc0 c0b01e20 cf0ba000 c0444958 cf31e800 c032d1c8 
c04448b8 c02967bc
[2.834802] de00: cf0b9940 cf31edc0 cf04b340 cf31ee20 cf0ba010 cf0ba000 
cf31ee20 cf31e800
[2.843453] de20: cf0bcea0 cf0ba010 d0892800 d0892a00 d0892a20 d0892a40 
d0892a60 d08928c0
[2.852105] de40: d08928e0 0008 0001 003c 4a102000 4a102000 
2000 0010
[2.860756] de60: 0001 cf31ea80 d0892d00 000a 0400 0002 
0008 0002
[2.869406] de80: c0b00a7c cf0ba010 c0b00a7c c05dea70  c0b00a8c 
c058664c c05cc984
[2.878057] dea0:  c02408b8 c02408a0 c023f658 cf0ba010 cf0ba010 
cf0ba010 c05cc984
[2.886708] dec0: cf0ba044  c057194c c058664c 006c c023f920 
c05cc984 c023f88c
[2.895361] dee0: cf04dee8 c023db1c cf0444a8 cf0ac210 c057194c c05cc984 
c05c6580 cf2f6c40
[2.904013] df00:  c023e400 c050f208 c05cc984 c05cc984 0007 
c057d0c0 
[2.912664] df20: c057194c c023ff10  c057d0e0 0007 c057d0c0 
 c057194c
[2.921313] df40: 006c c055281c 0007 0007 6113 c057d0dc 
c057d0e0 0007
[2.929964] df60: c057d0c0 c05e3d80 c0552168 006c  c05529d8 
0007 0007
[2.938614] df80: c0552168   

Re: MTD : cannot reserve enough PEBs for bad PEB handling [SOLVED]

[Mark Jackson]

On 22/04/13 10:38, Mark Jackson wrote:
 I'm trying to work out how to generate a valid UBI image, but I keep
 getting a cannot get enough PEBs warning.
 
 I generate my image (destined for a 64MB NAND partition) using:-
 
 $ mkfs.ubifs -d output/target -e 0x1f000 -c 483 -m 0x800 -x none -F -o
 output/images/rootfs.ubifs
 $ ubinize -o output/images/rootfs.ubi -m 0x800 -p 0x2 -s 512 -O 2048
 ubinize.cfg
 
 My .cfg file is:-
 
 [ubifs]
 mode=ubi
 vol_id=0
 vol_type=dynamic
 vol_name=rootfs
 vol_alignment=1
 vol_flags=autoresize
 vol_size=61MiB

I just removed this vol_size entry and it all seems to be fine now.

I guess this was too big ??

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: OMAP2+: Allow NAND transfer mode to be specified in DT

[Mark Jackson]

OMAP devices support various NAND transfer modes.

Currently all device-tree definitions will use the default prefetch
polled mode, so this patch enables the transfer mode to be specified
in the device-tree.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
Changes in v2:
- Fixed line wrapping

 .../devicetree/bindings/mtd/gpmc-nand.txt  |8 
 arch/arm/mach-omap2/gpmc.c |   14 ++
 2 files changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index e7f8d7e..cd4a19b 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -29,6 +29,13 @@ Optional properties:
bch4  4-bit BCH ecc code
bch8  8-bit BCH ecc code
 
+ - ti,nand-xfer-type:  A string setting the data transfer type. One of:
+
+   prefetch-polled   Prefetch polled mode (default)
+   polledPolled mode, without prefetch
+   prefetch-dma  Prefetch enabled sDMA mode
+   prefetch-irq  Prefetch enabled irq mode
+
  - elm_id: Specifies elm device node. This is required to support BCH
error correction using ELM module.
 
@@ -55,6 +62,7 @@ Example for an AM33xx board:
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 16;
ti,nand-ecc-opt = bch8;
+   ti,nand-xfer-type = polled;
 
gpmc,sync-clk = 0;
gpmc,cs-on = 0;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 410e1ba..2f47f76 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1212,6 +1212,13 @@ static const char * const nand_ecc_opts[] = {
[OMAP_ECC_BCH8_CODE_HW] = bch8,
 };
 
+static const char * const nand_xfer_types[] = {
+   [NAND_OMAP_PREFETCH_POLLED] = prefetch-polled,
+   [NAND_OMAP_POLLED]  = polled,
+   [NAND_OMAP_PREFETCH_DMA]= prefetch-dma,
+   [NAND_OMAP_PREFETCH_IRQ]= prefetch-irq,
+};
+
 static int gpmc_probe_nand_child(struct platform_device *pdev,
 struct device_node *child)
 {
@@ -1241,6 +1248,13 @@ static int gpmc_probe_nand_child(struct platform_device 
*pdev,
break;
}
 
+   if (!of_property_read_string(child, ti,nand-xfer-type, s))
+   for (val = 0; val  ARRAY_SIZE(nand_xfer_types); val++)
+   if (!strcasecmp(s, nand_xfer_types[val])) {
+   gpmc_nand_data-xfer_type = val;
+   break;
+   }
+
val = of_get_nand_bus_width(child);
if (val == 16)
gpmc_nand_data-devsize = NAND_BUSWIDTH_16;
-- 
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

MTD : cannot reserve enough PEBs for bad PEB handling

[Mark Jackson]

I'm trying to work out how to generate a valid UBI image, but I keep
getting a cannot get enough PEBs warning.

I generate my image (destined for a 64MB NAND partition) using:-

$ mkfs.ubifs -d output/target -e 0x1f000 -c 483 -m 0x800 -x none -F -o
output/images/rootfs.ubifs
$ ubinize -o output/images/rootfs.ubi -m 0x800 -p 0x2 -s 512 -O 2048
ubinize.cfg

My .cfg file is:-

[ubifs]
mode=ubi
vol_id=0
vol_type=dynamic
vol_name=rootfs
vol_alignment=1
vol_flags=autoresize
vol_size=61MiB
image=output/images/rootfs.ubifs

And the resulting image is:-

-rw-rw-r-- 1 mpfj mpfj 9437184 Apr 16 10:19 rootfs.ubi

This is then written to a freshly erased 64MB NAND partition, and
appears to mount correctly, apart from the warning about not enough
reserved PEBs, as follows:-

...
[0.792456] UBI: attaching mtd7 to ubi0
[1.540858] UBI: scanning is finished
[1.557578] UBI warning: print_rsvd_warning: cannot reserve enough
PEBs for bad PEB handling, reserved 4, need 40
[1.561346] UBI: attached mtd7 (name rootfs, size 64 MiB) to ubi0
[1.561404] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[1.561434] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[1.561464] UBI: VID header offset: 2048 (aligned 2048), data offset:
4096
[1.561493] UBI: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
[1.561520] UBI: user volume: 1, internal volumes: 1, max. volumes
count: 128
[1.561554] UBI: max/mean erase counter: 2/1, WL threshold: 4096,
image sequence number: 1434266085
[1.561591] UBI: available PEBs: 0, total reserved PEBs: 512, PEBs
reserved for bad PEB handling: 4
[1.562374] UBI: background thread ubi_bgt0d started, PID 598
...

I think I've calculated the various option values correctly for
mkfs.ubifs and ubinize.

But since I'm getting the warning, can anyone explain where I've gone
wrong ?

Thanks in advance
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : cannot reserve enough PEBs for bad PEB handling

[Mark Jackson]

On 22/04/13 10:38, Mark Jackson wrote:
 I'm trying to work out how to generate a valid UBI image, but I keep
 getting a cannot get enough PEBs warning.

snip

 ...
 [0.792456] UBI: attaching mtd7 to ubi0
 [1.540858] UBI: scanning is finished
 [1.557578] UBI warning: print_rsvd_warning: cannot reserve enough
 PEBs for bad PEB handling, reserved 4, need 40
 [1.561346] UBI: attached mtd7 (name rootfs, size 64 MiB) to ubi0
 [1.561404] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
 [1.561434] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
 [1.561464] UBI: VID header offset: 2048 (aligned 2048), data offset:
 4096
 [1.561493] UBI: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
 [1.561520] UBI: user volume: 1, internal volumes: 1, max. volumes
 count: 128
 [1.561554] UBI: max/mean erase counter: 2/1, WL threshold: 4096,
 image sequence number: 1434266085
 [1.561591] UBI: available PEBs: 0, total reserved PEBs: 512, PEBs
 reserved for bad PEB handling: 4
 [1.562374] UBI: background thread ubi_bgt0d started, PID 598
 ...

And some additional UBI messages I failed to copy in:-

...
[1.728485] UBIFS: recovery needed
[1.824972] UBIFS: recovery deferred
[1.825553] UBIFS: mounted UBI device 0, volume 0, name rootfs, R/O
mode
[1.825595] UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O
unit sizes: 2048 bytes/2048 bytes
[1.825638] UBIFS: FS size: 60059648 bytes (57 MiB, 473 LEBs),
journal size 7999488 bytes (7 MiB, 63 LEBs)
[1.825677] UBIFS: reserved for root: 0 bytes (0 KiB)
[1.825711] UBIFS: media format: w4/r0 (latest is w4/r0), UUID
93286679-C044-4BC4-8FCB-6E5055E65825, small LPT model
[2.088284] UBIFS: completing deferred recovery
[2.204405] UBIFS: background thread ubifs_bgt0_0 started, PID 613
[2.206118] UBIFS: deferred recovery completed

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW

[Mark Jackson]

On 18/04/13 17:01, Mark Jackson wrote:
 On 15/04/13 18:34, Mugunthan V N wrote:
 On 4/15/2013 10:58 PM, Mark Jackson wrote:
 On 15/04/13 18:07, Mugunthan V N wrote:
 On 4/15/2013 12:46 AM, Mark Jackson wrote:

 snip


 Notice that at the end, the nfs link appears to come back ok, but
 the ps command never completes.

 Any ideas of what's going on ?

 I have tried ping on both the interface fine. Will verify with ps again
 later in this week.
 Can you provide below details details
 - Are you using EVMsk or custom build EVM?

 This is a custom board (based on the BeagleBone design) with dual
 Ethernet, NAND, NOR and FRAM.

 The dual emac thing is (one of) the last things to get signed off, so
 I'm willing to assist in tracking this down.

 After testing the scenario i may be able to send you an update later in
 this week.
 
 I have made some progress ... I realised I was missing a (clearly rather
 important !!) item in my .config file, namely CONFIG_TI_DAVINCI_EMAC.
 
 I am now able to ping from our board to other systems on the network
 (again, I've only tested eth0 at the moment).
 
 However, I am unable to ping everything I should be able to !!

snip

 When the pings fail, I am unable to see *any* activity on the network
 (using wireshark).
 
 Is there anything else I should try ?

Mugunthan

Can you confirm that I'm actually trying to achieve the right thing ?

I have all along assumed that Dual EMAC mode would simply provide the
kernel will a pair of independent Ethernet ports.

All I am trying to do is to get both Ethernet ports working so I can
have one port on (say) 10.0.x.x and the other on (say) 10.1.x.x

But there is all this reference to VLANs(in the source code and the TRM)
... I have not setup any VLANs.  Do I need to ?  If so, how ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW

[Mark Jackson]

On 22/04/13 18:01, Mugunthan V N wrote:
 On 4/22/2013 7:37 PM, Mark Jackson wrote:
 Mugunthan

 Can you confirm that I'm actually trying to achieve the right thing ?

 I have all along assumed that Dual EMAC mode would simply provide the
 kernel will a pair of independent Ethernet ports.
 Yes, it will provide two network interfaces for ex eth0 and eth1
 All I am trying to do is to get both Ethernet ports working so I can
 have one port on (say) 10.0.x.x and the other on (say) 10.1.x.x
 This is perfectly correct
 But there is all this reference to VLANs(in the source code and the TRM)
 ... I have not setup any VLANs.  Do I need to ?  If so, how ?
 No need to setup any VLAN. VLAN are used to segregate the
 two down stream ports and it will be taken care by the driver

Mugunthan

I now have this all working, thanks to Markus Brunner who spotted that
the CPSW_VLAN_AWARE bit is being incorrectly set rather than cleared in
cpsw_init_host_port().

I think he will be posting a patch soon.

Regards
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP2+: Allow NAND transfer mode to be specified in DT

[Mark Jackson]

OMAP devices support various NAND transfer modes.

Currently all device-tree definitions will use the default prefetch
polled mode, so this patch enables the transfer mode to be specified
in the device-tree.
---
 .../devicetree/bindings/mtd/gpmc-nand.txt  |8 
 arch/arm/mach-omap2/gpmc.c |   14 ++
 2 files changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index e7f8d7e..cd4a19b 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -29,6 +29,13 @@ Optional properties:
bch4  4-bit BCH ecc code
bch8  8-bit BCH ecc code

+ - ti,nand-xfer-type:  A string setting the data transfer type. One of:
+
+   prefetch-polled   Prefetch polled mode (default)
+   polledPolled mode, without prefetch
+   prefetch-dma  Prefetch enabled sDMA mode
+   prefetch-irq  Prefetch enabled irq mode
+
  - elm_id: Specifies elm device node. This is required to support BCH
error correction using ELM module.

@@ -55,6 +62,7 @@ Example for an AM33xx board:
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 16;
ti,nand-ecc-opt = bch8;
+   ti,nand-xfer-type = polled;

gpmc,sync-clk = 0;
gpmc,cs-on = 0;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 410e1ba..2f47f76 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1212,6 +1212,13 @@ static const char * const nand_ecc_opts[] = {
[OMAP_ECC_BCH8_CODE_HW] = bch8,
 };

+static const char * const nand_xfer_types[] = {
+   [NAND_OMAP_PREFETCH_POLLED] = prefetch-polled,
+   [NAND_OMAP_POLLED]  = polled,
+   [NAND_OMAP_PREFETCH_DMA]= prefetch-dma,
+   [NAND_OMAP_PREFETCH_IRQ]= prefetch-irq,
+};
+
 static int gpmc_probe_nand_child(struct platform_device *pdev,
 struct device_node *child)
 {
@@ -1241,6 +1248,13 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
break;
}

+   if (!of_property_read_string(child, ti,nand-xfer-type, s))
+   for (val = 0; val  ARRAY_SIZE(nand_xfer_types); val++)
+   if (!strcasecmp(s, nand_xfer_types[val])) {
+   gpmc_nand_data-xfer_type = val;
+   break;
+   }
+
val = of_get_nand_bus_width(child);
if (val == 16)
gpmc_nand_data-devsize = NAND_BUSWIDTH_16;
-- 
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW

[Mark Jackson]

On 15/04/13 18:34, Mugunthan V N wrote:
 On 4/15/2013 10:58 PM, Mark Jackson wrote:
 On 15/04/13 18:07, Mugunthan V N wrote:
 On 4/15/2013 12:46 AM, Mark Jackson wrote:

 snip


 Notice that at the end, the nfs link appears to come back ok, but
 the ps command never completes.

 Any ideas of what's going on ?

 I have tried ping on both the interface fine. Will verify with ps again
 later in this week.
 Can you provide below details details
 - Are you using EVMsk or custom build EVM?

 This is a custom board (based on the BeagleBone design) with dual
 Ethernet, NAND, NOR and FRAM.

 The dual emac thing is (one of) the last things to get signed off, so
 I'm willing to assist in tracking this down.
 
 After testing the scenario i may be able to send you an update later in
 this week.

I have made some progress ... I realised I was missing a (clearly rather
important !!) item in my .config file, namely CONFIG_TI_DAVINCI_EMAC.

I am now able to ping from our board to other systems on the network
(again, I've only tested eth0 at the moment).

However, I am unable to ping everything I should be able to !!

Here's my setup ...

# cat /etc/network/interfaces
# Configure Loopback
auto lo eth0 eth1
iface lo inet loopback
iface eth1 inet static
address 10.1.101.111
netmask 255.255.0.0
gateway 10.1.0.1
iface eth0 inet static
address 10.0.101.111
netmask 255.255.0.0
gateway 10.0.0.1

# ifconfig
eth0  Link encap:Ethernet  HWaddr C2:21:5E:B4:06:5E
  inet addr:10.0.101.111  Bcast:0.0.0.0  Mask:255.255.0.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:67 errors:0 dropped:0 overruns:0 frame:0
  TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:8848 (8.6 KiB)  TX bytes:4290 (4.1 KiB)
  Interrupt:56

eth1  Link encap:Ethernet  HWaddr D6:2F:CF:39:22:4E
  inet addr:10.1.101.111  Bcast:0.0.0.0  Mask:255.255.0.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:38 errors:0 dropped:0 overruns:0 frame:0
  TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:4022 (3.9 KiB)  TX bytes:4022 (3.9 KiB)

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
0.0.0.0 10.0.0.10.0.0.0 UG0  00 eth0
10.0.0.00.0.0.0 255.255.0.0 U 0  00 eth0
10.1.0.00.0.0.0 255.255.0.0 U 0  00 eth1

I can ping a couple of units on 10.0.0.x ...

# ping 10.0.0.120
PING 10.0.0.120 (10.0.0.120): 56 data bytes
64 bytes from 10.0.0.120: seq=0 ttl=64 time=0.955 ms
64 bytes from 10.0.0.120: seq=1 ttl=64 time=0.676 ms
64 bytes from 10.0.0.120: seq=2 ttl=64 time=0.732 ms
64 bytes from 10.0.0.120: seq=3 ttl=64 time=0.762 ms

--- 10.0.0.120 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.676/0.781/0.955 ms
# ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: seq=0 ttl=64 time=1.815 ms
64 bytes from 10.0.0.5: seq=1 ttl=64 time=0.458 ms
64 bytes from 10.0.0.5: seq=2 ttl=64 time=0.474 ms
64 bytes from 10.0.0.5: seq=3 ttl=64 time=0.345 ms
64 bytes from 10.0.0.5: seq=4 ttl=64 time=0.329 ms

--- 10.0.0.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.329/0.684/1.815 ms

But *not* my router on the same subnet ...

# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes

--- 10.0.0.1 ping statistics ---
15 packets transmitted, 0 packets received, 100% packet loss

I am also unable to ping other equipment that exists:-

# ping 10.0.101.2
PING 10.0.101.2 (10.0.101.2): 56 data bytes

--- 10.0.101.2 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

# ping 10.0.200.2
PING 10.0.200.2 (10.0.200.2): 56 data bytes

--- 10.0.200.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Just to prove these other item do exist, here's me pinging them from
another Linux VM (working off the same physical switch):-

mpfj@mpfj-nanobone:~/linux/linux-2.6$ ifconfig
eth0  Link encap:Ethernet  HWaddr 08:00:27:1e:0d:f5
  inet addr:10.0.0.120  Bcast:10.0.255.255  Mask:255.255.0.0
  inet6 addr: fe80::a00:27ff:fe1e:df5/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:135935 errors:0 dropped:0 overruns:0 frame:0
  TX packets:172692 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000

Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW

[Mark Jackson]

On 15/04/13 18:34, Mugunthan V N wrote:
 On 4/15/2013 10:58 PM, Mark Jackson wrote:
 On 15/04/13 18:07, Mugunthan V N wrote:
 On 4/15/2013 12:46 AM, Mark Jackson wrote:

 snip


 Notice that at the end, the nfs link appears to come back ok, but
 the ps command never completes.

 Any ideas of what's going on ?

 I have tried ping on both the interface fine. Will verify with ps again
 later in this week.
 Can you provide below details details
 - Are you using EVMsk or custom build EVM?

 This is a custom board (based on the BeagleBone design) with dual Ethernet, 
 NAND, NOR and FRAM.

 The dual emac thing is (one of) the last things to get signed off, so I'm 
 willing to assist in tracking this down.
 
 After testing the scenario i may be able to send you an update later in this 
 week.

Just a quick update ...

I've now setup our board to boot entirely from NAND (UBoot - Kernel - UBIFS) 
so
that I'm no longer using NFS (just to isolate any issues there).

I am still *unable* to get a connection on either Ethernet port.

*HOWEVER* ... I *can* ping my board from another PC on the network:-

mpfj@mpfj-nanobone:~/uboot/u-boot$ ping 10.0.101.111 -c 5
PING 10.0.101.111 (10.0.101.111) 56(84) bytes of data.
64 bytes from 10.0.101.111: icmp_req=1 ttl=64 time=0.692 ms
64 bytes from 10.0.101.111: icmp_req=2 ttl=64 time=0.551 ms
64 bytes from 10.0.101.111: icmp_req=3 ttl=64 time=0.462 ms
64 bytes from 10.0.101.111: icmp_req=4 ttl=64 time=0.409 ms
64 bytes from 10.0.101.111: icmp_req=5 ttl=64 time=0.344 ms

--- 10.0.101.111 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.344/0.491/0.692/0.123 ms

So I can't ping *out*, but I can ping *in* !!

Note that I've only tried this ping test to/from eth0 ... I'll
setup another box on the correct IP range so I can also test eth1.

I've added my boot log below.

Cheers
Mark J.
---
U-Boot SPL 2013.04-rc2-00065-g7450e4d-dirty (Apr 16 2013 - 11:36:17)


U-Boot 2013.04-rc2-00065-g7450e4d-dirty (Apr 16 2013 - 11:36:17)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Net:   cpsw:0 is connected to cpsw.  Reconnecting to cpsw
cpsw
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x20, size 0x40
 4194304 bytes read: OK
## Booting kernel from Legacy Image at 8020 ...
   Image Name:   Linux 3.9.0-rc7-00023-gfcc38a5
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:2997518 Bytes = 2.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.9.0-rc7-00023-gfcc38a5 (mpfj@mpfj-nanobone) (gcc 
version 4.5.4 (Buildroot 2012.11) ) #156 Tue Apr 16 08:55:28 BST 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow 
AM335x NanoBone
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c059a858, node_mem_map 
c0ac4000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off 
mem=256M rootwait=1 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs 
ignore_loglevel
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 247776k/247776k available, 14368k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00]   .text : 0xc0008000 - 0xc0517550   (5182 kB)
[0.00]   .init : 0xc0518000 - 0xc0549fdc   ( 200 kB)
[0.00]   .data : 0xc054a000 - 0xc059b420   ( 326 kB)
[0.00].bss : 0xc059b420 - 0xc0ac0210   (5268 kB)
[0.00

Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW

[Mark Jackson]

On 15/04/13 18:07, Mugunthan V N wrote:

On 4/15/2013 12:46 AM, Mark Jackson wrote:


snip



Notice that at the end, the nfs link appears to come back ok, but
the ps command never completes.

Any ideas of what's going on ?


I have tried ping on both the interface fine. Will verify with ps again
later in this week.
Can you provide below details details
- Are you using EVMsk or custom build EVM?


This is a custom board (based on the BeagleBone design) with dual 
Ethernet, NAND, NOR and FRAM.


The dual emac thing is (one of) the last things to get signed off, so 
I'm willing to assist in tracking this down.


Regards
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW

[Mark Jackson]

On 15/04/13 18:34, Mugunthan V N wrote:

On 4/15/2013 10:58 PM, Mark Jackson wrote:

On 15/04/13 18:07, Mugunthan V N wrote:

On 4/15/2013 12:46 AM, Mark Jackson wrote:


snip



Notice that at the end, the nfs link appears to come back ok, but
the ps command never completes.

Any ideas of what's going on ?


I have tried ping on both the interface fine. Will verify with ps again
later in this week.
Can you provide below details details
- Are you using EVMsk or custom build EVM?


This is a custom board (based on the BeagleBone design) with dual
Ethernet, NAND, NOR and FRAM.

The dual emac thing is (one of) the last things to get signed off, so
I'm willing to assist in tracking this down.


After testing the scenario i may be able to send you an update later in
this week.


Excellent ... if you've anything I can test now, I'd be happy to try.

Cheers
Mark J.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW

[Mark Jackson]

On 11/02/13 19:52, Mugunthan V N wrote:

This patch series implements Dual EMAC mode implementation of CPSW
which acts as two standalone EMAC by segregating the switch using VIDs
and port VLAN

Mugunthan V N (3):
   driver: net: ethernet: davinci_cpdma: add support for directed packet
 and source port detection
   driver: net: ethernet: cpsw: make cpts as pointer
   driver: net: ethernet: cpsw: dual emac interface implementation

  Documentation/devicetree/bindings/net/cpsw.txt |2 +
  drivers/net/ethernet/ti/cpsw.c |  387 +++-
  drivers/net/ethernet/ti/davinci_cpdma.c|   17 +-
  drivers/net/ethernet/ti/davinci_cpdma.h|4 +-
  drivers/net/ethernet/ti/davinci_emac.c |6 +-
  include/linux/platform_data/cpsw.h |3 +
  6 files changed, 338 insertions(+), 81 deletions(-)


I'm trying to get dual emac mode working, but I'm only having partial 
success.  We have a custom AM335x board with dual LAN8710 PYHs, but the 
basic design is based on the BeagleBone board.


I have the following in my .dts file:-

mac: ethernet@4a10 {
dual_emac = 1;
cpsw_emac0: slave@4a100200 {
dual_emac_res_vlan = 1;
};
cpsw_emac1: slave@4a100300 {
dual_emac_res_vlan = 2;
};
};

When I boot my board (across nfs via eth1):-

(a) the kernel is loaded (via tftp under U-Boot)
(b) the kernel mounts the nfsroot
(c) my init scripts are run (e.g. dropbear)
(d) the shell prompt appears

So far so good, but when I then try any shell command (e.g. ps) the 
nfs link just hangs.


Below is an extract from the boot messages:-

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.9.0-rc6-00186-g5b55d70-dirty 
(mpfj@mpfj-nanobone) (gcc version 4.7.2 (Buildroot 
2013.02-00154-g851ceaa) ) #19 Sun Apr 14 19:50:21 BST 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: 
Newflow AM335x NanoBone

[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] Built 1 zonelists in Zone order, mobility grouping on. 
Total pages: 64768
[0.00] Kernel command line: root=/dev/nfs 
nfsroot=10.1.0.111:/tftpboot/nanobone/rootfs rw 
ip=10.1.0.199:10.1.0.111:10.1.0.1:255.255.0.0::eth1:off console=ttyO0,115200

...
[1.424977] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[1.431443] davinci_mdio 4a101000.mdio: detected phy mask fffc
[1.440939] libphy: 4a101000.mdio: probed
[1.445266] davinci_mdio 4a101000.mdio: phy[0]: device 
4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[1.454962] davinci_mdio 4a101000.mdio: phy[1]: device 
4a101000.mdio:01, driver SMSC LAN8710/LAN8720

[1.465059] Random MACID = a2:3f:fb:2c:47:d9
[1.472276] cpsw: Random MACID = ae:d5:c0:c0:27:03
[1.480588] rtc-ds1307 0-0068: setting system clock to 2013-04-14 
19:59:52 UTC (1365969592)

[1.491543] net eth1: initializing cpsw version 1.12 (0)
[1.516965] net eth1: phy found : id is : 0x7c0f1
[4.595479] libphy: 4a101000.mdio:01 - Link is Up - 100/Full
[4.625872] IP-Config: Complete:
[4.629307]  device=eth1, hwaddr=ae:d5:c0:c0:27:03, 
ipaddr=10.1.0.199, mask=255.255.0.0, gw=10.1.0.1

[4.639365]  host=10.1.0.199, domain=, nis-domain=(none)
[4.645359]  bootserver=10.1.0.111, rootserver=10.1.0.111, rootpath=
[4.674219] VFS: Mounted root (nfs filesystem) on device 0:12.
[4.682438] devtmpfs: mounted
[4.686042] Freeing init memory: 196K
Starting logging: OK
Initializing random number generator... done.
Starting network...
ip: RTNETLINK answers: File exists
[5.340677] net eth0: initializing cpsw version 1.12 (0)
[5.366463] net eth0: phy found : id is : 0x7c0f1
ip: RTNETLINK answers: File exists
ip: RTNETLINK answers: File exists
ip: RTNETLINK answers: File exists
Starting dropbear sshd: OK

Welcome to Buildroot
nanobone login: root
Password:
# ps
[   18.845266] nfs: server 10.1.0.111 not responding, still trying

At this point, I can disconnect my network cable from eth1 and connect 
to eth0, and back again which shows the PYHs appear to be detecting the 
link up/down status of each port.


[  562.675229] libphy: 4a101000.mdio:01 - Link is Down
[  567.885586] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[  571.965156] libphy: 4a101000.mdio:00 - Link is Down
[  575.014943] nfs: server 10.1.0.111 not responding, still trying
[  576.635412] libphy: 4a101000.mdio:01 - Link is Up - 100/Full
[  579.426051] nfs: server 10.1.0.111 OK

Notice that at the end, the nfs link appears to come back ok, but the 
ps command never completes.


Any ideas of what's going on ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line 

Re: [PATCH 3/3] driver: net: ethernet: cpsw: dual emac interface implementation

[Mark Jackson]

On 11/02/13 19:52, Mugunthan V N wrote:

The CPSW switch can act as Dual EMAC by segregating the switch ports
using VLAN and port VLAN as per the TRM description in
14.3.2.10.2 Dual Mac Mode

Following CPSW components will be common for both the interfaces.
* Interrupt source is common for both eth interfaces
* Interrupt pacing is common for both interfaces
* Hardware statistics is common for all the ports
* CPDMA is common for both eth interface
* CPTS is common for both the interface and it should not be enabled on
   both the interface as timestamping information doesn't contain port
   information.

Constrains
* Reserved VID of One port should not be used in other interface which will
   enable switching functionality
* Same VID must not be used in both the interface which will enable switching
   functionality

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
  Documentation/devicetree/bindings/net/cpsw.txt |2 +
  drivers/net/ethernet/ti/cpsw.c |  335 
  include/linux/platform_data/cpsw.h |3 +
  3 files changed, 288 insertions(+), 52 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..ecfdf75 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Required properties:
  Optional properties:
  - ti,hwmods   : Must be cpgmac0
  - no_bd_ram   : Must be 0 or 1
+- dual_emac: Specifies Switch to act as Dual EMAC
+- dual_emac_res_vlan   : Specifies VID to be used to segregate the ports

  Note: ti,hwmods field is used to fetch the base address and irq
  resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 4b964bb..4ceed6e 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c


snip


@@ -1237,6 +1372,18 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
if (mac_addr)
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);

+   if (data-dual_emac) {
+   if (of_property_read_u32(node, dual_emac_res_vlan,
+prop)) {


Shouldn't this be:-

if (of_property_read_u32(slave_node, dual_emac_res_vlan,
 ^^

... so we pick each VLAN id from the individual slaves ?

Regards
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW

[Mark Jackson]

On 12/02/13 21:15, David Miller wrote:
 From: Mugunthan V N mugunthan...@ti.com
 Date: Tue, 12 Feb 2013 01:22:17 +0530
 
 This patch series implements Dual EMAC mode implementation of CPSW
 which acts as two standalone EMAC by segregating the switch using VIDs
 and port VLAN

 Mugunthan V N (3):
   driver: net: ethernet: davinci_cpdma: add support for directed packet
 and source port detection
   driver: net: ethernet: cpsw: make cpts as pointer
   driver: net: ethernet: cpsw: dual emac interface implementation
 
 Series applied.

I can see that this series is now in the mainline kernel, but can anyone
give me some pointers on how to use it ?

First, I'd like to check that it's achieving what I think it does ...
namely to be able to access both eth0 and eth1 as separate Ethernet ports ?

If this assumption is correct, can anyone guide me as to how to setup my
dts file to allow the kernel to see both ports ?

If have been trying to get it going (see my posting [1]), but to no avail.

Any help would be greatly appreciated !!

[1] http://www.spinics.net/lists/linux-omap/msg89920.html

Regards
Mark JACKSON
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

How do you configure AM335x dts for dual ethernet ?

[Mark Jackson]

I'm trying to work out how to setup my custom dts file to support dual ethernet.

This is on a custom board based on the BeagleBone, but with both ethernet ports 
connected in MII mode.

So far I have just copied the layout of am335x-evm.dts, but that only gives me 
eth0:-

[1.418487] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[1.424952] davinci_mdio 4a101000.mdio: detected phy mask fffc
[1.434455] libphy: 4a101000.mdio: probed
[1.438790] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, 
driver SMSC LAN8710/LAN8720
[1.448486] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, 
driver SMSC LAN8710/LAN8720
[1.458585] Random MACID = 82:72:bb:49:3f:49
[1.466964] rtc-ds1307 0-0068: setting system clock to 2013-04-11 16:15:37 
UTC (1365696937)
[1.478107] net eth0: initializing cpsw version 1.12 (0)
[1.486109] net eth0: phy found : id is : 0x7c0f1
[1.491696] net eth0: phy found : id is : 0x7c0f1

I added:-

mac: ethernet@4a10 {
dual_emac = 1;
};

... which gives me eth0 and eth1, but kills my nfs root:-

[1.444534] libphy: 4a101000.mdio: probed
[1.448842] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, 
driver SMSC LAN8710/LAN8720
[1.458422] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, 
driver SMSC LAN8710/LAN8720
[1.468439] Random MACID = 1e:5b:03:c9:a4:f7
[1.475683] cpsw: Random MACID = 66:56:fa:5e:9f:19
[1.484027] rtc-ds1307 0-0068: setting system clock to 2013-04-11 16:50:32 
UTC (1365699032)
[1.494911] net eth0: initializing cpsw version 1.12 (0)
[1.503727] net eth0: phy found : id is : 0x7c0f1
[4.579126] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[4.608561] IP-Config: Guessing netmask 255.0.0.0
[4.613910] IP-Config: Complete:
[4.617307]  device=eth0, hwaddr=1e:5b:03:c9:a4:f7, ipaddr=10.0.101.111, 
mask=255.0.0.0, gw=10.0.0.100
[4.627473]  host=10.0.101.111, domain=, nis-domain=(none)
[4.633613]  bootserver=255.255.255.255, rootserver=10.0.0.100, rootpath=
[4.665520] VFS: Mounted root (nfs filesystem) on device 0:12.
[4.673877] devtmpfs: mounted
[4.677461] Freeing init memory: 196K
Starting logging: OK
Initializing random number generator... done.
Starting network...
ip: RTNETLINK answers: File exists
ip: RTNETLINK answers: File exists
[5.449203] net eth1: initializing cpsw version 1.12 (0)
[5.456180] net eth1: phy found : id is : 0x7c0f1
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
Starting dropbear sshd: OK

Welcome to Buildroot
nanobone login: root
Password:
# ps
[   27.729217] nfs: server 10.0.0.100 not responding, still trying

I know this should work (since the svm has dual ethernet), so can anyone give 
me some pointers ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How do you configure AM335x dts for dual ethernet ?

[Mark Jackson]

On 11/04/13 17:14, Mark Jackson wrote:

I'm trying to work out how to setup my custom dts file to support dual ethernet.

This is on a custom board based on the BeagleBone, but with both ethernet ports 
connected in MII mode.


snip


I know this should work (since the svm has dual ethernet), so can anyone give 
me some pointers ?


That should read since the *starter kit* has dual ethernet.

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 3.9.0-rc3: BUG: Bad page state in process

[Mark Jackson]

On 25/03/13 13:30, Mark Jackson wrote:
 On our custom AM335x cpu board, I have had several kernel crashes via my 
 userspace program.

snip

And here's another similar oops ...

[16565.691706] Unable to handle kernel NULL pointer dereference at virtual 
address 
[16565.700289] pgd = cd07c000
[16565.703149] [] *pgd=
[16565.706909] Internal error: Oops: 5 [#1] ARM
[16565.711390] CPU: 0Not tainted  (3.9.0-rc4-00026-g58216a6 #148)
[16565.717886] PC is at free_pages_and_swap_cache+0x48/0xbc
[16565.723457] LR is at release_pages+0x1d0/0x20c
[16565.728117] pc : [c00be4ac]lr : [c009d474]psr: 2013
[16565.728117] sp : cf707d70  ip :   fp : cf56edac
[16565.740153] r10: cd079388  r9 : c0c8bac0  r8 : 
[16565.745624] r7 : 0001  r6 : cd079380  r5 : 0320  r4 : 000e
[16565.752463] r3 : 00080068  r2 :   r1 :   r0 : cf707d2c
[16565.759308] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[16565.766784] Control: 10c5387d  Table: 8d07c019  DAC: 0015
[16565.772802] Process ccrt (pid: 800, stack limit = 0xcf706238)
[16565.778820] Stack: (0xcf707d70 to 0xcf708000)
[16565.783389] 7d60: 000b b6bb6000 
0001 cf707e08
[16565.791961] 7d80: cf707e08 b6c0  c00aeb70 cf644d38 cf640700 
cf644d00 
[16565.800531] 7da0: 8e4d63cd cf56eda8 b6d97000 b6d96fff c0c8ba60  
fe49 
[16565.809102] 7dc0: 09bdd609 cf640700  cf707e08   
cf52d868 cf644d00
[16565.817675] 7de0: cf39c680 c00af4b4  cf2fd640 cf640498 cf644d00 
cf707e08 cf2ffc80
[16565.826251] 7e00: cf2fd640 c00b56a8 cf644d00 0001  0080 
 0400
[16565.834826] 7e20: 0400 cd079000 cf2ffc80 cf2fd640 cf52d868 cf644d00 
cf39c680 c03ffc08
[16565.843397] 7e40: 6013 cf644d5c cf644d00 cf644d00  cf706000 
cf2ffc80 c00364b8
[16565.851968] 7e60: cf644d00 cf52d4c0 cf706000 c00ccb4c cf2f7340 cf2ffc80 
cf2f73a4 cf707e90
[16565.860541] 7e80: cf2f7374 cf706000 0001 c010a624 cf2ffc80 0080 
0003 
[16565.869118] 7ea0: cf706000 cf2ffd80 cf6003c0 c0579ddc cf706000 c0109b08 
0320 c0075190
[16565.877691] 7ec0: 0002   c00cd214   
cf52d4c0 c0579dc0
[16565.886262] 7ee0: 0002  c0579dc0 cf2ffc80 fff8  
c057a71c c0579ddc
[16565.894834] 7f00: cf706000 c010a3e8 0320 c00cd200 0001  
c00cd150 befff000
[16565.903406] 7f20: cf706000 0001 cf38e548 cf706000 0001 0001 
cf38e548 cf2ffc80
[16565.911976] 7f40: bebc3dac bebc34a8  c00cd750 0001  
c00cd3bc 0ff0
[16565.920549] 7f60: cf2fd698 cf2fd640 cf52d6e0   cd046000 
bebc3dac bebc34a8
[16565.929124] 7f80: 000b c0013968 cf706000  0001f190 c00cda58 
 b6e0c198
[16565.937703] 7fa0: b6e07ee8 c00137c0  b6e0c198 b6dfcd52 bebc34a8 
bebc3dac b6e0c190
[16565.946280] 7fc0:  b6e0c198 b6e07ee8 000b 42b0 0001394e 
bebc3900 0001f190
[16565.954852] 7fe0: b6e07f34 bebc3488 b6dfac38 b6dc9e88 0010 b6dfcd52 
 
[16565.963451] [c00be4ac] (free_pages_and_swap_cache+0x48/0xbc) from 
[c00aeb70] (unmap_single_vma+0x3b0/0x5b8)
[16565.974035] [c00aeb70] (unmap_single_vma+0x3b0/0x5b8) from [c00af4b4] 
(unmap_vmas+0x54/0x68)
[16565.983253] [c00af4b4] (unmap_vmas+0x54/0x68) from [c00b56a8] 
(exit_mmap+0xd0/0x1f4)
[16565.991746] [c00b56a8] (exit_mmap+0xd0/0x1f4) from [c00364b8] 
(mmput+0x34/0xb8)
[16565.999783] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] 
(flush_old_exec+0x240/0x4c8)
[16566.008365] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] 
(load_elf_binary+0x23c/0x11b0)
[16566.018131] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] 
(search_binary_handler+0xe4/0x1f0)
[16566.028437] [c00cd200] (search_binary_handler+0xe4/0x1f0) from 
[c00cd750] (do_execve+0x444/0x4fc)
[16566.038107] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] 
(sys_execve+0x30/0x44)
[16566.046697] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] 
(ret_fast_syscall+0x0/0x3c)
[16566.055635] Code: e2877001 e1540007 da15 e49a8004 (e5983000)
[16566.062129] ---[ end trace d58a14e8bd6d8269 ]---


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 3.9.0-rc3: BUG: Bad page state in process

[Mark Jackson]

On 25/03/13 13:59, Mark Jackson wrote:
 On 25/03/13 13:30, Mark Jackson wrote:
 On our custom AM335x cpu board, I have had several kernel crashes via my 
 userspace program.
 
 snip
 
 And here's another similar oops ...

snip

Another big blowout ...

[16910.346870] BUG: Bad page state in process ccrt  pfn:8f94e
[16910.352656] page:c0cb49c0 count:0 mapcount:1 mapping:  (null) index:0xb6a21
[16910.360028] page flags: 0x80008(uptodate|swapbacked)
[16910.365332] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] 
(bad_page+0xa8/0x108)
[16910.374211] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] 
(free_pages_prepare+0xfc/0x108)
[16910.383451] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] 
(free_hot_cold_page+0x18/0x144)
[16910.393602] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] 
(free_hot_cold_page_list+0x2c/0x48)
[16910.404112] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from 
[c009d474] (release_pages+0x1d0/0x20c)
[16910.414264] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] 
(free_pages_and_swap_cache+0xac/0xbc)
[16910.424608] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from 
[c00b56e8] (exit_mmap+0x110/0x1f4)
[16910.434579] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] 
(mmput+0x34/0xb8)
[16910.442713] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] 
(flush_old_exec+0x240/0x4c8)
[16910.451321] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] 
(load_elf_binary+0x23c/0x11b0)
[16910.461103] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] 
(search_binary_handler+0xe4/0x1f0)
[16910.471429] [c00cd200] (search_binary_handler+0xe4/0x1f0) from 
[c00cd750] (do_execve+0x444/0x4fc)
[16910.481121] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] 
(sys_execve+0x30/0x44)
[16910.489737] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] 
(ret_fast_syscall+0x0/0x3c)
[16910.498694] BUG: Bad page state in process ccrt  pfn:8f94c
[16910.504484] page:c0cb4980 count:0 mapcount:1 mapping:  (null) index:0xb6a1f
[16910.511779] page flags: 0x80008(uptodate|swapbacked)
[16910.517033] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] 
(bad_page+0xa8/0x108)
[16910.525906] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] 
(free_pages_prepare+0xfc/0x108)
[16910.535144] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] 
(free_hot_cold_page+0x18/0x144)
[16910.545290] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] 
(free_hot_cold_page_list+0x2c/0x48)
[16910.555799] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from 
[c009d474] (release_pages+0x1d0/0x20c)
[16910.565945] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] 
(free_pages_and_swap_cache+0xac/0xbc)
[16910.576271] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from 
[c00b56e8] (exit_mmap+0x110/0x1f4)
[16910.586235] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] 
(mmput+0x34/0xb8)
[16910.594375] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] 
(flush_old_exec+0x240/0x4c8)
[16910.602952] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] 
(load_elf_binary+0x23c/0x11b0)
[16910.612734] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] 
(search_binary_handler+0xe4/0x1f0)
[16910.623062] [c00cd200] (search_binary_handler+0xe4/0x1f0) from 
[c00cd750] (do_execve+0x444/0x4fc)
[16910.632752] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] 
(sys_execve+0x30/0x44)
[16910.641348] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] 
(ret_fast_syscall+0x0/0x3c)
[16910.759432] BUG: Bad page state in process ccrt  pfn:8f94e
[16910.765348] page:c0cb49c0 count:1 mapcount:1 mapping:  (null) index:0x2
[16910.772283] page flags: 0x0()
[16910.775475] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] 
(bad_page+0xa8/0x108)
[16910.784360] [c0097dfc] (bad_page+0xa8/0x108) from [c0098fa0] 
(get_page_from_freelist+0x47c/0x57c)
[16910.794056] [c0098fa0] (get_page_from_freelist+0x47c/0x57c) from 
[c0099320] (__alloc_pages_nodemask+0xd8/0x7bc)
[16910.805030] [c0099320] (__alloc_pages_nodemask+0xd8/0x7bc) from 
[c00ae154] (do_wp_page+0xbc/0x728)
[16910.814813] [c00ae154] (do_wp_page+0xbc/0x728) from [c00b0624] 
(handle_pte_fault+0x23c/0x6c4)
[16910.824141] [c00b0624] (handle_pte_fault+0x23c/0x6c4) from [c00b0b3c] 
(handle_mm_fault+0x90/0xc0)
[16910.833831] [c00b0b3c] (handle_mm_fault+0x90/0xc0) from [c001da08] 
(do_page_fault+0x220/0x38c)
[16910.843251] [c001da08] (do_page_fault+0x220/0x38c) from [c0008498] 
(do_DataAbort+0x30/0x9c)
[16910.852390] [c0008498] (do_DataAbort+0x30/0x9c) from [c0013534] 
(__dabt_usr+0x34/0x40)
[16910.861068] Exception stack(0xcd057fb0 to 0xcd057ff8)
[16910.866382] 7fa0:  bedfe4c8 
0002 0094
[16910.874974] 7fc0:  b6eb1198 b6eacee8 b6ea1d52 42b0 0001394e 
bedfe900 0001f190
[16910.883568] 7fe0: b6eacf34 bedfe490 b6e9fc18 b6e9fc1c 0010 
[16910.890504] BUG: Bad page state in process ccrt  pfn:8f94c
[16910.896271] page:c0cb4980 count:1 mapcount:1 mapping:  (null) index:0x2
[16910.903217] page

Re: 3.9.0-rc3: BUG: Bad page state in process

[Mark Jackson]

On 25/03/13 15:06, jean-philippe francois wrote:
 2013/3/25 Mark Jackson mpfj-l...@mimc.co.uk:
 On 25/03/13 13:59, Mark Jackson wrote:
 On 25/03/13 13:30, Mark Jackson wrote:
 On our custom AM335x cpu board, I have had several kernel crashes via my 
 userspace program.

 
 Is the problem still present when booting with nohlt ?

Yes ... 

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.9.0-rc4-00026-g58216a6 (mpfj@mpfj-nanobone) (gcc 
version 4.5.4 (Buildroot 2012.11) ) #148 Mon Mar 25 09:19:57 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow 
AM335x NanoBone
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: root=/dev/nfs 
nfsroot=10.0.0.100:/tftpboot/nanobone/rootfs rw 
ip=10.0.101.111::10.0.0.100:::eth0:off console=ttyO0,115200 no-hlt
...

# ./ccrt -f target/ccrt.ccc 4 1
Setting up signal handler
Loading XML
XML mem usage = 1101660 in 55080 elements
Assessing resources
Creating langauge string store
Creating variable store
[   13.323738] BUG: Bad page state in process ccrt  pfn:8fba4
[   13.329525] page:c0cb9480 count:0 mapcount:1 mapping:  (null) index:0x49
[   13.336623] page flags: 0x80008(uptodate|swapbacked)
[   13.341908] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] 
(bad_page+0xa8/0x108)
[   13.350794] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] 
(free_pages_prepare+0xfc/0x108)
[   13.360038] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] 
(free_hot_cold_page+0x18/0x144)
[   13.370184] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] 
(free_hot_cold_page_list+0x2c/0x48)
[   13.380699] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from 
[c009d474] (release_pages+0x1d0/0x20c)
[   13.390856] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] 
(free_pages_and_swap_cache+0xac/0xbc)
[   13.401202] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from 
[c00b56e8] (exit_mmap+0x110/0x1f4)
[   13.411167] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] 
(mmput+0x34/0xb8)
[   13.419317] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] 
(flush_old_exec+0x240/0x4c8)
[   13.427918] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] 
(load_elf_binary+0x23c/0x11b0)
[   13.437700] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] 
(search_binary_handler+0xe4/0x1f0)
[   13.448029] [c00cd200] (search_binary_handler+0xe4/0x1f0) from 
[c00cd750] (do_execve+0x444/0x4fc)
[   13.457722] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] 
(sys_execve+0x30/0x44)
[   13.466332] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] 
(ret_fast_syscall+0x0/0x3c)
[   13.475303] BUG: Bad page state in process ccrt  pfn:8fbf2
[   13.481055] page:c0cb9e40 count:0 mapcount:1 mapping:  (null) index:0x97
[   13.488100] page flags: 0x80008(uptodate|swapbacked)
[   13.493356] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] 
(bad_page+0xa8/0x108)
[   13.502207] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] 
(free_pages_prepare+0xfc/0x108)
[   13.511443] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] 
(free_hot_cold_page+0x18/0x144)
[   13.521610] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] 
(free_hot_cold_page_list+0x2c/0x48)
[   13.532119] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from 
[c009d474] (release_pages+0x1d0/0x20c)
[   13.542265] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] 
(free_pages_and_swap_cache+0xac/0xbc)
[   13.552595] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from 
[c00b56e8] (exit_mmap+0x110/0x1f4)
[   13.562554] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] 
(mmput+0x34/0xb8)
[   13.570693] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] 
(flush_old_exec+0x240/0x4c8)
[   13.579288] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] 
(load_elf_binary+0x23c/0x11b0)
[   13.589070] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] 
(search_binary_handler+0xe4/0x1f0)
[   13.599395] [c00cd200] (search_binary_handler+0xe4/0x1f0) from 
[c00cd750] (do_execve+0x444/0x4fc)
[   13.609086] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] 
(sys_execve+0x30/0x44)
[   13.617682] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] 
(ret_fast_syscall+0x0/0x3c)
[   13.736537] BUG: Bad page state in process ccrt  pfn:8fba4
[   13.742321] page:c0cb9480 count:1 mapcount:1 mapping:  (null) index:0x2
[   13.749332] page flags: 0x0()
[   13.752506] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] 
(bad_page+0xa8/0x108)
[   13.761390] [c0097dfc] (bad_page+0xa8/0x108) from [c0098fa0] 
(get_page_from_freelist+0x47c/0x57c)
[   13.771086] [c0098fa0

AM335x crc32 oops ?

[Mark Jackson]

Apologies for the long email ...

Following on from another thread, I have encountered an issue with crc32 within
the mtd system, seemingly only on my AM335x cpu board.

In function ubi_eba_atomic_leb_change() in drivers/mtd/ubi/eba.c, there is a 
call
to crc32.

During a remount of my ubifs volume, ubi_eba_atomic_leb_change() is called 
several
times, with crc32 happening at various points.

Most of the time, the crc length is 2048 bytes, but when a large crc is required
(in my case 122880 bytes), I get an oops.

# mount -o remount,rw /
[   24.609350] UBIFS: start fixing up free space
[   24.627010] uealc crc32 : d08cb000 2048
[   24.643019] uealc crc32 : d08cb000 2048
[   24.661278] uealc crc32 : d08cb000 2048
[   24.680505] uealc crc32 : d08cb000 2048
[   24.743176] uealc crc32 : d08cb000 122880
[   24.747581] Unable to handle kernel paging request at virtual address 
e7938204
[   24.755199] pgd = cf408000
[   24.758052] [e7938204] *pgd=
[   24.761833] Internal error: Oops: 5 [#1] ARM
[   24.766342] CPU: 0Not tainted  (3.8.0-next-20130225-2-g678576f-dirty 
#45)
[   24.774248] PC is at crc32_le+0xf8/0x168
[   24.778389] LR is at ubi_eba_atomic_leb_change+0x1d8/0x460
[   24.784177] pc : [c01e734c]lr : [c026de20]psr: 2013
[   24.784177] sp : cf359e10  ip : 3145  fp : c054f840
[   24.796285] r10: e7938104  r9 : c054fc40  r8 : af5e2a9e
[   24.801796] r7 : e59f3038  r6 : e59f0040  r5 : 0040  r4 : 00e5
[   24.808682] r3 : c054e040  r2 :   r1 : d08d05d0  r0 : 3e5ed77d
[   24.815570] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   24.823097] Control: 10c5387d  Table: 8f408019  DAC: 0015
[   24.829160] Process mount (pid: 659, stack limit = 0xcf358238)
[   24.835313] Stack: (0xcf359e10 to 0xcf35a000)
[   24.839912] 9e00: d08cb000  
d08caffc 3c00
[   24.848543] 9e20: cf2f8000  cf2ec000 cf32da00 cf2f8554  
000c d08cb000
[   24.857173] 9e40: d08cb000 c059f1f6 cf32da00    
 0001e000
[   24.865803] 9e60: cf32e000 000c d08cb000 0080 000c cf3c8f88 
 0020
[   24.874435] 9e80: 8000 c026c47c 0001e000 cf359e9c cf32e000 d08cb000 
0001e000 c0179b80
[   24.883066] 9ea0: cf390c80 0001 0001e000 cf32e000  cf32eb20 
000c c01796f0
[   24.891698] 9ec0: cf32e000  cf32ea9c  cf359f48 c0175170 
0001 6013
[   24.900329] 9ee0: cf326800    cf359f48  
0020 c00c9e24
[   24.908963] 9f00: 00100100 00200200 cf390c80 8000 cf358000 00208020 
 cf01a200
[   24.917595] 9f20: cf326800 c00e3d6c  000c cf326840  
c0013968 cf3c4680
[   24.926227] 9f40: 000c  cf01a210 ce828858 000c cf3a4000 
000a18b4 
[   24.934859] 9f60: 00208020 c0013968 cf358000  0003 c00e3e40 
 c0071e24
[   24.943491] 9f80:   cf3c4680 cf314540 a010  
be984b68 b6fbc48c
[   24.952124] 9fa0: 0015 c00137c0  be984b68 000a18b4 000a18c0 
000a18c2 00208020
[   24.960757] 9fc0:  be984b68 b6fbc48c 0015   
 0003
[   24.969391] 9fe0: b6f6ef48 be984a64 00042994 b6f6ef58 a010 000a18b4 
ebfecd47 00095348
[   24.978033] [c01e734c] (crc32_le+0xf8/0x168) from [d08cb000] (0xd08cb000)
[   24.985570] Code: 0a08 e59da008 e28a1003 e5f1c001 (e2522001)
[   24.992006] ---[ end trace 1496ae984fb21f1a ]---

I did some further testing, and, when the 122880 byte crc is about to run, I 
performed multiple
crc's on the same buffer but with increasing sizes:-

# mount -o remount,rw /
[   19.208302] UBIFS: start fixing up free space
[   19.230271] uealc crc32 : ** starting 122880 byte test **
[   19.235881] uealc crc32 : d08cb000 2048
[   19.240015] uealc crc32 : d08cb000 4096
[   19.244091] uealc crc32 : d08cb000 8192
[   19.248184] uealc crc32 : d08cb000 16384
[   19.252448] uealc crc32 : d08cb000 32768
[   19.256772] uealc crc32 : d08cb000 65536
[   19.260133] uealc crc32 : d08cb000 122880
[   19.261117] Unable to handle kernel paging request at virtual address 
e79381bc
[   19.268741] pgd = cf40c000
[   19.271598] [e79381bc] *pgd=
[   19.275387] Internal error: Oops: 5 [#1] ARM
[   19.279902] CPU: 0Not tainted  (3.8.0-next-20130225-2-g678576f-dirty 
#47)
[   19.287819] PC is at crc32_le+0xf8/0x168
[   19.291965] LR is at ubi_eba_atomic_leb_change+0x3ac/0x4f8
[   19.297760] pc : [c01e724c]lr : [c026def4]psr: 2013
[   19.297760] sp : cf3bbe08  ip : 0e4e  fp : c054f840
[   19.309882] r10: e7938104  r9 : c054fc40  r8 : 65e95c1c
[   19.315396] r7 : 322e315f  r6 : 352e332e  r5 : 002e  r4 : 0035
[   19.322288] r3 : c054e040  r2 : 0033  r1 : d08d3d90  r0 : 63c3884e
[   19.329180] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   19.336713] Control: 10c5387d  Table: 8f40c019  DAC: 0015
[   19.342781] Process mount (pid: 

Re: MTD : Kernel oops when remounting ubifs as read/write

[Mark Jackson]

On 14/03/13 09:13, Artem Bityutskiy wrote:
 On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
 Sorry ... this just locks up the unit.
 
 OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
 below. The patch I proposed did not get the error path correctly, but it
 does fix the issue.
 
 I think what you treat as lockup is the fixup process. UBIFS basically
 reads the entire UBI volume and writes it back. And it uses the atomic
 change UBI service, which means it also calculates CRC of everything it
 writes. And this all just takes a lot of time. This has to be done only
 once on the first mount.

Okay ... I've retried, but how long is a lot of time ?

I've waited 15 minutes and still nothing.

And I can see that there's no activity on the NAND chip select !?!

I'll put some debug info into the fixup routines to see if I can trace what's 
going on.

Regards
Mark J.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 net-next 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mark Jackson]

On 14/03/13 10:21, Mugunthan V N wrote:
 On 3/13/2013 3:04 PM, Mark Jackson wrote:
 On 18/02/13 08:19, Mugunthan V N wrote:
 CPDMA interrupts are not properly acknowledged which leads to interrupt
 storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
 Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
 used for rx and tx respectively.
 
 Reported-by: Pantelis Antonioupa...@antoniou-consulting.com
 Signed-off-by: Mugunthan V Nmugunthan...@ti.com
 Not sure if I'm seeing this same problem [1], but it doesn't appear fixed to 
 me.

 I've tried both mainline -rc2 and -next.

 [1]https://lkml.org/lkml/2013/3/12/376
 Without this patch, PG2.0 was not usable as CPSW interrupt was never acked
 and CPU spent most of the time in CPSW ISR.
 
 I have checked -rc2 and it is working fine.

I needed to add patch [1] to fix my problem.  See thread [2].

[1] 
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d35162f89b8f00537d7b240b76d2d0e8b8d29aa0
[2] https://lkml.org/lkml/2013/3/13/146

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

[Mark Jackson]

On 14/03/13 10:30, Artem Bityutskiy wrote:
 On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
 On 14/03/13 09:13, Artem Bityutskiy wrote:
 On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
 Sorry ... this just locks up the unit.

 OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
 below. The patch I proposed did not get the error path correctly, but it
 does fix the issue.

 I think what you treat as lockup is the fixup process. UBIFS basically
 reads the entire UBI volume and writes it back. And it uses the atomic
 change UBI service, which means it also calculates CRC of everything it
 writes. And this all just takes a lot of time. This has to be done only
 once on the first mount.

 Okay ... I've retried, but how long is a lot of time ?

 I've waited 15 minutes and still nothing.

 And I can see that there's no activity on the NAND chip select !?!

 I'll put some debug info into the fixup routines to see if I can trace 
 what's going on.
 
 Just to make sure - try this last patch I sent. I did test it with
 nandsim at least, and I am sure it works. I did not test at all the
 first one.
 
 And yes, debug messages would be useful, just do not forget to add the
 'ignore_loglevel' kernel boot option, otherwise you won't see the
 messages on your console, since they are of KERN_DEBUG level.
 
 You may have other issues which cause lockup, e.g., in driver level. It
 makes sense to validate your flash with MTD test modules.

My first initial findings ...

I added some simple printk(KERN_INFO) lines to fixup_free_space(), and when
I remount, it gets as far as:-

printk(KERN_INFO ffs 7\n);
/* Fixup LEBs in the main area */
for (lnum = c-main_first; lnum  c-leb_cnt; lnum++) {
lprops = ubifs_lpt_lookup(c, lnum);
if (IS_ERR(lprops)) {
err = PTR_ERR(lprops);
goto out;
}

if (lprops-free  0) {
err = fixup_leb(c, lnum, c-leb_size - lprops-free);
if (err)
goto out;
}
}

out:
printk(KERN_INFO ffs x\n);
ubifs_release_lprops(c);
return err;
}

... before we get an oops with crc32_le().  See the full log below.

I'll keep digging ...

Regards
Mark J.
---
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-next-20130225-2-g678576f-dirty 
(mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #40 Thu Mar 14 
10:58:28 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI 
AM335x BeagleBone
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c059c7b0, node_mem_map 
c0ac6000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off 
mem=256M rootwait=1 ubi.mtd=6,2048 rootfstype=ubifs root=ubi0:rootfs 
ignore_loglevel
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 247768k/247768k available, 14376k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00]   .text : 0xc0008000 - 0xc05194ac   (5190 kB)
[0.00]   .init : 0xc051a000 - 0xc054bfbc   ( 200 kB)
[0.00]   .data : 0xc054c000 - 0xc059d360   ( 325 kB)
[0.00].bss : 0xc059d360 - 0xc0ac21a0   (5268 kB)
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 
interrupts
[0.00] Total of 128 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER1 at 2600 Hz
[0.00] sched_clock: 32 bits at 26MHz

Re: MTD : Kernel oops when remounting ubifs as read/write

[Mark Jackson]

On 14/03/13 12:23, Artem Bityutskiy wrote:
 On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
 Is this size larger than the allocated buffer ?

 I believe so.
 
 Err, I mean, the buffer is large enough. I do not believe there is a
 stupid bug like too small buffer. This code has worked for years and I
 do not think it was changes much.
 
 The oops may be cause by memory corruption - some of your drivers may
 corrupt memory. You need to spend more time debugging this carefully.

It can handle 64k, but not 122880 bytes ...

# mount -o remount,rw /
[   19.208302] UBIFS: start fixing up free space
[   19.235881] uealc crc32 : d08cb000 2048
[   19.240015] uealc crc32 : d08cb000 4096
[   19.244091] uealc crc32 : d08cb000 8192
[   19.248184] uealc crc32 : d08cb000 16384
[   19.252448] uealc crc32 : d08cb000 32768
[   19.256772] uealc crc32 : d08cb000 65536
[   19.260133] uealc crc32 : d08cb000 122880
[   19.261117] Unable to handle kernel paging request at virtual address 
e79381bc
[   19.268741] pgd = cf40c000
[   19.271598] [e79381bc] *pgd=
[   19.275387] Internal error: Oops: 5 [#1] ARM
[   19.279902] CPU: 0Not tainted  (3.8.0-next-20130225-2-g678576f-dirty 
#47)
[   19.287819] PC is at crc32_le+0xf8/0x168
[   19.291965] LR is at ubi_eba_atomic_leb_change+0x3ac/0x4f8
[   19.297760] pc : [c01e724c]lr : [c026def4]psr: 2013
[   19.297760] sp : cf3bbe08  ip : 0e4e  fp : c054f840
[   19.309882] r10: e7938104  r9 : c054fc40  r8 : 65e95c1c
[   19.315396] r7 : 322e315f  r6 : 352e332e  r5 : 002e  r4 : 0035
[   19.322288] r3 : c054e040  r2 : 0033  r1 : d08d3d90  r0 : 63c3884e
[   19.329180] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   19.336713] Control: 10c5387d  Table: 8f40c019  DAC: 0015
[   19.342781] Process mount (pid: 659, stack limit = 0xcf3ba238)
[   19.348939] Stack: (0xcf3bbe08 to 0xcf3bc000)
[   19.353542] be00:   cf2f8554  d08caffc 2000 
cf2f8000 cf357a00
[   19.362183] be20:  000c cf2ec000  000c cf2f8554 
 
[   19.370823] be40: d08cb000 d08cb000  0700 8000 c026c168 
 0001e000
[   19.379463] be60:  000c d08cb000 0080 000c cf3bbf48 
 0020
[   19.388101] be80: 8000 c026c37c 0001e000 cf33 cf33 d08cb000 
0001e000 c0179a78
[   19.396738] bea0: 000d c0177a68 0001e000 cf33  cf330b20 
000d c01794b4
[   19.405376] bec0:  cf33  cf330a9c  c0175170 
0001 6013
[   19.414012] bee0: cf32c800    cf3bbf48  
0020 c00c9e24
[   19.422648] bf00: 00100100 00200200 cf390300 8000 cf3ba000 00208020 
 cf01a200
[   19.431284] bf20: cf32c800 c00e3d6c  000c cf32c840  
c0013968 cf325800
[   19.439921] bf40: 000c  cf01a210 ce828858 000c cf053000 
000a18b4 
[   19.448559] bf60: 00208020 c0013968 cf3ba000  0003 c00e3e40 
 c0071e24
[   19.457197] bf80:   cf325800 cf328380 a010  
beb83b68 b6f8348c
[   19.465838] bfa0: 0015 c00137c0  beb83b68 000a18b4 000a18c0 
000a18c2 00208020
[   19.474475] bfc0:  beb83b68 b6f8348c 0015   
 0003
[   19.483108] bfe0: b6f35f48 beb83a64 00042994 b6f35f58 a010 000a18b4 
 
[   19.491758] [c01e724c] (crc32_le+0xf8/0x168) from [] (  (null))
[   19.499115] Code: 0a08 e59da008 e28a1003 e5f1c001 (e2522001)
[   19.50] ---[ end trace 84a04423f0bc8388 ]---

 Do you have fastmap UBI feature enabled?

No ...

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_DTC=y
CONFIG_OF=y

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 net-next 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mark Jackson]

On 18/02/13 08:19, Mugunthan V N wrote:
 CPDMA interrupts are not properly acknowledged which leads to interrupt
 storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
 Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
 used for rx and tx respectively.
 
 Reported-by: Pantelis Antoniou pa...@antoniou-consulting.com
 Signed-off-by: Mugunthan V N mugunthan...@ti.com

Not sure if I'm seeing this same problem [1], but it doesn't appear fixed to me.

I've tried both mainline -rc2 and -next.

[1] https://lkml.org/lkml/2013/3/12/376

Regards
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Excessive ethernet interrupts on AM335x board

[Mark Jackson]

On 13/03/13 08:44, Koen Kooi wrote:
 
 Op 12 mrt. 2013, om 16:35 heeft Mark Jackson mpfj-l...@mimc.co.uk het 
 volgende geschreven:
 
 I'm just fighting an issue with ethernet on our custom AM335x board:-

 # uname -a
 Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 
 armv7l GNU/Linux

 Every now and then, the whole unit slows to a crawl.  The only indication of 
 any problem is:-

 (a) the serial tty port becomes much less responsive
 (b) normal ping times jump from 1ms to 10sec (sometimes 20sec !!)
 (c) the ethernet interrupt count rockets (see below)
 
 You probably have PG2.x silicon, have a look at this patch: 
 https://github.com/beagleboard/kernel/blob/3.8/patches/net/0003-cpsw-Fix-interrupt-storm-among-other-things.patch

No, it's 1.0 ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.9.0-rc2-00113-gd60f039-dirty 
(mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #141 Wed Mar 13 
09:14:03 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow 
AM335x NanoBone
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )

The patch certainly didn't fix things (and possibly made things worse i.e. my 
nfs root kept dropping off even more).

 I saw some patches going into net-next today that might address this in a 
 different way, but I haven't tried 3.9rc on an am335x yet.

I might track those down and test them.

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Excessive ethernet interrupts on AM335x board

[Mark Jackson]

On 13/03/13 10:32, Daniel Mack wrote:
 On Tue, Mar 12, 2013 at 4:35 PM, Mark Jackson mpfj-l...@mimc.co.uk wrote:
 I'm just fighting an issue with ethernet on our custom AM335x board:-

 # uname -a
 Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 
 armv7l GNU/Linux

 Every now and then, the whole unit slows to a crawl.  The only indication of 
 any problem is:-

 (a) the serial tty port becomes much less responsive
 (b) normal ping times jump from 1ms to 10sec (sometimes 20sec !!)
 (c) the ethernet interrupt count rockets (see below)

 I've tried to force the problem by flood pinging from my PC.

snip

 As you can see, when I stop the flood pings, the nfs link is now reported
 as being lost.
 
 I had the same problem. Please check this patch, I'm sure it will fix you 
 issue:
 
   
 https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d35162f89b8f00537d7b240b76d2d0e8b8d29aa0

Brilliant ... that's the one !!  

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

[Mark Jackson]

On 12/03/13 11:25, Artem Bityutskiy wrote:
 On Mon, 2013-03-04 at 16:42 +, Mark Jackson wrote:
 I'm encountering an oops when remounting my ubifs volume as read/write.

 # mount -o remount,rw /
 [   89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
 [   89.442122] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
 (ubifs_write_node+0x180/0x1c4)
 [   89.451896] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b3878] 
 (ubifs_write_master+0x9c/0x134)
 [   89.462018] [c01b3878] (ubifs_write_master+0x9c/0x134) from 
 [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8)
 [   89.472133] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
 (do_remount_sb+0x98/0x16c)
 [   89.481790] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
 (do_mount+0x830/0x888)
 [   89.490708] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
 (sys_mount+0x84/0xb8)
 [   89.499178] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
 (ret_fast_syscall+0x0/0x3c)
 [   89.510997] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
 [   89.517884] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
 (ubifs_write_node+0x180/0x1c4)
 [   89.527641] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b38b4] 
 (ubifs_write_master+0xd8/0x134)
 [   89.537760] [c01b38b4] (ubifs_write_master+0xd8/0x134) from 
 [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8)
 [   89.547869] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
 (do_remount_sb+0x98/0x16c)
 [   89.557526] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
 (do_mount+0x830/0x888)
 [   89.566435] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
 (sys_mount+0x84/0xb8)
 [   89.574905] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
 (ret_fast_syscall+0x0/0x3c)
 [   89.585939] UBIFS: start fixing up free space
 [   89.592237] UBIFS: background thread ubifs_bgt0_0 started, PID 629
 [   91.419951] UBIFS: free space fixup complete
 #

 If it's any help, if the remount is put into my inittab, I don't get any 
 oops.
 
 Would you please try this patch (also attached):
 
 diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
 index ac838b8..9791b3c 100644
 --- a/fs/ubifs/super.c
 +++ b/fs/ubifs/super.c
 @@ -1568,6 +1568,12 @@ static int ubifs_remount_rw(struct ubifs_info *c)
   c-remounting_rw = 1;
   c-ro_mount = 0;
  
 + if (c-space_fixup) {
 + err = ubifs_fixup_free_space(c);
 + if (err)
 + goto out;
 + }
 +
   err = check_free_space(c);
   if (err)
   goto out;
 @@ -1684,12 +1690,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
   err = dbg_check_space_info(c);
   }
  
 - if (c-space_fixup) {
 - err = ubifs_fixup_free_space(c);
 - if (err)
 - goto out;
 - }
 -
   mutex_unlock(c-umount_mutex);
   return err;
 

Sorry ... this just locks up the unit.

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

[Mark Jackson]

On 13/03/13 11:20, Artem Bityutskiy wrote:
 On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
 -   if (c-space_fixup) {
 -   err = ubifs_fixup_free_space(c);
 -   if (err)
 -   goto out;
 -   }
 -
 mutex_unlock(c-umount_mutex);
 return err;


 Sorry ... this just locks up the unit.
 
 Am I right that to reproduce it I need any image with the 'fixup' flag
 set, then I should put it on the flash, mount it R/O and then remount
 R/W. Right?
 

Yes ... this is on a custom AM335x board, where the ubi image must be created
with the -F flag.

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Excessive ethernet interrupts on AM335x board

[Mark Jackson]

I'm just fighting an issue with ethernet on our custom AM335x board:-

# uname -a
Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 
armv7l GNU/Linux

Every now and then, the whole unit slows to a crawl.  The only indication of 
any problem is:-

(a) the serial tty port becomes much less responsive
(b) normal ping times jump from 1ms to 10sec (sometimes 20sec !!)
(c) the ethernet interrupt count rockets (see below)

I've tried to force the problem by flood pinging from my PC.

# while true
 do grep 58: /proc/interrupts; sleep 10
 done
 58:   1291  INTC  4a10.ethernet   normal pinging (about 100 
irqs per 10sec)
 58:   1333  INTC  4a10.ethernet
 58:   1372  INTC  4a10.ethernet
 58:   3979  INTC  4a10.ethernet   start flood ping (about 4k 
irqs per 10sec)
 58:   6540  INTC  4a10.ethernet
 58:  17519  INTC  4a10.ethernet   big jump 
 58:  20169  INTC  4a10.ethernet
 58:  22775  INTC  4a10.ethernet
 58:  25368  INTC  4a10.ethernet
 58:  34598  INTC  4a10.ethernet   big jump 
 58:  37182  INTC  4a10.ethernet
 58:  39730  INTC  4a10.ethernet
 58: 141220  INTC  4a10.ethernet   whoa !!! 
 58: 146080  INTC  4a10.ethernet
 58: 149351  INTC  4a10.ethernet
 58: 152922  INTC  4a10.ethernet
 58: 156420  INTC  4a10.ethernet
 58: 159538  INTC  4a10.ethernet
 58: 162711  INTC  4a10.ethernet
 58: 165746  INTC  4a10.ethernet
 58: 168973  INTC  4a10.ethernet
 58: 172128  INTC  4a10.ethernet
 58: 175030  INTC  4a10.ethernet
 58: 177957  INTC  4a10.ethernet
 58: 180782  INTC  4a10.ethernet
 58: 183618  INTC  4a10.ethernet
 58: 186450  INTC  4a10.ethernet
 58: 189242  INTC  4a10.ethernet
 58: 191909  INTC  4a10.ethernet
 58: 194565  INTC  4a10.ethernet
 58: 197153  INTC  4a10.ethernet
 58: 199730  INTC  4a10.ethernet   another big jump 
 58: 252629  INTC  4a10.ethernet
 58: 262955  INTC  4a10.ethernet
 58: 265557  INTC  4a10.ethernet
 58: 268131  INTC  4a10.ethernet
 58: 272586  INTC  4a10.ethernet
 58: 275623  INTC  4a10.ethernet   here I stop flood pings 
[  631.727758] nfs: server 10.0.0.100 not responding, still trying
[  638.738864] nfs: server 10.0.0.100 OK
 58: 277694  INTC  4a10.ethernet
 58: 277703  INTC  4a10.ethernet
 58: 277709  INTC  4a10.ethernet
 58: 277719  INTC  4a10.ethernet
 58: 277725  INTC  4a10.ethernet
 58: 277734  INTC  4a10.ethernet
 58: 277745  INTC  4a10.ethernet

As you can see, when I stop the flood pings, the nfs link is now reported
as being lost.

Any ideas ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Excessive ethernet interrupts on AM335x board

[Mark Jackson]

On 12/03/13 15:35, Mark Jackson wrote:
 I'm just fighting an issue with ethernet on our custom AM335x board:-
 
 # uname -a
 Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 
 armv7l GNU/Linux
 
 Every now and then, the whole unit slows to a crawl.  The only indication of 
 any problem is:-
 
 (a) the serial tty port becomes much less responsive
 (b) normal ping times jump from 1ms to 10sec (sometimes 20sec !!)
 (c) the ethernet interrupt count rockets (see below)
 
 I've tried to force the problem by flood pinging from my PC.
 
 # while true
 do grep 58: /proc/interrupts; sleep 10
 done
  58:   1291  INTC  4a10.ethernet   normal pinging (about 100 
 irqs per 10sec)
  58:   1333  INTC  4a10.ethernet
  58:   1372  INTC  4a10.ethernet
  58:   3979  INTC  4a10.ethernet   start flood ping (about 4k 
 irqs per 10sec)
  58:   6540  INTC  4a10.ethernet
  58:  17519  INTC  4a10.ethernet   big jump 
  58:  20169  INTC  4a10.ethernet
  58:  22775  INTC  4a10.ethernet
  58:  25368  INTC  4a10.ethernet
  58:  34598  INTC  4a10.ethernet   big jump 
  58:  37182  INTC  4a10.ethernet
  58:  39730  INTC  4a10.ethernet
  58: 141220  INTC  4a10.ethernet   whoa !!! 
  58: 146080  INTC  4a10.ethernet

Doing the flood ping test on an old Beaglebone (running kernel 3.2.34 on an 
sdcard), I get:-

# while true
 do grep 94: /proc/interrupts; sleep 10
ne
 done
 94: 281353  INTC  cpsw.0
 94: 370782  INTC  cpsw.0
 94: 457537  INTC  cpsw.0
 94: 544876  INTC  cpsw.0
 94: 631795  INTC  cpsw.0
 94: 717747  INTC  cpsw.0
 94: 805974  INTC  cpsw.0
 94: 892961  INTC  cpsw.0
 94: 981490  INTC  cpsw.0
 94:1070627  INTC  cpsw.0
 94:1153086  INTC  cpsw.0
 94:1242060  INTC  cpsw.0
 94:1327734  INTC  cpsw.0
 94:1413705  INTC  cpsw.0
 94:1504494  INTC  cpsw.0
 94:1591395  INTC  cpsw.0
 94:1676769  INTC  cpsw.0

So these are going up by 90k irqs per 10sec ... meaning that the AM335x
board seems to be *dropping* most of its ethernet irqs.

I'll try to get 3.9.0-rc2 on the BB and retest.

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Booting 3.9.0-rc2 on Beaglebone ?

[Mark Jackson]

I'm struggling to get the latest kernel git to load on my beaglebone.

My build process is:-

$ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- distclean
$ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_OMAP2PLUS_UART=y
CONFIG_DEBUG_AM33XXUART1=y
CONFIG_EARLY_PRINTK=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
$ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux-
$ cat arch/arm/boot/zImage arch/arm/boot/am335x-bone.dtb  
arch/arm/boot/zImage-dtb.am335x-bone
$ scripts/mkuboot.sh -A arm -O linux -C none  -T kernel -a 0x80008000 -e 
0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone 
arch/arm/boot/uImage-dtb.am335x-bone


But this produces the following when booting:-

## Booting kernel from Legacy Image at 8000 ...
   Image Name:   Linux
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3995640 Bytes = 3.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...


Error: unrecognized/unsupported machine ID (r1 = 0x0e05).

Available machine support:

ID (hex)NAME
Generic OMAP5 (Flattened Device Tree)
Generic OMAP4 (Flattened Device Tree)
Generic AM33XX (Flattened Device Tree)
Generic OMAP3-GP (Flattened Device Tree)
Generic OMAP3 (Flattened Device Tree)
Generic OMAP2430 (Flattened Device Tree)
Generic OMAP2420 (Flattened Device Tree)
01feOMAP2420 H4 board
0384OMAP2430 sdp2430 board
060aOMAP3 Beagle Board
091aOMAP3 Devkit8000
0667OMAP LDP board
06edOMAP Logic 3530 LV SOM board
0882Logic OMAP3 Torpedo board
0706Gumstix Overo
05ffOMAP3 EVM
06e1Pandora Handheld Console
0472OMAP3430 3430SDP board
06bfNokia N810 WiMAX
060cNokia N810
04f7Nokia N800
0dc2Nokia RM-696 board
0c94Nokia RM-680 board
07a3Nokia RX-51 board
09a0OMAP Zoom3 board
07afOMAP Zoom2 board
09a1OMAP 3630SDP board
0cdaCompulab CM-T3730
0925Compulab CM-T35
0abeCompulab CM-T3517
0a9dIGEP OMAP3 module
0928IGEP v2 board
0959OMAP3 touchbook Board
0870OMAP4430 4430SDP board
0ae7OMAP4 Panda board
0898OMAP3517/AM3517 EVM
0aa2OMAP3 STALKER
0bbcti8148evm
0af0ti8168evm
ARM-Versatile Express
08e0ARM-Versatile Express

Please check your kernel config and/or bootloader.

I guess I'm missing some vital step ?

Thanks for any help
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash

[Mark Jackson]

On 05/03/13 21:34, Jon Hunter wrote:
 
 On 03/05/2013 11:30 AM, Jon Hunter wrote:
 On 03/05/2013 10:20 AM, Mark Jackson wrote:
 
 [snip]
 
 But I can see in physmap_of.c that the device gets registered without any 
 call to
 devm_pinctrl_get_select_default() and hence no probe deferring takes place 
 is the
 pinctrl device hasn't yet been started (which it hasn't).

 Does probe deferral need adding to physmap_of.c, or should the pinctrl 
 device really
 be registered sooner ?

 I see, so the pinctrl driver is not getting probed until later.
 
 Can you give this version of the patch a go? I have re-worked the patch
 so the NOR device will only be registered after the GPMC probe completes.
 
 By the way, with this version you should remove simple-bus from your
 gpmc node compatible strings. I now call of_platform_device_create() to
 create the child device during the GPMC probe. I think that this is a
 safer approach.

This is better in that the probe *is* now delayed until the gpmc has been setup,
but I still get an oops.

However, this time it's in the actual cfi query code.

I've traced it down to when it tries to physically access the memory associated
with the chip select in question (in this case CS3 @ 0x1a00).

I printed some debug info to show that the GPMC CONFIG7 register is being setup
correctly, and I show the physical to virtual memory mapping values, as 
performed
in of_flash_probe(), but when I try to do a test raw_readw() on the virtual 
address,
I get the following:-

[1.222950] omap-gpmc 5000.gpmc: GPMC revision 6.0
[1.229002] gpmc_read_settings_dt: read/write wait monitoring not enabled!
[1.237916] enabling NAND BCH ecc with 8-bit correction
[1.243843] ONFI param page 0 valid
[1.247531] ONFI flash detected
[1.250856] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron 
MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64
[1.263149] 8 ofpart partitions found on MTD device omap2-nand.0
[1.269492] Creating 8 MTD partitions on omap2-nand.0:
[1.275150] 0x-0x0002 : spl1
[1.282593] 0x0002-0x0004 : spl2
[1.288524] 0x0004-0x0006 : spl3
[1.294456] 0x0006-0x0008 : spl4
[1.300270] 0x0008-0x001e : boot
[1.307224] 0x001e-0x0020 : env
[1.313093] 0x0020-0x0420 : rootfs
[1.373589] 0x0420-0x1000 : data
[1.541884] gpmc_probe_nor_child 1
[1.545483] GPMC_CS_CONFIG7_0 : 0f48
[1.549621] GPMC_CS_CONFIG7_1 : 0f58
[1.553812] GPMC_CS_CONFIG7_2 : 0f00
[1.557951] GPMC_CS_CONFIG7_3 : 0c5a
[1.564789] of_flash_probe ioremap : phys 1a00 - virt d300
[1.571468] of_flash_probe test read d300 ...
[1.576440] Unhandled fault: external abort on non-linefetch (0x1028) at 
0xd300
[1.584525] Internal error: : 1028 [#1] ARM
[1.588946] CPU: 0Not tainted  (3.9.0-rc1-12191-ga00d6d1-dirty #57)
[1.595943] PC is at of_flash_probe+0x22c/0x5dc
[1.600724] LR is at of_flash_probe+0x228/0x5dc
[1.605506] pc : [c023b28c]lr : [c023b288]psr: 2113
[1.605506] sp : cf077ba0  ip : cf06c080  fp : c0492150
[1.617621] r10: 0400  r9 : cf2ac6d0  r8 : 
[1.623135] r7 : cf2ac6d0  r6 : cf2b9010  r5 : cf2b9000  r4 : c0c81f60
[1.630027] r3 : d300  r2 :   r1 : cf06c4d8  r0 : 0025
[1.636921] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[1.644635] Control: 10c5387d  Table: 80004019  DAC: 0015
[1.650703] Process kworker/u:0 (pid: 6, stack limit = 0xcf076238)
[1.657225] Stack: (0xcf077ba0 to 0xcf078000)

Any ideas ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash

[Mark Jackson]

On 06/03/13 10:23, Mark Jackson wrote:
 On 05/03/13 21:34, Jon Hunter wrote:

 On 03/05/2013 11:30 AM, Jon Hunter wrote:
 On 03/05/2013 10:20 AM, Mark Jackson wrote:

 [snip]

 But I can see in physmap_of.c that the device gets registered without any 
 call to
 devm_pinctrl_get_select_default() and hence no probe deferring takes place 
 is the
 pinctrl device hasn't yet been started (which it hasn't).

 Does probe deferral need adding to physmap_of.c, or should the pinctrl 
 device really
 be registered sooner ?

 I see, so the pinctrl driver is not getting probed until later.

 Can you give this version of the patch a go? I have re-worked the patch
 so the NOR device will only be registered after the GPMC probe completes.

 By the way, with this version you should remove simple-bus from your
 gpmc node compatible strings. I now call of_platform_device_create() to
 create the child device during the GPMC probe. I think that this is a
 safer approach.
 
 This is better in that the probe *is* now delayed until the gpmc has been 
 setup,
 but I still get an oops.
 
 However, this time it's in the actual cfi query code.
 
 I've traced it down to when it tries to physically access the memory 
 associated
 with the chip select in question (in this case CS3 @ 0x1a00).
 
 I printed some debug info to show that the GPMC CONFIG7 register is being 
 setup
 correctly, and I show the physical to virtual memory mapping values, as 
 performed
 in of_flash_probe(), but when I try to do a test raw_readw() on the virtual 
 address,
 I get the following:-
 
 [1.222950] omap-gpmc 5000.gpmc: GPMC revision 6.0
 [1.229002] gpmc_read_settings_dt: read/write wait monitoring not enabled!
 [1.237916] enabling NAND BCH ecc with 8-bit correction
 [1.243843] ONFI param page 0 valid
 [1.247531] ONFI flash detected
 [1.250856] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron 
 MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64
 [1.263149] 8 ofpart partitions found on MTD device omap2-nand.0
 [1.269492] Creating 8 MTD partitions on omap2-nand.0:
 [1.275150] 0x-0x0002 : spl1
 [1.282593] 0x0002-0x0004 : spl2
 [1.288524] 0x0004-0x0006 : spl3
 [1.294456] 0x0006-0x0008 : spl4
 [1.300270] 0x0008-0x001e : boot
 [1.307224] 0x001e-0x0020 : env
 [1.313093] 0x0020-0x0420 : rootfs
 [1.373589] 0x0420-0x1000 : data
 [1.541884] gpmc_probe_nor_child 1
 [1.545483] GPMC_CS_CONFIG7_0 : 0f48
 [1.549621] GPMC_CS_CONFIG7_1 : 0f58
 [1.553812] GPMC_CS_CONFIG7_2 : 0f00
 [1.557951] GPMC_CS_CONFIG7_3 : 0c5a

0x0c5a is an invalid mode !!

I'm trying to use a 64MB address space but not on a 64MB boundary ... oops.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash

[Mark Jackson]

On 06/03/13 16:44, Jon Hunter wrote:
 
 On 03/06/2013 07:30 AM, Mark Jackson wrote:
 On 06/03/13 10:23, Mark Jackson wrote:

snip

 [1.541884] gpmc_probe_nor_child 1
 [1.545483] GPMC_CS_CONFIG7_0 : 0f48
 [1.549621] GPMC_CS_CONFIG7_1 : 0f58
 [1.553812] GPMC_CS_CONFIG7_2 : 0f00
 [1.557951] GPMC_CS_CONFIG7_3 : 0c5a

 0x0c5a is an invalid mode !!

 I'm trying to use a 64MB address space but not on a 64MB boundary ... oops.
 
 Good catch. So this is now working for you then?

Not yet ... I got distracted by something else !?!

I'll take another look tomorrow.

Do you think it might be worth adding some sanity checking to the cs config
routines to trap similar errors ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: OMAP: Clear GPMC bits when applying new setting.

[Mark Jackson]

When setting the GPMC device type, make sure any previous
bits are cleared down, before applying the new setting.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
Changes in v2:
- Change mux type to 2 bits
- Add extra mux types in gpmc.h

 arch/arm/mach-omap2/gpmc.c |4 
 arch/arm/mach-omap2/gpmc.h |5 -
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 410e1ba..479369c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -613,6 +613,10 @@ int gpmc_cs_configure(int cs, int cmd, int wval)
 
case GPMC_CONFIG_DEV_TYPE:
regval  = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+   /* clear 4 target bits */
+   regval = ~(GPMC_CONFIG1_DEVICETYPE(3) |
+   GPMC_CONFIG1_MUXTYPE(3));
+   /* set the proper value */
regval |= GPMC_CONFIG1_DEVICETYPE(wval);
if (wval == GPMC_DEVICETYPE_NOR)
regval |= GPMC_CONFIG1_MUXADDDATA;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index fe0a844..f79cbde 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -58,7 +58,10 @@
 #define GPMC_CONFIG1_DEVICESIZE_16  GPMC_CONFIG1_DEVICESIZE(1)
 #define GPMC_CONFIG1_DEVICETYPE(val)((val  3)  10)
 #define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
-#define GPMC_CONFIG1_MUXADDDATA (1  9)
+#define GPMC_CONFIG1_MUXTYPE(val)   ((val  3)  8)
+#define GPMC_CONFIG1_MUXNONMUX  GPMC_CONFIG1_MUXTYPE(0)
+#define GPMC_CONFIG1_MUXAAD GPMC_CONFIG1_MUXTYPE(1)
+#define GPMC_CONFIG1_MUXADDDATA GPMC_CONFIG1_MUXTYPE(2)
 #define GPMC_CONFIG1_TIME_PARA_GRAN (1  4)
 #define GPMC_CONFIG1_FCLK_DIV(val)  (val  3)
 #define GPMC_CONFIG1_FCLK_DIV2  (GPMC_CONFIG1_FCLK_DIV(1))
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash

[Mark Jackson]

On 26/02/13 17:30, Jon Hunter wrote:
 NOR flash is not currently supported when booting with device-tree
 on OMAP2+ devices. Add support to detect and configure NOR devices
 when booting with device-tree.
 
 Add documentation for the TI GPMC NOR binding.
 
 Signed-off-by: Jon Hunter jon-hun...@ti.com

I'm trying to test this series, and am unable get my NOR device recognised.

If I remove all reference to NOR (and keep only my NAND device definition), then
everything seems to boot fine (so I'm assuming I've got at least the basics of
the patch set working).

My GPMC tree looks like this:-

gpmc: gpmc@5000 {
compatible = ti,am3352-gpmc, simple-bus;
ti,hwmods = gpmc;
status = okay;
gpmc,num-waitpins = 2;
pinctrl-names = default;
pinctrl-0 = gpmc_pins;

#address-cells = 2;
#size-cells = 1;
ranges = 0 0 0x0800 0x1000,   /* CS0: NAND 256M */
 3 0 0x1a00 0x0400;   /* CS3: NOR 64M */

nand@0,0 {
linux,mtd-name= micron,mt29f2g08abaea;
reg = 0 0x 0x1000; /* CS0, offset 0 */
nand-bus-width = 8;
ti,nand-ecc-opt = bch8;

gpmc,device-nand;
gpmc,device-width = 1;
gpmc,wait-pin = 0;

gpmc,sync-clk = 0;
gpmc,cs-on = 0;
gpmc,cs-rd-off = 44;
gpmc,cs-wr-off = 44;
gpmc,adv-on = 6;
gpmc,adv-rd-off = 34;
gpmc,adv-wr-off = 44;
gpmc,we-off = 40;
gpmc,oe-off = 54;
gpmc,access = 64;
gpmc,rd-cycle = 82;
gpmc,wr-cycle = 82;
gpmc,wr-access = 40;
gpmc,wr-data-mux-bus = 0;

#address-cells = 1;
#size-cells = 1;
elm_id = elm;

/*
MTD partition table
===
++--0x- SPL start (SPL copy on 
1st block)
||
||--0x0001- SPL end
||--0x0002- SPL.backup1 start (SPL copy on 
2nd block)
||
||--0x0003- SPL.backup1 end
||--0x0004- SPL.backup2 start (SPL copy on 
3rd block)
||
||--0x0005- SPL.backup2 end
||--0x0006- SPL.backup3 start (SPL copy on 
4th block)
||
||--0x0007- SPL.backup3 end
||--0x0008- U-Boot start
||
||--0x001D- U-Boot end
||--0x001E- ENV start
||
||--0x001F- ENV end
||--0x0020- File system start
||
||--0x041F- File system end
||--0x0420- Data storage start
||
++--0x1000- NAND end (Free end)
*/
partition@0 {
label = spl1;
reg = 0x 0x0002; /* 128KB */
};

partition@1 {
label = spl2;
reg = 0x0002 0x0002; /* 128KB */
};

partition@2 {
label = spl3;
reg = 0x0004 0x0002; /* 128KB */
};

partition@3 {
label = spl4;
reg = 0x0006 0x0002; /* 128KB */
};

partition@4 {
label = boot;
reg = 0x0008 0x0016; /* 1408KB */
};

partition@5 {
label = env;
reg = 0x001e 0x0002; /* 128KB */
};

partition@6 {
label = rootfs;
reg = 0x0020 0x0400; /* 64MB */
};

partition@7 {
label = data;
reg = 0x0420 0x0be0; /* 190MB */
};
};

nor@1,0 {
reg = 3 0x 0x0400;
compatible = cfi-flash;
linux,mtd-name = spansion,s29gl064n90t;
bank-width = 2;

gpmc,device-width = 1;
gpmc,mux-add-data;

gpmc,sync-clk = 0;
gpmc,cs-on = 10;
gpmc,cs-rd-off = 150;

Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash

[Mark Jackson]

On 05/03/13 14:46, Jon Hunter wrote:
 
 On 03/05/2013 08:34 AM, Mark Jackson wrote:
 On 26/02/13 17:30, Jon Hunter wrote:
 NOR flash is not currently supported when booting with device-tree
 on OMAP2+ devices. Add support to detect and configure NOR devices
 when booting with device-tree.

 Add documentation for the TI GPMC NOR binding.

 Signed-off-by: Jon Hunter jon-hun...@ti.com

 I'm trying to test this series, and am unable get my NOR device recognised.

 If I remove all reference to NOR (and keep only my NAND device definition), 
 then
 everything seems to boot fine (so I'm assuming I've got at least the basics 
 of
 the patch set working).

 My GPMC tree looks like this:-

snip

  nor@1,0 {
  reg = 3 0x 0x0400;
  compatible = cfi-flash;
  linux,mtd-name = spansion,s29gl064n90t;
  bank-width = 2;

  gpmc,device-width = 1;
 
 Only bank-width should be necessary for NOR (per the binding
 documentation). However, if you do specify both, then they should match.
 Do you have two 8-bits devices? If so may be I need to update the
 documentation to make it clear this is the total width of all devices
 for a given chip-select.

No ... that was wrong, so I've fixed that.

snip

 Booting with this NOR device produces the following oops:-

 [0.00] Booting Linux on physical CPU 0x0
 [0.00] Linux version 3.9.0-rc1-12191-ga00d6d1-dirty 
 (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #33 Tue Mar 5 
 13:08:25 GMT 2013
 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
 cr=10c53c7d

snip

 [0.236730] omap-gpmc 5000.gpmc: could not find pctldev for node 
 /pinmux@44e10800/gpmc_pins, deferring probe
 [0.236781] platform 5000.gpmc: Driver omap-gpmc requests probe 
 deferral
 
 This look like your problem. I would figure out why this is failing and
 try again.

H ... I get this even when I've no NOR device defined and the board boots 
up fine.

But I can see in physmap_of.c that the device gets registered without any call 
to
devm_pinctrl_get_select_default() and hence no probe deferring takes place is 
the
pinctrl device hasn't yet been started (which it hasn't).

Does probe deferral need adding to physmap_of.c, or should the pinctrl device 
really
be registered sooner ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

MTD : Kernel oops when remounting ubifs as read/write

[Mark Jackson]

I'm encountering an oops when remounting my ubifs volume as read/write.

# mount -o remount,rw /
[   89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
[   89.442122] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
(ubifs_write_node+0x180/0x1c4)
[   89.451896] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b3878] 
(ubifs_write_master+0x9c/0x134)
[   89.462018] [c01b3878] (ubifs_write_master+0x9c/0x134) from [c01a79a4] 
(ubifs_remount_fs+0x5d4/0x7f8)
[   89.472133] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
(do_remount_sb+0x98/0x16c)
[   89.481790] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
(do_mount+0x830/0x888)
[   89.490708] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
(sys_mount+0x84/0xb8)
[   89.499178] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
(ret_fast_syscall+0x0/0x3c)
[   89.510997] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
[   89.517884] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
(ubifs_write_node+0x180/0x1c4)
[   89.527641] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b38b4] 
(ubifs_write_master+0xd8/0x134)
[   89.537760] [c01b38b4] (ubifs_write_master+0xd8/0x134) from [c01a79a4] 
(ubifs_remount_fs+0x5d4/0x7f8)
[   89.547869] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
(do_remount_sb+0x98/0x16c)
[   89.557526] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
(do_mount+0x830/0x888)
[   89.566435] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
(sys_mount+0x84/0xb8)
[   89.574905] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
(ret_fast_syscall+0x0/0x3c)
[   89.585939] UBIFS: start fixing up free space
[   89.592237] UBIFS: background thread ubifs_bgt0_0 started, PID 629
[   91.419951] UBIFS: free space fixup complete
#

If it's any help, if the remount is put into my inittab, I don't get any oops.

I've attached my full dmesg log below.

Regards
Mark J.
---
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-next-20130225-dirty (mpfj@mpfj-nanobone) 
(gcc version 4.5.4 (Buildroot 2012.11) ) #24 SMP Mon Mar 4 16:34:01 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI 
AM335x BeagleBone
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c062cd40, node_mem_map 
c0b7f000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] PERCPU: Embedded 9 pages/cpu @c0d89000 s13696 r8192 d14976 u36864
[0.00] pcpu-alloc: s13696 r8192 d14976 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off 
mem=256M rootwait=1 ubi.mtd=6,2048 rootfstype=ubifs root=ubi0:rootfs
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 247020k/247020k available, 15124k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc0570d40   (5540 kB)
[0.00]   .init : 0xc0571000 - 0xc05b7580   ( 282 kB)
[0.00]   .data : 0xc05b8000 - 0xc062ee20   ( 476 kB)
[0.00].bss : 0xc062ee20 - 0xc0b7b0ac   (5425 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 
interrupts
[0.00] Total of 128 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER1 at 2600 Hz
[0.00] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 
165191ms
[0.00] OMAP clocksource: GPTIMER2 at 2600 Hz
[0.00] Console: colour dummy device 80x30
[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., 
Ingo Molnar
[

Re: AM335x pinctrl error -19 (-ENODEV)

[Mark Jackson]

On 01/03/13 05:49, AnilKumar, Chimata wrote:
 On Wed, Feb 27, 2013 at 21:14:25, Mark Jackson wrote:
 I've specified an I2C bus and all 6 UARTs in the dts file for my custom cpu 
 board, as follows:-

  ocp {
  uart1: serial@44e09000 {
  pinctrl-names = default;
 
 Hi Mark,
 
 Specify pinctrl-0 property with pinmux/conf node.
 Refer 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139223.html

Thanks ... I just worked it out myself before your reply.

Regards
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

AM335x pinctrl error -19 (-ENODEV)

[Mark Jackson]

I've specified an I2C bus and all 6 UARTs in the dts file for my custom cpu 
board, as follows:-

ocp {
uart1: serial@44e09000 {
pinctrl-names = default;
status = okay;
};

uart2: serial@48022000 {
pinctrl-names = default;
status = okay;
};

uart3: serial@48024000 {
pinctrl-names = default;
status = okay;
};

uart4: serial@481a6000 {
pinctrl-names = default;
status = okay;
};

uart5: serial@481a8000 {
pinctrl-names = default;
status = okay;
};

uart6: serial@481aa000 {
pinctrl-names = default;
status = okay;
};

i2c1: i2c@44e0b000 {
status = okay;
pinctrl-names = default;
clock-frequency = 40;

gpio@20 {
compatible = mcp,mcp23017;
reg = 0x20;
};

tps: tps@24 {
reg = 0x24;
};

eeprom@53 {
compatible = mcp,24c02;
reg = 0x53;
pagesize = 8;
};

rtc@68 {
compatible = dallas,ds1307;
reg = 0x68;
};
};
};

But I get the following errors in the kernel boot log:-

[0.409275] omap_i2c 44e0b000.i2c: did not get pins for i2c error: -19
[0.411498] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[0.413235] mcp230xx: probe of 0-0020 failed with error -22
...
[0.716912] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[0.721790] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[0.729174] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[0.729833] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP 
UART0
[1.320105] console [ttyO0] enabled
[1.326050] omap_uart 48022000.serial: did not get pins for uart1 error: -19
[1.334384] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP 
UART1
[1.344362] omap_uart 48024000.serial: did not get pins for uart2 error: -19
[1.352281] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is a OMAP 
UART2
[1.361721] omap_uart 481a6000.serial: did not get pins for uart3 error: -19
[1.369759] 481a6000.serial: ttyO3 at MMIO 0x481a6000 (irq = 60) is a OMAP 
UART3
[1.379144] omap_uart 481a8000.serial: did not get pins for uart4 error: -19
[1.387008] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP 
UART4
[1.396302] omap_uart 481aa000.serial: did not get pins for uart5 error: -19
[1.404164] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62) is a OMAP 
UART5

However, the I2C bus appears to be working okay, as later I get:-

[1.906072] rtc-ds1307 0-0068: rtc core: registered ds1307 as rtc0
[1.912767] rtc-ds1307 0-0068: 56 bytes nvram
...
[2.118207] rtc-ds1307 0-0068: setting system clock to 2013-01-22 20:28:37 
UTC (1358886517)

I did try specifying the exact pins required in the am33xx_pinmux dts entry, 
but I got an error
stating the pins were already allocated to their relevant devices.

Any ideas ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

AM335x mpurate + bogomips

[Mark Jackson]

Before I dig any deeper, can anyone tell me if the bootarg mpurate is meant to
be supported for AM335x SoCs ?

I've tried it on our custom board using 3v8, but no joy.

The boot log shows:-

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-03059-g621553c-dirty (mpfj@mpfj-nanobone) 
(gcc version 4.5.4 (Buildroot 2012.11) ) #113 SMP Thu Feb 21 16:29:48 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow 
NanoBone
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
...
[0.00] Kernel command line: console=ttyO0,115200n8 mpurate=720 
root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait
...
[0.001119] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408)

I have seen other boot logs outputs [1] from other people where they are 
getting nearly double that.

Looking at omap2xxx_clk_arch_init(), only ompa24xx devices are supported.

Am I missing something obvious (like it's not yet supported !!) ?

Cheers
Mark J.

[1] http://e2e.ti.com/support/embedded/linux/f/354/t/245316.aspx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

AM335x : placing NAND @ address 0x0

[Mark Jackson]

I'm hitting an issue where I want to register my GPMC connected NAND on CS0 at 
address 0x0.

Here's the relevant error from the boot messages:-

[0.293834] omap-gpmc gpmc.3: GPMC revision 6.0
[0.294175] omap-gpmc gpmc.3: failed to reserve memory
[0.294267] omap-gpmc: probe of gpmc.3 failed with error -16

The chip select and base address have already been setup under U-Boot and it 
appears to work fine
(i.e. U-Boot can see the device).

Am I not allowed to place the NAND at address 0x0 ?  If not, why not ?

The GPMC section of my .dts file is shown below.

Cheers
Mark J.

---
gpmc: gpmc@5000 {
compatible = ti,am3352-gpmc, simple-bus;
ti,hwmods = gpmc;
status = okay;
#address-cells = 2;
#size-cells = 1;
ranges = 0 0 0x0100 0x1000;   /* CS0: NAND 
256M */

nand@0,0 {
reg = 0 0 0x1000; /* CS0, offset 0 */
nand-bus-width = 8;
ti,nand-ecc-opt = bch8;

gpmc,sync-clk = 0;
gpmc,cs-on = 0;
gpmc,cs-rd-off = 44;
gpmc,cs-wr-off = 44;
gpmc,adv-on = 6;
gpmc,adv-rd-off = 34;
gpmc,adv-wr-off = 44;
gpmc,we-off = 40;
gpmc,oe-off = 54;
gpmc,access = 64;
gpmc,rd-cycle = 82;
gpmc,wr-cycle = 82;
gpmc,wr-access = 40;
gpmc,wr-data-mux-bus = 0;

#address-cells = 1;
#size-cells = 1;
elm_id = elm;

/* MTD partition table */
partition@1 {
label = boot;
reg = 0x 0x0010; /* 1MB */
};

partition@2 {
label = rootfs;
reg = 0x0010 0x0400; /* 64MB 
*/
};

partition@3 {
label = data;
reg = 0x0410 0x0bf0; /* 191MB 
*/
};
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x : placing NAND @ address 0x0

[Mark Jackson]

On 14/02/13 11:59, Mark Jackson wrote:
 I'm hitting an issue where I want to register my GPMC connected NAND on CS0 
 at address 0x0.

Just found the existing thread that already covers this.

Sorry for the noise.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DT GPMC SRAM and NOR flash support ?

[Mark Jackson]

Okay ... I have made some progress, but it's not ideal.

Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now 
handles setting up the
chip selects and timings for NOR devices, e.g.

gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800;   /* CS0: NOR 16M 
*/

nor@0,0 {
compatible = spansion,s29gl064n90t, 
cfi-flash;
reg = 0 0 0;
bank-width = 2;

gpmc,sync-clk = 0;
gpmc,cs-on = 10;
gpmc,cs-rd-off = 150;
gpmc,cs-wr-off = 150;
gpmc,adv-on = 10;
gpmc,adv-rd-off = 10;
gpmc,adv-wr-off = 10;
gpmc,oe-on = 30;
gpmc,oe-off = 150;
gpmc,we-on = 30;
gpmc,we-off = 150;
gpmc,rd-cycle = 150;
gpmc,wr-cycle = 150;
gpmc,access = 130;
gpmc,page-burst-access = 10;
gpmc,cycle2cycle-diff = 1;
gpmc,cycle2cycle-same = 1;
gpmc,cycle2cycle-delay = 10;
gpmc,wr-data-mux-bus = 60;
};
};

But the physmap driver (of_flash_probe()) is unable to use this information.  
It seems that although
I can call of_flash_probe() from my NOR setup code, the platform_device being 
reference is wrong.

The platform_device passed to my gpmc_probe_nor_child() routine from 
gpmc_probe_dt() points to my
gpmc entry (above), but the physmap probe requires its own DT entry (rather 
than a node child such
as my NOR entry with the GPMC device entry).

So I need to have any extra entry in the DT file as follows:-

nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};

So the GPMC entry handles all the chip select and timing setup, but the 2nd 
entry is the only one
the physmap driver can see.

Would it be acceptable to re-code of_flash_probe() to allow either a child 
device_node to be passed
or a platform_device ?

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DT GPMC SRAM and NOR flash support ?

[Mark Jackson]

On 07/02/13 09:51, Mark Jackson wrote:
 Okay ... I have made some progress, but it's not ideal.

snip

 But the physmap driver (of_flash_probe()) is unable to use this information.  
 It seems that although
 I can call of_flash_probe() from my NOR setup code, the platform_device being 
 reference is wrong.
 
 The platform_device passed to my gpmc_probe_nor_child() routine from 
 gpmc_probe_dt() points to my
 gpmc entry (above), but the physmap probe requires its own DT entry (rather 
 than a node child such
 as my NOR entry with the GPMC device entry).
 
 So I need to have any extra entry in the DT file as follows:-
 
   nor-flash@0800 {
   compatible = spansion,s29gl064n90t, cfi-flash;
   reg = 0x0800 0x0080;
   bank-width = 2;
   };
 
 So the GPMC entry handles all the chip select and timing setup, but the 2nd 
 entry is the only one
 the physmap driver can see.
 
 Would it be acceptable to re-code of_flash_probe() to allow either a child 
 device_node to be passed
 or a platform_device ?

Or is it acceptable to simply state the gpmc portion is for setting up the chip 
access, and you *do*
need a separate physmap section ?

That's certainly easier, and it works without any changes to the physmap driver.

Regards
Mark J.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP: Clear GPMC bits when applying new setting

[Mark Jackson]

When setting the GPMC device type, make sure any previous
bits are cleared down, before applying the new setting.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 arch/arm/mach-omap2/gpmc.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1adb2d4..026e786 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -613,6 +613,10 @@ int gpmc_cs_configure(int cs, int cmd, int wval)

case GPMC_CONFIG_DEV_TYPE:
regval  = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+   /* clear 3 target bits */
+   regval = ~(GPMC_CONFIG1_DEVICETYPE(3) |
+   GPMC_CONFIG1_MUXADDDATA);
+   /* set the proper value */
regval |= GPMC_CONFIG1_DEVICETYPE(wval);
if (wval == GPMC_DEVICETYPE_NOR)
regval |= GPMC_CONFIG1_MUXADDDATA;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DT GPMC SRAM and NOR flash support ?

[Mark Jackson]

On 01/02/13 19:39, Mark Jackson wrote:
 On 01/02/13 17:12, Jon Hunter wrote:
 Hi Mark,

 On 02/01/2013 10:56 AM, Mark Jackson wrote:
 There's plenty of DT support going in for NAND flash, but is there any work 
 going on to support NOR
 flash ?

 What board and device are you working that is using NOR? I have a
 OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but
 I don't spend much time on it. Eventually it will have to be done but it
 is always good to know if there is a pressing need.
 
 We have a custom AM335x CPU board (arriving on my desk within the next few 
 weeks) that has both NAND
 and NOR Flash.
 
 And how about SRAM chips or other memory mapped devices ?

 Not sure about SRAM (trying to think if I have a board with SRAM even),
 but definitely, boards using the GPMC to interface to ethernet chips
 need to be added.
 
 The board also contains an FRAM chip (which is just treated as SRAM).
 
 If you'd anything in the pipeline, I'm glad to help in any testing. I've 
 created a custom cape board
 for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not 
 waiting for the new
 hardware to arrive.

I've experimented with trying to add a mtd-physmap device, but no joy.

I'm guessing that the current mtd-physmap code is (in some way) currently 
incompatible with the GPMC
device ?

Mark J.


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DT GPMC SRAM and NOR flash support ?

[Mark Jackson]

On 05/02/13 16:35, Jon Hunter wrote:
 
 On 02/05/2013 10:16 AM, Mark Jackson wrote:
 On 01/02/13 19:39, Mark Jackson wrote:
 On 01/02/13 17:12, Jon Hunter wrote:
 Hi Mark,

 On 02/01/2013 10:56 AM, Mark Jackson wrote:
 There's plenty of DT support going in for NAND flash, but is there any 
 work going on to support NOR
 flash ?

 What board and device are you working that is using NOR? I have a
 OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but
 I don't spend much time on it. Eventually it will have to be done but it
 is always good to know if there is a pressing need.

 We have a custom AM335x CPU board (arriving on my desk within the next few 
 weeks) that has both NAND
 and NOR Flash.

 And how about SRAM chips or other memory mapped devices ?

 Not sure about SRAM (trying to think if I have a board with SRAM even),
 but definitely, boards using the GPMC to interface to ethernet chips
 need to be added.

 The board also contains an FRAM chip (which is just treated as SRAM).

 If you'd anything in the pipeline, I'm glad to help in any testing. I've 
 created a custom cape board
 for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not 
 waiting for the new
 hardware to arrive.
 
 Sorry for the delay. I personally don't have anything in the pipe.
 
 Afzal, do you know of anyone looking at this?
 
 I've experimented with trying to add a mtd-physmap device, but no joy.

 I'm guessing that the current mtd-physmap code is (in some way) currently 
 incompatible with the GPMC
 device ?
 
 I am not familiar with mtd-physmap to comment. Is that DT specific?

Well, it's documented in Documentation/devicetree/bindings/mtd/mtd-physmap.txt, 
showing you can
specify cfi-flash or mtd-ram devices, eg (taken from mtd-physmap.txt):-

flash@ff00 {
compatible = amd,am29lv128ml, cfi-flash;
reg = ff00 0100;
bank-width = 4;
device-width = 1;
#address-cells = 1;
#size-cells = 1;
fs@0 {
label = fs;
reg = 0 f8;
};
firmware@f8 {
label =firmware;
reg = f8 8;
read-only;
};
};

sram@2,0 {
compatible = samsung,k6f1616u6a, mtd-ram;
reg = 2 0 0x0020;
bank-width = 2;
};

But I guess the GPMC needs to be configured to enable chip selects, data 
widths, etc.

I did get *something* on the address / data bus by adding the patches below, 
but I'm getting bus
contention, so something else needs setting up in the GPMC.

I'm no great device driver writer, but if anyone can give me some pointers, I'm 
happy to keep digging.

Cheers
Mark J.

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a37e1c9..8f45d18 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1265,10 +1265,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
struct device_node *child;
const struct of_device_id *of_id =
of_match_device(gpmc_dt_ids, pdev-dev);
+   unsigned long base;

if (!of_id)
return 0;

+   gpmc_cs_request(0, SZ_16M, base);
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
of_node_put(child);
diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..ad89446 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -26,7 +26,7 @@

am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
-   pinctrl-0 = user_leds_s0;
+   pinctrl-0 = user_leds_s0 gpmc_pins_s0;

user_leds_s0: user_leds_s0 {
pinctrl-single,pins = 
@@ -36,6 +36,49 @@
0x60 0x17   /* gpmc_a8.gpio1_24, 
OUTPUT_PULLUP | MODE7 */
;
};
+
+   gpmc_pins_s0: gpmc_pins_s0 {
+   pinctrl-single,pins = 
+   0x0 0x30/* gpmc_ad0.gpmc_ad0, INPUT | 
PULLUP | MODE0 */
+   0x4 0x30/* gpmc_ad1.gpmc_ad1, INPUT | 
PULLUP | MODE0 */
+   0x8 0x30/* gpmc_ad2.gpmc_ad2, INPUT | 
PULLUP | MODE0 */
+   0xc 0x30/* gpmc_ad3.gpmc_ad3, INPUT | 
PULLUP | MODE0 */
+   0x10 0x30   /* gpmc_ad4.gpmc_ad4, INPUT | 
PULLUP | MODE0 */
+   0x14 0x30   /* gpmc_ad5.gpmc_ad5, INPUT | 
PULLUP | MODE0 */
+   0x18 0x30   /* gpmc_ad6.gpmc_ad6, INPUT | 
PULLUP | MODE0 */
+   0x1c 0x30   /* gpmc_ad7

DT GPMC SRAM and NOR flash support ?

[Mark Jackson]

There's plenty of DT support going in for NAND flash, but is there any work 
going on to support NOR
flash ?

And how about SRAM chips or other memory mapped devices ?

Regards
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DT GPMC SRAM and NOR flash support ?

[Mark Jackson]

On 01/02/13 17:12, Jon Hunter wrote:

Hi Mark,

On 02/01/2013 10:56 AM, Mark Jackson wrote:

There's plenty of DT support going in for NAND flash, but is there any work 
going on to support NOR
flash ?


What board and device are you working that is using NOR? I have a
OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but
I don't spend much time on it. Eventually it will have to be done but it
is always good to know if there is a pressing need.


We have a custom AM335x CPU board (arriving on my desk within the next 
few weeks) that has both NAND and NOR Flash.



And how about SRAM chips or other memory mapped devices ?


Not sure about SRAM (trying to think if I have a board with SRAM even),
but definitely, boards using the GPMC to interface to ethernet chips
need to be added.


The board also contains an FRAM chip (which is just treated as SRAM).

If you'd anything in the pipeline, I'm glad to help in any testing. 
I've created a custom cape board for the BeagleBone which contains the 
NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive.


Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ARM: OMAP2+: omap2plus_defconfig: enable omap1 rtc

[Mark Jackson]

The BeagleBone dev kit uses the built-in RTC module, so
it would be nice to have this built by default in the
omap2plus defconfig.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 arch/arm/configs/omap2plus_defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 82ce8d7..d852775 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -199,6 +199,7 @@ CONFIG_MMC_OMAP_HS=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_TWL92330=y
 CONFIG_RTC_DRV_TWL4030=y
+CONFIG_RTC_DRV_OMAP=y
 CONFIG_DMADEVICES=y
 CONFIG_DMA_OMAP=y
 CONFIG_EXT2_FS=y
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.8-rc5

[Mark Jackson]

On 28/01/13 10:34, Mohammed, Afzal wrote:
 Hi,
 
 On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote:
 On Sat, Jan 26, 2013 at 08:40:07AM +, Paul Walmsley wrote:
 
 * am335xbone: hangs after Starting kernel
   - Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
   - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html
   - http://marc.info/?l=linux-omapm=135903184512238w=2

 FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
 without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
 to help my bone, no matter if I had appended DTB or not.
 
 Following patch with low level debug may help to find where the issue is,
 (my observation is that it boots with mainline u-boot)
 
 Regards
 Afzal
 
 
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index 41b581f..178a411 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -117,6 +117,10 @@ config SOC_AM33XX
 select CPU_V7
 select MULTI_IRQ_HANDLER
 select COMMON_CLK
 +   select MACH_AM335XEVM
 +
 +config MACH_AM335XEVM
 +   bool
 
  config OMAP_PACKAGE_ZAF
 bool
 

I can confirm that this patch works with EARLY_PRINTK and DEBUG_LL enabled 
(current mainline kernel
and u-boot), and the following .config changes:-

$ diff .config.omap2plus_defconfig .config
505c505,508
 # CONFIG_ARM_APPENDED_DTB is not set
---
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
 # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
2659c2662,2665
 # CONFIG_DEBUG_LL is not set
---
 CONFIG_DEBUG_LL=y
 CONFIG_DEBUG_LL_UART_NONE=y
 # CONFIG_DEBUG_ICEDCC is not set
 # CONFIG_DEBUG_SEMIHOSTING is not set
2660a2667
 CONFIG_EARLY_PRINTK=y

Boot log

Filename '/nanobone/uImage-dtb'.
Load address: 0x8000
Loading: #
 #
 #
 #
 #
 627 KiB/s
done
Bytes transferred = 3946799 (3c392f hex)
## Booting kernel from Legacy Image at 8000 ...
   Image Name:   Linux 3.8.0-rc5-dirty
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3946735 Bytes = 3.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-rc5-dirty (mpfj@mpfj-nanobone) (gcc version 
4.5.4 (Buildroot
2012.11-git-00497-ge48bf89) ) #9 SMP Mon Jan 28 11:34:19 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI 
AM335x BeagleBone
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c07c7040, node_mem_map 
c0d27000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 64768 pages, LIFO batch:15
[0.00] AM335X ES1.0 (neon )
[0.00] PERCPU: Embedded 9 pages/cpu @c0f3 s12992 r8192 d15680 u36864
[0.00] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 earlyprintk debug 
root=/dev/mmcblk0p2 ro
rootfstype=ext2 rootwait

snip

[1.702800] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, 
driver SMSC LAN8710/LAN8720
[1.713088] Random MACID = 56:e9:38:ee:af:e4
[1.723695] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[1.735470] Waiting for root device /dev/mmcblk0p2...

Still no support for rootfs on MMC, but hopefully that won't be long ??

Regards
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.8-rc4

[Mark Jackson]

On 22/01/13 18:23, Tony Lindgren wrote:
 * Mark Jackson mpfj-l...@mimc.co.uk [130122 05:46]:
 On 22/01/13 13:32, Bedia, Vaibhav wrote:

 snip

 Following works for me:

 Kernel
 ===
 git checkout next-20130122
 make distclean
 make omap2plus_defconfig
 Enable the appended DTB related options via menuconfig
 make -j7
 cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb  
 arch/arm/boot/zImage-dtb.am335x-bone
 mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 
 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone 
 arch/arm/boot/uImage-dtb.am335x-bone

 U-Boot
 ===
 Built from v2013.01

 snip

 A dumb question... in your case what's the bootargs set? Note that the 
 mainline
 kernel for AM335x doesn't have MMC support yet and the default bootargs is 
 set to
 rootfs on MMC.

 Yes ... I'm trying to boot from a rootfs on MMC:-

 Kernel command line: console=ttyO0,115200n8 earlyprintk debug 
 root=/dev/mmcblk0p2 ro rootfstype=ext2
 rootwait

 But I should get *something* from the kernel before it starts trying to 
 access the rootfs ?
 
 Here's something Kevin fixed but did not send it out before going to
 a vacation. Can you give it a try with earlyprintk enabled?
 
 Note that this does not help with no output early on, that sounds
 like a bug configuring the DEBUG_LL port somewhere.
 
 Regards,
 
 Tony
 
 
 
 From: Kevin Hilman khil...@deeprootsystems.com
 Date: Tue, 15 Jan 2013 14:12:24 -0800
 Subject: [PATCH] Fix omap_serial as module with debug_ll and earlyprintk
 
 Otherwise we can race with the earlyconsole getting turned off
 which can cause a non-booting system with earlyprintk enabled.
 
 [t...@atomide.com: updated description]
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 ---
 
 Kevin, can I add your Signed-off-by to this one?
 
 --- a/arch/arm/mach-omap2/omap_device.c
 +++ b/arch/arm/mach-omap2/omap_device.c
 @@ -1298,4 +1298,4 @@ static int __init omap_device_late_init(void)
   bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle);
   return 0;
  }
 -omap_late_initcall(omap_device_late_init);
 +late_initcall_sync(omap_device_late_init);
 

Sorry ... still no joy:-

U-Boot# askenv bootargs
Please enter 'bootargs':ttyO0,115200n8 earlyprintk root=/dev/mmcblk0p2 ro 
rootfstype=ext2 rootwait
U-Boot# dhcp 8000 10.0.0.100:/nanobone/uImage-dtb;bootm 8000
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
DHCP client bound to address 10.0.0.112
Using cpsw device
TFTP from server 10.0.0.100; our IP address is 10.0.0.112
Filename '/nanobone/uImage-dtb'.
Load address: 0x8000
Loading: #
 #
 #
 #
 ###
 625 KiB/s
done
Bytes transferred = 3972199 (3c9c67 hex)
## Booting kernel from Legacy Image at 8000 ...
   Image Name:   Linux 3.8.0-rc3-12154-gac00f0e-d
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3972135 Bytes = 3.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

My .config can be found at http://pastebin.com/rj5ptt7W

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html