phytec-som-imx6: DCD setup: PLL reduction and video core settings

2016-02-19 Thread Andreas Pretzsch
While looking into a maybe boarderline RAM setup on one specific piece
of hardware, I took a closer look at the i.MX6 DDR setup of the Phytec
i.MX6 modules in barebox.
And came across two things that look ... somewhat questionable, maybe
worth a look.

In the very first setup (the DCD) in
arch/arm/boards/phytec-som-imx6/flash-header-phytec-pfla02.h
there is a block
wm 32 0x020e0010 0xf0ff
wm 32 0x020e0018 0x007F007F
wm 32 0x020e001c 0x007F007F
wm 32 0x020c8000 0x80002021
at the end.


The first three (comments about complete register meanings added by me)
// IOMUX_GPR4 : VDOA, PCIe, VPU, IPU cache setup ; stop acknowledge
wm 32 0x020e0010 0xf0ff
// IOMUX_GPR6 : IPU1 QoS setup
wm 32 0x020e0018 0x007F007F
// IOMUX_GPR7 : IPU2 QoS setup
wm 32 0x020e001c 0x007F007F
do setup some cache attributes of VDOA, IPU, VPU (some of the video
cores) and IPU QoS. Beside accessing two reserved bits in GPR4, they
maybe do not harm, and can be found also in various other board files.
Might be some case of copy-from-copy, no idea.
Not sure if these really should be part of lowest-level memory setup...
Maybe - if at all - in some board-specific setup, given barebox drives a
display.
Also, a quick google search shows the possible origin, and that it has
been removed in some U-Boot branch, leaving it to the Linux kernel:
https://github.com/linksprite/u-boot-acadia1.0-beta/blob/master/u-boot-acadia1.0-beta/patches/0546-ENGR00215515-MX6-Move-IPU-QoS-and-VDOA-IPU-VPU-AXI-C.patch
So maybe more of a cleanup issue.
Not only in the Phytec DCDs, but maybe also the other ones.


What concerns me more is the CPU core clock reduction:
// CCM_ANALOG_PLL_ARM0 : PLL setup => PLL locked, PLL on,
//   bypass off, 396MHz
// reset default: 0x00013042 => PLL not locked, PLL off, bypass on,
//  bypass 24MHz osc as src, pll divider
//  for 792MHz
// 0x80002021 => PLL locked, PLL on, bypass off, pll divider for
//   396MHz ; Attn.: PLL locked is w/o ; divider for
//   396MHz is below valid range
wm 32 0x020c8000 0x80002021
Comments again added by me.

Two things here look questionable to me:
1.) Datasheet says valid divider values are 54-108, so the
default 0x42=66 is in range, whereas the 0x21=33 is not.
2.) Even if the divider value is legit, the change flow might be not.
A PLL normally takes some time to lock.

Now, I have not looked yet at the PLL setup and/or scaling code of the
kernel, both wrt PLL change flow as well as dividers. So this might be
ok, and even if only implicitly (like due to some implicit delay after
DCD got parsed).
And obviously it works. "Only" misses a comment whats it does. And only
present in some of the Phytec DCDs, as far as I can see.

But what I like to understand is why ?
I mean, scaling down the i.MX6 to its minimum frequency (half of
default) in the bootloader, to get a maximum stable state, ok. Even if
it extends the bootup time.

But why after all the IOMUX, MMDC and DDR setup is through ?
Probably too late if it is about some PMIC-reset-voltage-scaling issue.
Or some thermal precaution ?

By the way, the above setups goes back through long history, as in
a540c30 boards: Add phytec-som-imx6
c5b4f09 ARM:phyFLEX-iMX6 New Ram Timings for Q/DL
30f29e3 ARM: Add Phytec phyFLEX-i.MX6 board support
and applies to other Phytec i.MX6 boards as well, beside the DL ones.


Any comments on this, maybe also from Phytec ?

Best regards,
  Andreas Pretzsch

