Wolfgang,
no users out there.
The hardware is out of production for 5 years now.
We already waited that long to make sure.
After all there have been OEM customers only.
You can definitely remove it.
regards,
Andre
Wolfgang Denk schrieb:
Dear Andre,
In message [EMAIL PROTECTED] you wrote:
Hi,
after moving to the latest u-boot (v1.3.4) I can observe strange hangs
during network transfer.
This is clearly related to U-Boot since network is running smoothly
after booting linux from flash.
It's a MPC8343 with a Vitesse VSC8601 PHY connected via RGMII.
This happens both at 100M and
JerryVanBaren schrieb:
Andre Schwarz wrote:
Huh - problem solved. It's been a memory setup issue :-(
But I still wonder why the error is forced, i.e. happens more often,
when using network on u-boot.
If it is a SDRAM (DDR/DDR2) configuration issue, it likely is the DMA
happening from
Manuel,
we do this with conditional boot depending on environment settings, e.g.
netboot yes or no.
If netboot==no then omit bootp/dhcp completely and proceed to boot from
flash.
Otherwise try netboot and stick to the timeout. Autoneg can indeed take
some time ...
This can easily be done with a
Sylvain,
there may be a combination of several faults.
What exact type of flash are you using -have a look at the suffix like
TFIR040 to figure out if it's a fixed x8 or x16 or configurable and
how the sector layout is supposed to be (top/bottom boot or uniform
sector flash).
Send me the
clean up existing boards (mvBC-P/MPC5200 and mvBL-M7/MPC8343) by using common
code.
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner,
Hans-Joachim Reich
diff --git a/board/matrix_vision/mvbc_p/mvbc_p.c
b/board/matrix_vision/mvbc_p/mvbc_p.c
index a300342..0cbe900 100644
--- a/board/matrix_vision/mvbc_p/mvbc_p.c
+++ b/board/matrix_vision/mvbc_p/mvbc_p.c
@@ -39,6 +39,7 @@
#include asm/io.h
#include fpga.h
#include mvbc_p.h
+#include
--- /dev/null
+++ b/board/matrix_vision/common/mv_common.c
@@ -0,0 +1,125 @@
+/*
+ * (C) Copyright 2008
+ * Andre Schwarz, Matrix Vision GmbH, andre.schw...@matrix-vision.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can
boards are currently broken due to missing common dir inside board dir.
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner,
Hans-Joachim Reich
Jocke,
[snip]
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- in_flash and _start_of_vectors adress increment = 0x10.
- offset calculation for
Andy,
Sure, but until freescale or someone else with eq. and motivation
researches it, we are stuck. I am not sure anyone else has tried
83xx based boards yet. If someone has please report. Also
include weather booted from NAND or NOR, CPU type(e300cX) and
what reset vector is used.
I
Andy,
Sure, but until freescale or someone else with eq. and motivation
researches it, we are stuck. I am not sure anyone else has tried
83xx based boards yet. If someone has please report. Also
include weather booted from NAND or NOR, CPU type(e300cX) and
what reset vector is used.
Jocke,
[snip]
still -E_TOO_LITTLE_INFO:
sorry - thought it was clear already.
include weather booted from NAND or NOR, CPU type(e300cX) and
what reset vector is used.
CPU: e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
- Boot from NOR Flash
- HRCW from I2C EEPROM
- Reset
Jocke,
CPU: e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
- Boot from NOR Flash
- HRCW from I2C EEPROM
- Reset Vector 0x100, i.e. low boot.
OK, almost the same as me, but I got a:
CPU: e300c2, MPC8321, Rev: 1.1 at 266.664 MHz, CSB: 133.332 MHz
However, I think I just
Jocke,
ok - works for me, i.e. no quad-nop needed anymore.
Does both your boards work now?
MPC8343 @ 400MHz never had any issues - it's still working with your
patch applied.
MPC8377 works fine up to 533MHz ... 600MHz+ still hangs.
Looks like there are more sync missing.
I am
On 11/04/2010 08:49 PM, Wood Scott-B07421 wrote:
Timur Tabi wrote:
Wood Scott-B07421 wrote:
To be totally safe, we probably want to do a readback plus twi (to
turn
a data dependency into a flow dependency) before the isync.
twi == trap word immediate?
Yes.
If so, I don't see
Scott,
looks like I made a mistake on current MPC8377 NAND wiring.
Nand-Flash write enable is wired to LFWE1 ... I connected each WE to
its corresponding CS, i.e. :
- CS0/WE0 - Nor Flash
- CS1/WE1 - Nand Flash
- CS2/WE2 - MRAM
Am I assuming right that FCM can only use WE0 ?
Do you see any
Sebastien,
[snip]
So, U-boot needs to be fixed. I can see the following ways forward:
1.1) Stop using weak symbols; use pre-initialized function pointers
instead (possibly grouped in a struct, for cleanliness).
This has the benefit of offering a clear interface and being
Jocke,
sorry to bother you again, but it might relate to our last discussion.
Actually my MPC8377 based board is up and running with basic functionality.
Now I'm trying to add USB support - but as soon as CONFIG_USB_EHCI_FSL is
defined serial line is pretty dead again.
This means again there's
On 11/05/2010 04:00 PM, Joakim Tjernlund wrote:
Andre Schwarzandre.schw...@matrix-vision.de wrote on 2010/11/05 15:51:13:
Jocke,
sorry to bother you again, but it might relate to our last discussion.
Actually my MPC8377 based board is up and running with basic functionality.
Now I'm
All,
I'm a little confused how to setup SerDes properly on MPC8377, i.e.
which function uses which port ...
I'd expect the following :
- SATA Ports 1+2 used on SerDes 1
- PCIe Ports 3+4 (2 times x1) on SerDes 2
This is what I've done :
CONFIG_SYS_SCCR_PCIEXP1CM = 0 (disabled)
Sebastian,
drivers/qe already has an object called qe.o ... renaming qe.a to
qe.o doesn't work.
I'd suggest to build libqe.o and also adapt Toplevel Makefile accordingly.
I also don't understand why ftd.c is not depending on CONFIG_QE.
That's another question ... but leads to error having your
Scott,
looks like I made a mistake on current MPC8377 NAND wiring.
Nand-Flash write enable is wired to LFWE1 ... I connected each WE to
its corresponding CS, i.e. :
- CS0/WE0 - Nor Flash
- CS1/WE1 - Nand Flash
- CS2/WE2 - MRAM
Am I assuming right that FCM can only use WE0 ?
I
Sebastien,
I also don't understand why ftd.c is not depending on CONFIG_QE.
That's another question ... but leads to error having your patch applied.
Right, fdt.c should not be included in the build unless both CONFIG_QE
and CONFIG_OF_LIBFDT are defined. Previously this issue was
Kim, Timur,
some comments on this from your side would really help !
The issue can be summarized like this :
- MPC8377 based board is basically running fine with both U-Boot and Linux.
- Activating USB support within U-Boot leads to *very* early crash :
No console output - not even PCI
On 11/12/2010 08:31 PM, Scott Wood wrote:
On Fri, 12 Nov 2010 13:26:17 -0600
Kumar Galaga...@kernel.crashing.org wrote:
On Nov 12, 2010, at 11:22 AM, Scott Wood wrote:
On Fri, 12 Nov 2010 09:58:53 -0600
Kumar Galaga...@kernel.crashing.org wrote:
We only do the 'twi'
On 11/11/2010 01:24 PM, Andre Schwarz wrote:
Kim, Timur,
some comments on this from your side would really help !
The issue can be summarized like this :
- MPC8377 based board is basically running fine with both U-Boot and Linux.
- Activating USB support within U-Boot leads to *very
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index 7a1cae7..cfead18 100644
--- a/arch
Dave,
I notice this is hot thread for 83xx in these days.
Anybody can share more background for the issue?
I would like have a look the issue.
during MPC8377 board bring up we couldn't get U-Boot up and running -
the serial line has been dead.
Using a bdi2000 debugger told us the CPU,
Kumar,
Signed-off-by: Andre Schwarzandre.schw...@matrix-vision.de
---
arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
This doesn't seem quite right, the MPC837x has USB controllers.
- k
yes, it has - and it is working fine.
But USB
Wolfgang,
Dear Andre Schwarz,
In message4ce14e3e.7060...@matrix-vision.de you wrote:
This doesn't seem quite right, the MPC837x has USB controllers.
yes, it has - and it is working fine.
But USB register range 0x00-0xff is reserved and hangs the CPU.
With this patch
Am 15.11.2010 17:16, schrieb Wolfgang Denk:
Dear Andre Schwarz,
In message4ce1572c.6080...@matrix-vision.de you wrote:
This doesn't seem quite right, the MPC837x has USB controllers.
yes, it has - and it is working fine.
But USB register range 0x00-0xff is reserved and hangs the CPU
Wolfgang,
since a couple of days I get lots of mails from other U-Boot List
subscribers.
Is there any way to block this ?
Regards,
André
Am 16.11.2010 10:51, schrieb nore...@boxbe.com:
Hello Andre Schwarz,
Your message about Re: [U-Boot] MPC8377: USB breaks board (Action
Required
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index 7a1cae7..cfead18 100644
--- a/arch
USB register range IMMR+0x00-0xff is reserved and hangs the CPU.
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c
b/arch/powerpc/cpu
Cc: Detlev Zundeld...@denx.de
Cc: Heiko Schocherh...@denx.de
Cc: Andre Schwarzandre.schw...@matrix-vision.de
Cc: Peter De Schrijverp...@mind.be
---
Acked-by: Andre Schwarz andre.schw...@matrix-vision.de
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht
Kim,
diff --git a/include/configs/MVBLM7.h b/include/configs/MVBLM7.h
index 28e0d1b..431e102 100644
--- a/include/configs/MVBLM7.h
+++ b/include/configs/MVBLM7.h
@@ -348,7 +348,7 @@
#define CONFIG_SYS_SCCR_TSEC1CM1
#define CONFIG_SYS_SCCR_TSEC2CM1
-#define CONFIG_SYS_SICRH
Wolfgang,
Dear Andre Schwarz,
In message4cf4fcd6.80...@matrix-vision.de you wrote:
Since I have more stuff pending I'll wait for the merge window to open
before re-submitting.
We have a next branch.
understood - will rebase on current master and resubmit immediately
Kim Phillips schrieb:
On Tue, 07 Jul 2009 21:04:43 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Kim Phillips,
In message 20090624112410.b287f606.kim.phill...@freescale.com you wrote:
WD hasn't applied it yet - I applied it to my local tree. None of this
means your patch should
Peter,
On second thought, this will disable both the 'interrupts' and 'irqinfo'
command for the MVBLUE. Andre, do you mind if the 'interrupts' command
is not available the MVBLUE?
please go ahead - no problem at all.
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Any ideas on how to merge device tree binaries from slave devices ?
Having a PowerPC based board with various extension boards on e.g. the
local bus with each board having some kind of PROM device (I2C, SPI
etc.) containing a dtb ... is it possible to merge this into the
existing boards dtb
Add initial support for Matrix Vision mvSMR board based on MPC5200B.
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
Wolfgang,
thanks for having a look @ v2.
This is v3 taking all comments into account.
TIA,
Andre
CREDITS |2 +-
MAINTAINERS
Add USB commands.
Rename autoscript to bootscript.
Add automatic bootscript image generation to makefile.
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
board/matrix_vision/mvblm7/Makefile |1 +
board/matrix_vision/mvblm7/bootscript| 43
Jerry Van Baren wrote:
Andre Schwarz wrote:
Kumar Gala schrieb:
On Dec 9, 2008, at 12:01 PM, Andre Schwarz wrote:
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed
values
Jürgen,
Have a look at the manual chapter 4 (=Reset + Config).
SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware
reset.
Looks like you should make use of the SRESET and trigger HRESET accordingly.
I could solve this with _not_ using the internal watchdog but an
external
Kim,
I'd like to change my DDR setup code since it looks like my computed
values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the new common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for
83xx or shall I
Kim Phillips schrieb:
On Mon, 08 Dec 2008 18:02:02 +0100
Andre Schwarz [EMAIL PROTECTED] wrote:
I'd like to change my DDR setup code since it looks like my computed
values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up
All,
can someone tell me why the board specific function void
show_boot_progress(int arg)
is no longer called (at least on MPC5200).
Of course this line is present in the board config :
#define CONFIG_SHOW_BOOT_PROGRESS 1
What have I missed ?
regards,
André
MATRIX VISION GmbH, Talstraße
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed
values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller
Heiko Schocher schrieb:
Hello Andre,
Andre Schwarz wrote:
All,
can someone tell me why the board specific function void
show_boot_progress(int arg)
is no longer called (at least on MPC5200).
Of course this line is present in the board config :
#define CONFIG_SHOW_BOOT_PROGRESS 1
Graeme Russ schrieb:
Hi All,
I had some 'fun' with weak functions a little while ago, and I'm wondering
if maybe we should fix up a few inconsistencies...
Andre Schwarz wrote:
Heiko Schocher schrieb:
Hello Andre,
Andre Schwarz wrote:
All,
can someone tell me why
Ben,
after cloning the latest u-boot git I can see that you've added this
inside the mvBC-P board setup :
int board_eth_init(bd_t *bis)
{
cpu_eth_init(bis); /* Built in FEC comes first */
return pci_eth_init(bis);
}
Are you aware that there's no PHY connected and the ETH-Pins are used
Kumar Gala schrieb:
On Dec 9, 2008, at 12:01 PM, Andre Schwarz wrote:
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed
values are not perfectly stable on our 8343 based board
Kumar Gala schrieb:
On Dec 9, 2008, at 12:01 PM, Andre Schwarz wrote:
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed
values are not perfectly stable on our 8343 based board
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
arch/powerpc/lib/board.c |9 -
include/configs/BAB7xx.h |1 +
include/configs/CPC45.h |1 +
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
SICRH has been misconfigured, i.e. TSEC2 clock + D[0:3] are GPIOs.
Fix this to be RGMII signals again.
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
Kim,
sorry for late submission - this has been lingering around for a while.
Hopefully you can still appply it since it's a real
Jocke,
[snip]
You still haven't reported weather the 4 nop's helped or not, yet you
seek my help. I am just going to ignore you until you do test it.
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
Diffing both
Jocke,
Andre Schwarzandre.schw...@matrix-vision.de wrote on 2010/10/25 15:50:19:
Jocke,
[snip]
You still haven't reported weather the 4 nop's helped or not, yet you
seek my help. I am just going to ignore you until you do test it.
finally I got both some time and
Wolfgang,
Dear Andre Schwarz,
In message4cc58b1b.8040...@matrix-vision.de you wrote:
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
This is probably completely unrelated - but check your
Leif,
I have managed to flashed a 36-bits u-boot to my p4080 board.
I have put in two 4Gb dimm into the board but it doesn't work.
I got the following from u-boot.
[snip]
DRAM: Initializing
Error: DDR_SDRAM_CFG[RD_EN] and DDR_SDRAM_CFG[2T_EN] should not be set at
the same
Kim,
are you using TOT of mpc83xx or master ?
ToT seems to be working fine for me (using different PHYs though):
U-Boot 2010.06-rc2-00035-g1f24126 (Jun 21 2010 - 11:16:54) MPC83XX
[snip]
you can try applying commit 71bd860cce4493c5def07804723661e75271052b
mpc83xx: don't shift
Michael,
On 05/25/2011 05:38 PM, Michael Jones wrote:
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c
bus. I tracked it to commit 0e57968a215d1b, I2C: OMAP: detect more
devices when probing an i2c bus. It detects more devices indeed, such
as some that don't even
Add initial support for Matrix Vision mvSMR board based on MPC5200B.
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
CREDITS |2 +-
MAINTAINERS |1 +
MAKEALL |1 +
Makefile
Detlev,
Hi Andre,
just a few obligatory remarks...
thanks for pointing this out - these are remnants dated from 2006 ...
simply overlooked them while concentrating on proper git usage :-)
Will wait for some more comments and resubmit v2 tomorrow.
Regards,
André
MATRIX VISION GmbH,
Add initial support for Matrix Vision mvSMR board based on MPC5200B.
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
Wolfgang,
I've made all changes requested by Detlev regarding v1.
Patch has been checked with checkpatch.pl from kernel tree showing no obvious
errors
Wolfgang,
Please help testing, and send any feedback / last minute patches ASAP.
if there's any chance that you'll apply this patch we can include the
latest code in our long term test site and report any possible issues
related with U-Boot @ MPC5200.
Wolfgang,
This is new code - posted just a couple of days ago. It will certainly
not go into the upcoming release any more.
Hmm - it's just another board making use of existing mpc5xxx code and
some common matrix-vision code already present.
There are no mods to any code possibly
Kim,
On Mon, 28 Feb 2011 17:18:38 +0100
Andre Schwarzandre.schw...@matrix-vision.de wrote:
sorry to bother you again, but I again stumbled over the discussed USB
init issue :
nack, 837x has a usb controller at IMMR+0x23000.
yes - but offset 0x00-0xff is explicitly reserved regarding to
Hi,
moving to latest U-Boot introduces some issues with the environment.
Setup:
- PowerPC based boards (52xx / 83xx)
- Environments are in flash with redundancy
Dumping flash the environments with dd and using hexdump shows :
- crc32 - flags Data (first entry beginning with 'a').
Wolfgang,
Dear Andre Schwarz,
In message4d949e22.5090...@matrix-vision.de you wrote:
moving to latest U-Boot introduces some issues with the environment.
Which board would that be? I don't see this on any board I tested.
it is mvblm7 (=MPC8343) and a new MPC8377 based one waiting
Wolfgang,
Which board would that be? I don't see this on any board I tested.
it is mvblm7 (=MPC8343) and a new MPC8377 based one waiting for
the merge window to open.
I'm using a gcc-4.3.3 from OpenEmbedded/Angstrom ... if this matters at all.
Can you please try and use anothe rtool chain,
-existent) PHY_CLK_VALID bit never gets set.
Reported-by: Andre Schwarzandre.schw...@matrix-vision.de
Signed-off-by: Kim Phillipskim.phill...@freescale.com
Tested-by: Andre Schwarz andre.schw...@matrix-vision.de
Works on MPC8343 and MPC8377.
---
arch/powerpc/cpu/mpc83xx/cpu_init.c |4
Kim,
I have made some mods to spd_sdram.c for various reason:
1.
use SPD setup also for soldered RAM.
This allows DDR mounting options without U-Boot change because SPD data
is written during in-circuit/boundary-scan testing.
2.
read SPD data also from extended adressing EEPROMS used for e.g.
Kim, York,
I have made some mods to spd_sdram.c for various reason:
1.
use SPD setup also for soldered RAM.
This allows DDR mounting options without U-Boot change because SPD data
is written during in-circuit/boundary-scan testing.
not sure I understand this - board with soldered RAM can't
York,
I have made some mods to spd_sdram.c for various reason:
1.
use SPD setup also for soldered RAM.
This allows DDR mounting options without U-Boot change because SPD data
is written during in-circuit/boundary-scan testing.
not sure I understand this - board with soldered RAM can't
Wolfgang,
Which board would that be? I don't see this on any board I tested.
it is mvblm7 (=MPC8343) and a new MPC8377 based one waiting for
the merge window to open.
I'm using a gcc-4.3.3 from OpenEmbedded/Angstrom ... if this matters at all.
Can you please try and use anothe rtool
Kim,
York,
ok - will give it a try tomorrow.
hmm - having a look at the Makefile it looks like I need
CONFIG_FSL_DDR2.
This seems to pull in the new code ... without omitting the old
one
in arch/powerpc/cpu/mpc83xx/spd_sdram.c
The Makefile further uses ctrl_regs.c ... which
York,
On Fri, 2011-04-08 at 09:41 +0200, Andre Schwarz wrote:
I am sorry I totally ignored the subject with mpc83xx. I was thinking of
mpc85xx.
ok - no new code for 83xx then.
You are right the old code is in spd_sdram.c and it is still in use for
mpc83xx. Unless to adjust the code
On 04/08/2011 06:36 PM, York Sun wrote:
On Fri, 2011-04-08 at 18:29 +0200, Andre Schwarz wrote:
York,
On Fri, 2011-04-08 at 09:41 +0200, Andre Schwarz wrote:
I am sorry I totally ignored the subject with mpc83xx. I was thinking of
mpc85xx.
ok - no new code for 83xx then.
You are right
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
board/matrix_vision/common/mv_common.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/board/matrix_vision/common/mv_common.c
b/board/matrix_vision/common/mv_common.c
index 0afc535
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
arch/powerpc/cpu/mpc83xx/speed.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx/speed.c b/arch/powerpc/cpu/mpc83xx/speed.c
index 5e616dd..1eca1a8 100644
--- a/arch/powerpc/cpu
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
include/mpc83xx.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/mpc83xx.h b/include/mpc83xx.h
index ea137c7..8292018 100644
--- a/include/mpc83xx.h
+++ b/include/mpc83xx.h
@@ -1000,6 +1000,7
CPO value and driver strength settings are board specifc.
Also allow SPD data fetch from any accessible I2C EEPROM.
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
arch/powerpc/cpu/mpc83xx/spd_sdram.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions
Running on mpc837x without CONFIG_FSL_ESDHC leads to
i2c1_clk not being set at all. It is bound to clock
of encryption module. fix this.
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
Changes for v2:
- fix commit message mangling in subject line.
arch/powerpc/cpu
introduced by this patchset.
Files have been checked using checkpatch.
Andre Schwarz (4):
MergerBox: Add board config file.
MergerBox: add documentation.
MergerBox: add maintainer and boards.cfg entries.
MergerBox: add board specific files in vendor dir.
MAINTAINERS
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
include/configs/MERGERBOX.h | 619 +++
1 files changed, 619 insertions(+), 0 deletions(-)
create mode 100644 include/configs/MERGERBOX.h
diff --git a/include/configs/MERGERBOX.h b/include
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
MAINTAINERS |1 +
boards.cfg |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4756f14..0720659 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -442,6 +442,7 @@ Peter De
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
doc/README.mergerbox | 59 ++
1 files changed, 59 insertions(+), 0 deletions(-)
create mode 100644 doc/README.mergerbox
diff --git a/doc/README.mergerbox b/doc/README.mergerbox
new
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de
---
board/matrix_vision/mergerbox/Makefile| 51 ++
board/matrix_vision/mergerbox/fpga.c | 175 +
board/matrix_vision/mergerbox/fpga.h | 30
board/matrix_vision/mergerbox/mergerbox.c | 241
Am 20.10.2011 13:37, schrieb Michael Jones:
When CONFIG_ENV_IS_NOWHERE, got following warning:
mv_common.c:32:14: warning: 'entries_to_keep' defined but not used.
Get rid of this warning.
Signed-off-by: Michael Jonesmichael.jo...@matrix-vision.de
Acked-by: Andre Schwarz andre.schw...@matrix
Wolfgang,
just wanted to update my local U-Boot master branch an got some errors I
don't understand (since I'm still a git newbie).
This is what I have:
git originally cloned from public repo - thus I have in .git/config :
[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/*
Wolfgang,
Have I missed anything ?
Is there a way to get automagically merged whatever there might be to
merge ?
Sorry, I have no idea what happenend of your system. I can see no
issues on our side.
thank - will clone a new repo an pull in my local branches.
--
Regards,
Andre
Kim,
finally found some time to re-work my 8377 board code for submission.
sorry to bother you again, but I again stumbled over the discussed USB
init issue :
nack, 837x has a usb controller at IMMR+0x23000.
yes - but offset 0x00-0xff is explicitly reserved regarding to the manual.
Don't
Stefan,
actually I have an issue with the ubi part command.
Situation:
MPC8377 based board with 64MiB Nor- (u-boot etc.) and 1GiB Nand-Flash
(ubi volume).
MTD devices look like this :
= mtdparts
device nor0 NOR, # parts = 2
#: namesizeoffset mask_flags
Stefan,
Hi Andre,
On Wednesday 02 March 2011 16:35:09 Andre Schwarz wrote:
actually I have an issue with the ubi part command.
Situation:
MPC8377 based board with 64MiB Nor- (u-boot etc.) and 1GiB Nand-Flash
(ubi volume).
MTD devices look like this :
= mtdparts
device nor0NOR
Stefan,
Andre,
On Friday 04 March 2011 11:16:50 Andre Schwarz wrote:
= ubi part root
Creating 1 MTD partitions on nand0:
0x-0x4000 : mtd=0
UBI: attaching mtd2 to ubi0
UBI error: io_init: unaligned VID header shift 2
UBI error: ubi_init: cannot attach mtd2
UBI error
All,
sorry to bother you again.
After my harddisk died I'm porting my latest 8377 work to TOT.
Unfortunately I'm lacking some commits that haven't been pushed to backup.
But everything's fine so far and the system is up and running, except PCIe.
Using the old binary left on the server PCIe has
I have an issue with i2c-1 bus speed not being calculated correctly on
MPC8377.
arch/powerpc/cpu/mpc83xx/speed.c lines 320+ are :
#if defined(CONFIG_MPC834x)
i2c1_clk = tsec2_clk;
#elif defined(CONFIG_MPC8360)
i2c1_clk = csb_clk;
#elif defined(CONFIG_MPC832x)
i2c1_clk
Stephen,
On 10/25/2012 01:05 AM, Stephen Warren wrote:
While looking into a CONFIG_CONSOLE_MUX-related issue, I noticed the
following:
include/configs/u8500_href.h:136: stdin=serial,usbtty\0
include/configs/u8500_href.h:135: stdout=serial,usbtty\0
include/configs/snowball.h:180:
99 matches
Mail list logo