-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas PretzschTel. +49-(0)7307-936088-1
Lange Strasse 28a   Fax: +49-(0)7307-936088-9
89250 Senden, Germany   email: a...@cn-eng.de


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


barebox-state (dt-utils): dump-shell broken for state@0

2016-04-04 Thread Andreas Pretzsch
On Mi, 2015-06-17 at 11:06 +0200, Sascha Hauer wrote:
> On Wed, Jun 17, 2015 at 08:42:50AM +0200, Jan Remmet wrote:
> > Hello,
> > I'm working with barebox states and wonder if there is already a tool to 
> > access
> > states in eeprom from linux?
> > The states from a dtb backend should be easy to read. For raw there must be
> > looked under /proc/devicetree or a state kernel driver.
> 
> Yes, there is such a tool here:
> 
> git://git.pengutronix.de/git/tools/dt-utils.git
> 
> The binary you'll need is barebox-state.

barebox-state provides a command "--dump-shell" to dump the state
suitable for shell sourcing.
Essentially, it prints out variable=value pairs.
So typical use would be a
eval `barebox-state --dump-shell`
somewhere in a shell script (incl. simple ones like busybox ash).

Unfortunately, this breaks with indices in the state name, as @ is not
escaped.
Tested with dt-utils v2015.10.0, but according to code this is the case
from v2015.05.0 up until master.

As of commit 6d58ca4 "barebox-state: fix export of shell variables:",
the fixed prefix "STATE_" was replaced by the supplied state name.
Also in there, all '.' are replaced by '_' in the variable name. Not in
the state name itself.

The same would be necessary for (at least) '@', because it is invalid
also inside a shell variable name. As probably other chars, just I'm not
sure which might show up from the dts. So no premature patch from my
side.
Not only for the variable name, but also the state name itself.

For clarification of the setup and behaviour, see below.


Now, question would be how to fix this.
Also replacing '@' by '_' might break existing users (e.g. when parsing
from stdin or similar, instead of using shells eval command).
On the other hand, status quo breaks the "described" use of dump
_shell_ ...

Talking about this, it might be also some idea to resurrect the old
behaviour of always printing 'STATE_' as prefix instead of the state
name from dts. Not sure if it's the best idea, or how to call such an
extra option, didn't think it through by now.
Just saying, as I will go this way here (as a hotfix) for my setup...

Ideas, opinions ?

Best regards,
  Andreas




Having a dts definition (according to documentation) like

state: state@0 {
[...]
active_firmware_slot@0 {
[...]
};
[...]
};

this results in

# barebox-state -vv
found state node /state@0:
state@0 {
[...]
active_firmware_slot@0 {
[...]
}
[...]
}

# barebox-state --dump-shell
load successful
state@0_active_firmware_slot="slot1"
[...]

# eval `barebox-state --dump-shell`
load successful
-sh: eval: state@0_active_firmware_slot=slot1: not found


With attached (quick and dirty) patch, this would look like:

# barebox-state --dump-shell
load successful
state_0_active_firmware_slot="slot1"
[...]


Regarding these changes, some free() for the strdup might be nice,
albeit not really necessary, as main ends anyway soon.

Last IMHO, loglevel without passing verbose as parameter should be
reduced, resp. 'dev_info(&state->dev, "load successful\n");' should be
taken down in level. To stay silent if nothing went wrong, in good unix
tradition.


-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas PretzschTel. +49-(0)7307-936088-1
Lange Strasse 28a   Fax: +49-(0)7307-936088-9
89250 Senden, Germany   email: a...@cn-eng.de
diff --git a/src/barebox-state.c b/src/barebox-state.c
index bc1010e..b7b6c03 100644
--- a/src/barebox-state.c
+++ b/src/barebox-state.c
@@ -2129,17 +2129,22 @@ int main(int argc, char *argv[])
 	if (do_dump_shell) {
 		state_for_each_var(state, v) {
 			struct variable_type *vtype;
-			char *name, *ptr;
+			char *statename, *name, *ptr;
 			int i;
 
-			/* replace "." by "_" to make it var name shell compatible */
+			/* replace "." by "_" to make the var name shell compatible */
 			name = strdup(v->name);
 			ptr = name;
 			while ((ptr = strchr(ptr, '.')))
 *ptr++ = '_';
+			/* replace "@" by "_" to make the state name shell compatible */
+			statename = strdup(state->name);
+			ptr = statename;
+			while ((ptr = strchr(ptr, '@')))
+*ptr++ = '_';
 
 			vtype = state_find_type(v->type);
-			printf("%s_%s=\"%s\"\n", state->name, name, vtype->__get(v));
+			printf("%s_%s=\"%s\"\n", statename, name, vtype->__get(v));
 		}
 	}
 
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


[PATCH 1/2] ARM i.MX31: cleanup MX31_ prefix: fix leftover IOMUXC_BASE defines

2013-05-06 Thread Andreas Pretzsch
The prefix/cleanup series
ad09b59f8bb58c27e3872b41f41beb1b9eb1aeb1
a8c6359667704ffc3bd2249dd76f3fbbb2134b55
4c53af062b38f15f6bc40c586e5760e640f5b8b1
missed a few unprefixed IOMUXC_BASE define users. Fix these.

Signed-off-by: Andreas Pretzsch 
---
 arch/arm/mach-imx/include/mach/imx31-regs.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/include/mach/imx31-regs.h 
b/arch/arm/mach-imx/include/mach/imx31-regs.h
index be3e4c1..599f800 100644
--- a/arch/arm/mach-imx/include/mach/imx31-regs.h
+++ b/arch/arm/mach-imx/include/mach/imx31-regs.h
@@ -162,9 +162,9 @@
 #define MX31_PDR0_MAX_PODF(x)  (((x) & 0x7) << 3)
 #define MX31_PDR0_MCU_PODF(x)  ((x) & 0x7)
 
-#define MX31_IOMUXC_GPR(IOMUXC_BASE + 0x8)
-#define MX31_IOMUXC_SW_MUX_CTL(x)  (IOMUXC_BASE + 0xc + (x) * 4)
-#define MX31_IOMUXC_SW_PAD_CTL(x)  (IOMUXC_BASE + 0x154 + (x) * 4)
+#define MX31_IOMUXC_GPR(MX31_IOMUXC_BASE_ADDR + 0x8)
+#define MX31_IOMUXC_SW_MUX_CTL(x)  (MX31_IOMUXC_BASE_ADDR + 0xc + (x) * 4)
+#define MX31_IOMUXC_SW_PAD_CTL(x)  (MX31_IOMUXC_BASE_ADDR + 0x154 + (x) * 
4)
 
 /*
  * Signal Multiplexing (IOMUX)
-- 
1.7.10.4


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


[PATCH 0/2] ARM i.MX31: define fix, IOMUX GPR setup fix for pcm037

2013-05-06 Thread Andreas Pretzsch
Patches against tag v2013.05.0.
Functionality tested on customer-specific pcm037 variant with 2013.03.0.
Compile-tested against pcm037_defconfig with 2013.05.0.
Relevant code base is unchanged between versions, no issues expected.

Andreas Pretzsch (2):
  ARM i.MX31: cleanup MX31_ prefix: fix leftover IOMUXC_BASE defines
  ARM i.MX31 pcm037: fix erroneous IOMUX GPR setup in pcm037_usb_init()

 arch/arm/boards/pcm037/pcm037.c |6 +++---
 arch/arm/mach-imx/include/mach/imx31-regs.h |6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
1.7.10.4


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


[PATCH 2/2] ARM i.MX31 pcm037: fix erroneous IOMUX GPR setup in pcm037_usb_init()

2013-05-06 Thread Andreas Pretzsch
In commit ad09b59f8bb58c27e3872b41f41beb1b9eb1aeb1 "ARM i.MX31: give
register base addresses a proper MX31_ prefix", the IOMUX GPR setup
to enable USBH2 was replaced with an incorrect source register.
Instead of reading the GPR register, USBOTG HWHOST is used as rmw source,
which contains 0x10020001.
Beside the intended GPR[11] setup ("Enable USBH2 signals on AudioPort 3 and
AudioPort6"), this erroneously also sets
GPR[28] enable USBOTG loopback
GPR[17] override DSR_DCE1 with USBOTG_DATA4
GPR[0]  select FIR DMA requests instead of UART2 DMA

Beside breaking UART2, it probably also broke some UART1 and USB OTG setups.
Fix this and replace the address with the appropriate defines.

Signed-off-by: Andreas Pretzsch 
---
 arch/arm/boards/pcm037/pcm037.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boards/pcm037/pcm037.c b/arch/arm/boards/pcm037/pcm037.c
index 276f9cd..9361a9d 100644
--- a/arch/arm/boards/pcm037/pcm037.c
+++ b/arch/arm/boards/pcm037/pcm037.c
@@ -83,9 +83,9 @@ static void pcm037_usb_init(void)
ulpi_setup((void *)(MX31_USB_OTG_BASE_ADDR + 0x170), 1);
 
/* Host 2 */
-   tmp = readl(MX31_USB_OTG_BASE_ADDR + 0x8);
-   tmp |= 1 << 11;
-   writel(tmp, MX31_IOMUXC_BASE_ADDR + 0x8);
+   tmp = readl(MX31_IOMUXC_GPR);
+   tmp |= 1 << 11; /* IOMUX GPR: enable USBH2 signals */
+   writel(tmp, MX31_IOMUXC_GPR);
 
imx_iomux_mode(IOMUX_MODE(MX31_PIN_USBH2_CLK, IOMUX_CONFIG_FUNC));
imx_iomux_mode(IOMUX_MODE(MX31_PIN_USBH2_DIR, IOMUX_CONFIG_FUNC));
-- 
1.7.10.4


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


[PATCH] mdiobus: unbreak phy_device_connect() "scan all PHY addresses" feature

2012-11-06 Thread Andreas Pretzsch
Calling phy_device_connect() with a PHY address of -1 will scan for a PHY
in the address range of 0..PHY_MAX_ADDR and registers the first one found.
This was broken by commit 09254f639c94cc7dc47fff7638dc8c7f88d700b1
"mdiobus: do not scan the bus at registration time", erroneously scanning
for -1 as PHY address.

Signed-off-by: Andreas Pretzsch 
---
patch against branch "next" / commit 129300139cbe7265c4b8b4142740c59b5b997e4d

 drivers/net/phy/phy.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 8d36300..547e269 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -169,7 +169,7 @@ int phy_device_connect(struct eth_device *edev, struct 
mii_bus *bus, int addr,
goto fail;
} else {
for (i = 0; i < PHY_MAX_ADDR && !edev->phydev; i++) {
-   dev = mdiobus_scan(bus, addr);
+   dev = mdiobus_scan(bus, i);
if (!dev || dev->attached_dev)
continue;
 
-- 
1.7.10.4


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


[PATCH] mdiobus: unbreak phy_device_connect(): honor masked out PHYs

2012-11-07 Thread Andreas Pretzsch
commit 89dfe2d2af87f1b803f611d986d4ef383b6ad964 "mdiobus: do not scan
the bus at registration time" dropped the check for struct mii_bus
element phy_mask while scanning through all addresses.
Re-add this check.

Signed-off-by: Andreas Pretzsch 
---
patch against branch "next" / commit 89dfe2d2af87f1b803f611d986d4ef383b6ad964
Another one to fold into original patch. Sorry for missing it the first round.

 drivers/net/phy/phy.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 547e269..d8132b9 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -169,6 +169,10 @@ int phy_device_connect(struct eth_device *edev, struct 
mii_bus *bus, int addr,
goto fail;
} else {
for (i = 0; i < PHY_MAX_ADDR && !edev->phydev; i++) {
+   /* skip masked out PHY addresses */
+   if (bus->phy_mask & (1 << i))
+   continue;
+
dev = mdiobus_scan(bus, i);
if (!dev || dev->attached_dev)
continue;
-- 
1.7.10.4


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


[PATCH] net smc911x: add support for external PHY

2012-11-07 Thread Andreas Pretzsch
On LAN9115/LAN9117/LAN9215/LAN9217, external PHYs are supported.
Switch to external PHY based on hardware strap pin and/or override flags.
Also add a mask to platform data selecting external PHY address to be used.

Code based on linux/drivers/net/ethernet/smsc/smsc911x.c (fd9abb3d, d23f028a).
---
Code is tested on a SMSC LAN9217 with an external PHY (switch chip attached
in PHY mode via MII), the external mode works as expected.
As I have no board at hand using the internal PHY of the controller (or any
of these family), I cannot verify the current behaviour, beside looking at
the internal PHY register (which are fine).
But as the modifications are mostly 1:1 copies of the respective Linux mainline
code, slightly adapted for Barebox, I expect no problems here.

Patch is against current next, but should also match current master.
CC'ing last active authors.

 drivers/net/smc911x.c |   97 +++--
 include/smc911x.h |6 +++
 2 files changed, 99 insertions(+), 4 deletions(-)

diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index c657fec..28c69ba 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -44,6 +44,10 @@ struct smc911x_priv {
 
int shift;
int generation;
+   unsigned int flags;
+   unsigned int idrev;
+   unsigned int using_extphy;
+   unsigned int phy_mask;
 
u32 (*reg_read)(struct smc911x_priv *priv, u32 reg);
void (*reg_write)(struct smc911x_priv *priv, u32 reg, u32 val);
@@ -225,6 +229,60 @@ static int smc911x_phy_write(struct mii_bus *bus, int 
phy_addr,
return 0;
 }
 
+/* Switch to external phy. Assumes tx and rx are stopped. */
+static void smsc911x_phy_enable_external(struct eth_device *edev)
+{
+   struct smc911x_priv *priv = edev->priv;
+   u32 hwcfg = smc911x_reg_read(priv, HW_CFG);
+
+   /* Disable phy clocks to the MAC */
+   hwcfg &= (~HW_CFG_PHY_CLK_SEL);
+   hwcfg |= HW_CFG_PHY_CLK_SEL_CLK_DIS;
+   smc911x_reg_write(priv, HW_CFG, hwcfg);
+   udelay(10); /* Enough time for clocks to stop */
+
+   /* Switch to external phy */
+   hwcfg |= HW_CFG_EXT_PHY_EN;
+   smc911x_reg_write(priv, HW_CFG, hwcfg);
+
+   /* Enable phy clocks to the MAC */
+   hwcfg &= (~HW_CFG_PHY_CLK_SEL);
+   hwcfg |= HW_CFG_PHY_CLK_SEL_EXT_PHY;
+   smc911x_reg_write(priv, HW_CFG, hwcfg);
+   udelay(10); /* Enough time for clocks to restart */
+
+   /* Switch MDIO/MDC to external PHY */
+   hwcfg |= HW_CFG_SMI_SEL;
+   smc911x_reg_write(priv, HW_CFG, hwcfg);
+}
+
+/* Autodetects and enables external phy if present on supported chips.
+ * autodetection can be overridden by specifying SMC911X_FORCE_INTERNAL_PHY
+ * or SMC911X_FORCE_EXTERNAL_PHY in the platform_data flags. */
+static void smsc911x_phy_initialise_external(struct eth_device *edev)
+{
+   struct smc911x_priv *priv = edev->priv;
+   u32 hwcfg = smc911x_reg_read(priv, HW_CFG);
+
+   if (priv->flags & SMC911X_FORCE_INTERNAL_PHY) {
+   dev_info(edev->parent, "Forcing internal PHY\n");
+   priv->using_extphy = 0;
+   } else if (priv->flags & SMC911X_FORCE_EXTERNAL_PHY) {
+   dev_info(edev->parent, "Forcing external PHY\n");
+   smsc911x_phy_enable_external(edev);
+   priv->using_extphy = 1;
+   } else if (hwcfg & HW_CFG_EXT_PHY_DET) {
+   dev_info(edev->parent,
+   "HW_CFG EXT_PHY_DET set, using external PHY\n");
+   smsc911x_phy_enable_external(edev);
+   priv->using_extphy = 1;
+   } else {
+   dev_info(edev->parent,
+   "HW_CFG EXT_PHY_DET clear, using internal PHY\n");
+   priv->using_extphy = 0;
+   }
+}
+
 static int smc911x_phy_reset(struct eth_device *edev)
 {
struct smc911x_priv *priv = edev->priv;
@@ -284,14 +342,41 @@ static void smc911x_reset(struct eth_device *edev)
 
/* Set to LED outputs */
smc911x_reg_write(priv, GPIO_CFG, 0x7007);
+
+   /* Select internal/external PHY */
+   switch (priv->idrev & 0x) {
+   case 0x0117:
+   case 0x0115:
+   case 0x117A:
+   case 0x115A:
+   /* External PHY supported, try to autodetect */
+   smsc911x_phy_initialise_external(edev);
+   break;
+   default:
+   dev_dbg(edev->parent, "External PHY is not supported, "
+   "using internal PHY\n");
+   priv->using_extphy = 0;
+   break;
+   }
+
+   if (!priv->using_extphy) {
+   /* Mask all PHYs except ID 1 (internal) */
+   priv->miibus.phy_mask = ~(1 << 1);
+   } else {
+   /* Mask PHYs as requested (or try all if mask is 0) */
+   /* Attn.: first probed PHY is used by phy_device_connect */
+   priv->miibus.phy_mask = priv->phy_mask;
+  

[PATCH] scripts: gitignore: update based on Makefile

2014-08-14 Thread Andreas Pretzsch
Create up-to-date list of hostprogs and targetprogs based on Makefile.
Have this list sorted like the targets in the Makefile to ease maintenance.
Also move some leftovers from root .gitignore over here.

Signed-off-by: Andreas Pretzsch 
---
patch relative to master as of 07.08.2014 (45615e3)

 .gitignore |  3 ---
 scripts/.gitignore | 20 
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/.gitignore b/.gitignore
index a62e08c..5d9157d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -83,6 +83,3 @@ cscope.*
 
 # patches
 *.patch
-scripts/gen_netx_image
-scripts/s5p_cksum
-scripts/bareboxenv-target
diff --git a/scripts/.gitignore b/scripts/.gitignore
index fddc04b..1df04ba 100644
--- a/scripts/.gitignore
+++ b/scripts/.gitignore
@@ -1,17 +1,21 @@
-bareboxenv
 bin2c
+mkimage
 fix_size
-gen_netx_image
-kallsyms
+bareboxenv
+bareboxcrc32
 kernel-install
-kernel-install-target
+bareboximd
+kallsyms
 kwbimage
 kwboot
-mk-am35xx-spi-image
-mkimage
-mkublheader
+gen_netx_image
 omap_signGP
+mk-am3xxx-spi-image
+s5p_cksum
+mkublheader
 zynq_mkimage
 socfpga_mkimage
-bareboxcrc32
+bareboxenv-target
+kernel-install-target
 bareboxcrc32-target
+bareboximd-target
-- 
2.0.1


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


Re: [PATCH 2/2] ARM: imx5: add imx5_cpu_lowlevel_init and use in all boards

2014-11-11 Thread Andreas Pretzsch
On Do, 2014-11-06 at 12:23 +0100, Lucas Stach wrote:
> This is similar to what we do on imx6 and makes sure we
> apply the errata workarounds early.

Without checking, doesn't this also apply to other Cortex-A8, like the
TI AM335x and OMAP3 chips ?

Reading "ARM Cortex A8 errata" raises this thought...

-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch  Tel. +49-(0)731-5521572
Hahnengasse 3 Fax: +49-(0)731-5521571
89073 Ulm, Germanyemail: a...@cn-eng.de


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox