Am 20.10.2010 22:38, schrieb Albert ARIBAUD:
This is an ld, not gcc, issue. What does arm-unknown-eabi-ld -V produce?
$ arm-unknown-eabi-ld -V
GNU ld (GNU Binutils) 2.19.1
Supported emulations:
armelf
Thanks for your time
Matthias
___
U-Boot
Hi all,
I have 2 questions.
1)
I have a P1020RDB Board on which I am trying to configure by E1000
82574 PCI express Ethernet Card. I see support for 82571 but not for
82574.
I don't know how different these chips. Can I expect this PCI express
Card to work with the e1000 driver in U-boot?
2)
I
Dear Prafulla Wadaskar,
In message f766e4f80769bd478052fb6533fa745d19a6a46...@sc-vexch4.marvell.com
you wrote:
We can rename KWD_CONFIG to CONFIG_SYS_KWB_CONFIG and have default assignment
as above
If for some boards default assignment stands invalid, those can be redefined
in board
After moving the definition of CONFIG_SYS_TEXT_BASE to the respective
board config files, all Marvell kirkwood board have just a single and
common entry in their config.mk files:
KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg
Replace the only reference to KWD_CONFIG in the top
Hi Stefano,
On Thu, 21 Oct 2010 00:10:56 +0200
Stefano Babic sba...@denx.de wrote:
...
What tree is this patch based on? It doesn't apply on current
u-boot.git/master:
The patch is based on the u-boot tree at the time I sent to ML, in any
case on the actual release
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Thursday, October 21, 2010 12:08 PM
To: u-boot@lists.denx.de
Cc: Wolfgang Denk; Prafulla Wadaskar; Siddarth Gore; Simon
Kagstrom; Heiko Schocher; Eric Cooper
Subject: [RFC] [PATCH] kirkwood: get rid of config.mk
Dear Prafulla,
In message f766e4f80769bd478052fb6533fa745d19a6a46...@sc-vexch4.marvell.com
you wrote:
- $(obj)tools/mkimage -n $(KWD_CONFIG) -T kwbimage \
+ $(obj)tools/mkimage \
+ -n $(SRCTREE)/board/$(CONFIG_BOARDDIR)/kwbimage.cfg \
Note: I have to admit
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Thursday, October 21, 2010 1:52 PM
To: Prafulla Wadaskar
Cc: u-boot@lists.denx.de; Siddarth Gore; Simon Kagstrom;
Heiko Schocher; Eric Cooper
Subject: Re: [RFC] [PATCH] kirkwood: get rid of config.mk files
Board support for the Guntermann Drunck CATCenter Io.
Board support for the Guntermann Drunck IoCon.
Signed-off-by: Dirk Eibach eib...@gdsys.de
---
Changes since v1:
- rebase rebase on current u-boot master
- dropped config.mk and adapted config headers
MAINTAINERS |2 +
I will be out of the office starting 10/20/2010 and will not return until
10/25/2010.
I will respond to your message when I return. Please contact my manager
Colleen Becker 319-295-1567 if you require immediate attention.
___
U-Boot mailing list
The following changes since commit c62491d2602b353a815a909e27eec0df9f2c06a2:
ppc: Don't initialize write protected NOR flashes (2010-10-20 21:58:16 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-usb.git master
Florian Fainelli (1):
ehci-pci: print hccr, hcor
Hi,
2010/10/20 Mike Frysinger vap...@gentoo.org:
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
common/usb_storage.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Applied to u-boot-usb
Thanks.
Remy
___
U-Boot mailing list
Hi,
2010/10/20 Wolfgang Denk w...@denx.de:
Commit 3ed1607 USB: sync Queue Element Transfer Descriptor against
EHCI spec added an __attribute__ ((aligned (32))) to the
declaration of struct qTD, as used for example in the Linux kernel as
well.
However, it turns out that this attribute causes
Wolfgang (and others who can/want),
Please test this patch; it should add a complete barrier to make
sure that all fixups are written to RAM before jumping there, and
that no remnants subsist of the old unfixed code in the instruction
paths. However, I cannot even do basic testing on it as I have
In case malloc is invoked with requested size 0, this patch will prevent
the execution of the allocation algorithm (because it corrupts the data
structures)
and will return 0 to the caller.
Signed-off-by: Nikolaos Kostaras nk...@intracomdefense.com
---
common/dlmalloc.c |2 +-
1 files
Dear Prafulla Wadaskar,
In message f766e4f80769bd478052fb6533fa745d19a6a46...@sc-vexch4.marvell.com
you wrote:
Shall I take this opporunity to modify test and repost this patch?
Yes, please do! Thanks!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk
Hello Albert,
Albert Aribaud wrote:
Wolfgang (and others who can/want),
Please test this patch; it should add a complete barrier to make
sure that all fixups are written to RAM before jumping there, and
that no remnants subsist of the old unfixed code in the instruction
paths. However, I
Le 21/10/2010 08:03, Matthias Weißer a écrit :
Am 20.10.2010 22:38, schrieb Albert ARIBAUD:
This is an ld, not gcc, issue. What does arm-unknown-eabi-ld -V produce?
$ arm-unknown-eabi-ld -V
GNU ld (GNU Binutils) 2.19.1
Supported emulations:
armelf
Thanks for your time
Matthias
Dear Albert Aribaud,
In message 1287652681-4085-1-git-send-email-albert.arib...@free.fr you wrote:
Wolfgang (and others who can/want),
Please test this patch; it should add a complete barrier to make
sure that all fixups are written to RAM before jumping there, and
that no remnants subsist
Le 21/10/2010 12:11, Reinhard Meyer a écrit :
Hello,
observation here:
ICACHE is always ON. No crash with usb read 2100 0 1000
Sorry that I can't reproduce the problem here, not even with 1 blocks.
(tried a few dozen times)
(ARM926EJS - AT91SAM9XE)
(based on TOT
Hello Albert,
Albert ARIBAUD wrote:
Le 21/10/2010 12:11, Reinhard Meyer a écrit :
Hello,
observation here:
ICACHE is always ON. No crash with usb read 2100 0 1000
Sorry that I can't reproduce the problem here, not even with 1
blocks.
(tried a few dozen times)
(ARM926EJS -
Le 21/10/2010 11:51, Heiko Schocher a écrit :
Hello Albert,
Albert Aribaud wrote:
Wolfgang (and others who can/want),
Please test this patch; it should add a complete barrier to make
sure that all fixups are written to RAM before jumping there, and
that no remnants subsist of the old
On Thursday 21 October 2010 12:34:01 Albert ARIBAUD wrote:
But with DCACHE ON, the USB Stick is not found - maybe a timing problem:
TOP9000 dc off
Data (writethrough) Cache is OFF
TOP9000 usb reset
(Re)start USB...
USB: scanning bus for devices... 2 USB Device(s) found
Hi,
But with DCACHE ON, the USB Stick is not found - maybe a timing problem:
TOP9000 dc off
Data (writethrough) Cache is OFF
TOP9000 usb reset
(Re)start USB...
USB: scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
Hello Albert,
Albert Aribaud wrote:
Wolfgang (and others who can/want),
Please test this patch; it should add a complete barrier to make
sure that all fixups are written to RAM before jumping there, and
that no remnants subsist of the old unfixed code in the instruction
paths.
On Thursday 21 October 2010 13:22:10 Reinhard Meyer wrote:
Correct. Note that the EHCI driver already supports such a mode with
d-cache enabled. You need to set CONFIG_EHCI_DCACHE to enable these
cache handling functions.
AT91 uses OHCI.
As far as I can tell there is no cache code in it.
Dear Albert ARIBAUD,
In message 4cc01c6b.9090...@free.fr you wrote:
Wolfgang/other testers, can you do the following three tests?
Will do asap, but first I want to share Heiko's latest findings:
With this patch all problems go away, too:
diff --git a/drivers/usb/host/ehci-hcd.c
Dear Albert,
In message 20101021113605.a85d6135...@gemini.denx.de I wrote:
With this patch all problems go away, too:
Don't count your chickens before they are hatched.
After 8 transfers of 65536 it hung again...
So not solved, but much, much better...
Best regards,
Wolfgang Denk
--
Dear Joakim Tjernlund,
In message
ofd5abfc5e.96e88c93-onc12577c3.00406e0e-c12577c3.00408...@transmode.se you
wrote:
It is legal for malloc() to return NULL in case of size==0,
and for the sake of simplicity I recommend we do just that.
Yes, but not very useful. Glibc does not return
Wolfgang Denk w...@denx.de wrote on 2010/10/21 13:51:26:
Dear Joakim Tjernlund,
In message OFD5ABFC5E.96E88C93-ONC12577C3.00406E0E-C12577C3.
00408...@transmode.se you wrote:
It is legal for malloc() to return NULL in case of size==0,
and for the sake of simplicity I recommend we do
Dear Albert ARIBAUD,
In message 4cc01c6b.9090...@free.fr you wrote:
Wolfgang/other testers, can you do the following three tests?
My test looks like this:
usb_test=usb start;run usb_test20 usb_test30 usb_test40
usb_test2=usb read 8080 0 100;date
usb_test20=run usb_test2 usb_test2
Dear Joakim Tjernlund,
In message
of9ad66e3f.36e9c654-onc12577c3.004134fd-c12577c3.0041a...@transmode.se you
wrote:
Of course we could return some valid pointer like glibc does, i. e.
implement something like
if (size == 0)
size = 8;
or so. Do you think that would be
Le 21/10/2010 14:00, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4cc01c6b.9090...@free.fr you wrote:
Wolfgang/other testers, can you do the following three tests?
My test looks like this:
usb_test=usb start;run usb_test20 usb_test30 usb_test40
usb_test2=usb read 8080 0
Wolfgang Denk w...@denx.de wrote on 2010/10/21 14:02:39:
Dear Joakim Tjernlund,
In message OF9AD66E3F.36E9C654-ONC12577C3.004134FD-C12577C3.
0041a...@transmode.se you wrote:
Of course we could return some valid pointer like glibc does, i. e.
implement something like
if
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Oct 21, 2010, at 1:34 AM, y bhanu wrote:
Hi all,
I have 2 questions.
1)
I have a P1020RDB Board on which I am trying to configure by E1000
82574 PCI express Ethernet Card. I see support for 82571 but not for
82574.
I don't know how different these chips. Can I expect this PCI
Commit 14d0a02a Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE missed the
IGEP boards since they were just added.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk
index b8812f9..7964621 100644
---
On Wed, Oct 20, 2010 at 09:52:31PM -0700, Prafulla Wadaskar wrote:
This is not Marvell owned board, so it must go in board/Seagate or
board/dockstar folder
board/Seagate/dockstar/ would be my preference, since there are
similar products like the Go Flex that might go in board/Seagate/
someday.
Dear Eric Cooper,
In message 20101021150117.gb6...@localhost you wrote:
On Wed, Oct 20, 2010 at 09:52:31PM -0700, Prafulla Wadaskar wrote:
This is not Marvell owned board, so it must go in board/Seagate or
board/dockstar folder
board/Seagate/dockstar/ would be my preference, since there
DISPLAY_MARK subcommand of display_set() is not used anywhere so
we can remove it safely.
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
doc/README.LED_display |1 -
include/led-display.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/doc/README.LED_display
The default values for 'addip' and 'norargs' changed per customer
request. Everything else cleaned up to fit into 80 symbol line.
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
include/configs/a4m072.h | 58 +
1 files changed, 37 insertions(+), 21
Hello,
these patches clean up the support for a4m072 board and related things.
Fourth patch is pretty generic actually but as it's only needed for
a4m072 AFAIK I post it in these series.
Patches:
[PATCH 1/5] a4m072: changes to the default environment
[PATCH 2/5] a4m072: change 'display' command
On some boards we have flash mapped high in the address space with
considerably small window (say 0xFE00 and 32MB). When we install
bigger chip (say 64MB) on such a board strange things happen
(flash_write() doesn't work at all, for ex). That's because cfi_flash
driver doesn't care about
This patch adds CONFIG_SYS_FLASH_BANKS_SIZES define to make use of new
cfi_flash driver ability to detect flash chips that are bigger than a
corresponding address window (we have such situation on some revs of
a4m072).
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
include/configs/a4m072.h |
This patch changes implementation of 'display' command for a4m072
that uses 7-segment LED display as customer requested:
a) The display command shall _not_ turn on the decimal point.
b) Exception: display . shall turn on (only) the decimal point.
c) Hex digits (0-9, A-F, a-f) shall be displayed
So do you mean adding one eth3addr to ENV will do the job.
eth3addr= 00:04:9F:01:08:23
I help to support the patch for this chip to U-boot.
It looks like most of the code is taken from Linux kernel.
Can you provide any references?
Thanks,
Mukund
On Thu, Oct 21, 2010 at 6:33 AM, Kumar Gala
Damien,
I get a build error on MVBLM7 board on current top of tree.
In file include/usb/ehci-fsl.h line 164 checks for CONFIG_MPC83XX
introduced by
commit 29c6fbe0471afd7ffa41fcb2103eec5b53294897
Author: Damien Dusha d.du...@gmail.com
Date: Thu Oct 14 15:27:06 2010 +0200
MPC5121: Add
Commit 29c6fbe0471afd7ffa41fcb2103eec5b53294897 broke
building for 83xx boards with USB support:
ehci-fsl.c: In function 'ehci_hcd_init':
ehci-fsl.c:43: error: 'CONFIG_SYS_FSL_USB_ADDR' undeclared (first use in this
function)
ehci-fsl.c:43: error: (Each undeclared identifier is reported only
HEAD is at commit c62491d2602b353a815a909e27eec0df9f2c06a2
MAKEALL guruplug
arm-gp2x-linux-ld: -static and -shared may not be used together
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
HEAD is at commit c62491d2602b353a815a909e27eec0df9f2c06a2
Untested due to link error bug
Signed-off-by: Gray Remlin g_rem...@rocketmail.com
---
arch/arm/cpu/arm926ejs/start.S |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S
Dear Anatolij Gustschin,
In message 1287678635-24269-1-git-send-email-ag...@denx.de you wrote:
Commit 29c6fbe0471afd7ffa41fcb2103eec5b53294897 broke
building for 83xx boards with USB support:
ehci-fsl.c: In function 'ehci_hcd_init':
ehci-fsl.c:43: error: 'CONFIG_SYS_FSL_USB_ADDR' undeclared
Dear Gray Remlin,
In message 4cc06b12.9090...@rocketmail.com you wrote:
HEAD is at commit c62491d2602b353a815a909e27eec0df9f2c06a2
MAKEALL guruplug
arm-gp2x-linux-ld: -static and -shared may not be used together
- git describe
v2010.09-468-gc62491d
- MAKEALL guruplug
Configuring for
Maintain syntax consistency and compatibility with the stock
FEDORA ARM cross-compiler tool chain.
Signed-off-by: Gray Remlin g_rem...@rocketmail.com
---
Patch V2fix all occurrences, not just arm926ejs
arch/arm/cpu/arm1136/start.S |4 ++--
arch/arm/cpu/arm926ejs/start.S |4
Labels added to endifs to aid readability of the net/bootp.c file.
A block of code was marked for conditional compilation but the condition
could never arise, the ifdef\endif code block has been deleted.
Signed-off-by: Gray Remlin g_rem...@rocketmail.com
---
net/bootp.c | 93
Move and rename common header files from under board/davinci to the
standard include file path.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
---
This patch is needed for adding board support for the hawkboard which
uses nand_spl based boot mechanism.
board/davinci/common/misc.c
The patch adds basic board support for TI's OMAP-L138 based
Hawkboard. This board is pretty similar to the da850 EVM. Support for
nand and network access is added in this version.
The following bootup procedure is used.
At reset, the Rom Boot Loader(RBL), initialises the ddr and the nand
On Thursday, October 21, 2010 07:45:10 Joakim Tjernlund wrote:
Wolfgang Denk wrote on 2010/10/21 13:32:54:
Joakim Tjernlund you wrote:
- if ((long)bytes 0) return 0;
+ if ((long)bytes = 0) return 0;
I think you should return some impossible ptr value =! NULL
Size 0 not
Dear Stefan,
In message 1287674413-3900-5-git-send-email-ya...@emcraft.com you wrote:
On some boards we have flash mapped high in the address space with
considerably small window (say 0xFE00 and 32MB). When we install
bigger chip (say 64MB) on such a board strange things happen
Dear Gray Remlin,
In message 4cc09695.6070...@rocketmail.com you wrote:
Labels added to endifs to aid readability of the net/bootp.c file.
A block of code was marked for conditional compilation but the condition
could never arise, the ifdef\endif code block has been deleted.
...
-#if
Dear Sughosh Ganu,
In message 1287690158-6055-1-git-send-email-urwithsugh...@gmail.com you wrote:
Move and rename common header files from under board/davinci to the
standard include file path.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
---
This patch is needed for adding board
Dear Wolfgang Denk,
In message4cc09695.6070...@rocketmail.com you wrote:
Labels added to endifs to aid readability of the net/bootp.c file.
A block of code was marked for conditional compilation but the condition
could never arise, the ifdef\endif code block has been deleted.
...
-#if
Dear Sughosh Ganu,
In message 1287690234-6109-1-git-send-email-urwithsugh...@gmail.com you wrote:
The patch adds basic board support for TI's OMAP-L138 based
Hawkboard. This board is pretty similar to the da850 EVM. Support for
nand and network access is added in this version.
The following
For current mx51 support in u-boot where we have no fuse support the
patch is useful. I don't recall what the general policy is in u-boot
for env vs eeprom mac addresses but I do remember discussions about
it.
On Tue, Oct 19, 2010 at 11:21 PM, Liu Hui-R64343 r64...@freescale.com wrote:
Hi, John
On 22/10/10 06:51, Mike Frysinger wrote:
On Thursday, October 21, 2010 07:45:10 Joakim Tjernlund wrote:
Wolfgang Denk wrote on 2010/10/21 13:32:54:
Joakim Tjernlund you wrote:
- if ((long)bytes 0) return 0;
+ if ((long)bytes = 0) return 0;
I think you should return some impossible ptr
On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:
On 22/10/10 06:51, Mike Frysinger wrote:
have u-boot return an error.
Is NULL what you consider to be an error
yes
Besides, is not free(NULL) valid (does nothing) as well?
yes, free(NULL) should work fine per POSIX
-mike
I sometimes want to try out a patch that has been proposed on the
mailing list. If I no longer have the email in my mailbox, and it
hasn't been applied to one of the uboot-*.git trees yet, my only
option seems to be to scrape it from the mailman archives, which makes
it difficult to use git am
On Wed, 13 Oct 2010 12:14:29 +0200
Stefano Babic sba...@denx.de wrote:
[port of linux 2.6.34 commit 6a9ee8af344e3bd7dbd61e67037096cdf7f83289]
Signed-off-by: Stefano Babic sba...@denx.de
---
Changes since V1:
- added precise reference to the kernel version used for porting
in the
On Wed, 13 Oct 2010 12:17:14 +0200
Stefano Babic sba...@denx.de wrote:
Add framebuffer driver for the MX51 processor
working on the IPUv3 internal graphic processor.
The port is based on the driver found in the kernel
delivered by Freescale as part of i.MX BSP:
[kernel 2.6.31 commit
On Thursday, October 21, 2010 17:32:52 Eric Cooper wrote:
I sometimes want to try out a patch that has been proposed on the
mailing list. If I no longer have the email in my mailbox, and it
hasn't been applied to one of the uboot-*.git trees yet, my only
option seems to be to scrape it from
Hi Stefano,
On Thu, 21 Oct 2010 10:34:39 +0200
Stefano Babic sba...@denx.de wrote:
The patch adds support for LCD to the vision board.
Signed-off-by: Stefano Babic sba...@denx.de
---
board/ttcontrol/vision2/vision2.c | 69
+
On Wed, 13 Oct 2010 12:17:48 +0200
Stefano Babic sba...@denx.de wrote:
The patch adds support for LCD to the vision board.
Signed-off-by: Stefano Babic sba...@denx.de
---
Changes since V1:
- Remove wrong CONFIG_CMD_DISPLAY
board/ttcontrol/vision2/vision2.c | 69
Dear Wolfgang,
The following changes since commit fff6ec382c139eb242bd85356e66a0bc43becb63:
Anatolij Gustschin (1):
Fix building for 83xx boards with USB support
are available in the git repository at:
git://git.denx.de/u-boot-video.git master
Stefano Babic (4):
Add linux
On Wed, Oct 13, 2010 at 5:14 AM, Stefano Babic sba...@denx.de wrote:
[port of linux 2.6.34 commit 6a9ee8af344e3bd7dbd61e67037096cdf7f83289]
Signed-off-by: Stefano Babic sba...@denx.de
---
Changes since V1:
- added precise reference to the kernel version used for porting
in the commit
Hi,
please pull my git://git.denx.de/u-boot-pxa for-wd-master branch into your u-
boot/master branch. Thanks
The following changes since commit fff6ec382c139eb242bd85356e66a0bc43becb63:
Fix building for 83xx boards with USB support (2010-10-21 20:00:41 +0200)
are available in the git
On Thu, Oct 21, 2010 at 06:19:20PM -0400, Mike Frysinger wrote:
gmane has a news gateway
And right after I posted my question (naturally) I found that the
archive at
marc.infohttp://marc.info/?l=u-boot
offers an option to download raw messages.
--
Eric Cooper e c c @ c m u . e
Hi, John
2010/10/22 John Rigby jcri...@gmail.com:
For current mx51 support in u-boot where we have no fuse support the
patch is useful. I don't recall what the general policy is in u-boot
for env vs eeprom mac addresses but I do remember discussions about
it.
Geting mac address from FUSE is
- Original Message -
From: Prafulla Wadaskar lt;prafu...@marvell.comgt;
To: Tanmay Upadhyay lt;tanmay.upadh...@einfochips.comgt;
Cc: u-boot@lists.denx.de, g remlin lt;g_rem...@rocketmail.comgt;, Ashish
Karkare lt;akark...@marvell.comgt;, Prabhanjan Sarnaik
lt;sarn...@marvell.comgt;
Sent:
Dear Jason Liu,
In message aanlktimesozpvruutursgkxtqk0tyjgdxtck7egzm...@mail.gmail.com you
wrote:
Geting mac address from FUSE is the right way for mx51 and it's not
difficult to add FUSE read function due to the FUSE read is simple as
the memory read. I have seen that Shawn has posted the
The RAM relocated address is useful when debugging or there is u-boot
crash dump. So always print it instead of debug.
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
Cc: Wood Scott-B07421 b07...@freescale.com
---
arch/powerpc/lib/board.c |2 +-
1 files changed, 1 insertions(+), 1
On 10/22/2010 05:54 AM, Liu Ying wrote:
Hello, Stefano,
Hi Liu,
It looks that your framebuffer patch supports one framebuffer only on IPU DI0.
That is correct. As I stated in the commit message, the goal was to add
LCD support to allow to display a splashscreen in u-boot. On the board I
Hi, Wolfgang,
2010/10/22 Wolfgang Denk w...@denx.de:
Dear Jason Liu,
In message aanlktimesozpvruutursgkxtqk0tyjgdxtck7egzm...@mail.gmail.com you
wrote:
Geting mac address from FUSE is the right way for mx51 and it's not
difficult to add FUSE read function due to the FUSE read is simple as
Dear Roy Zang,
In message 1287721745-7503-1-git-send-email-tie-fei.z...@freescale.com you
wrote:
The RAM relocated address is useful when debugging or there is u-boot
crash dump. So always print it instead of debug.
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
Cc: Wood Scott-B07421
From: John Schmoller jschmol...@xes-inc.com
Add a new 'pci enum' command which re-enumerates the PCI buses. This
command is enabled via the CONFIG_CMD_PCI_ENUM define and can be useful
in boards with FPGAs connected via PCI/PCIe, boards that support PCI
hot-plugging, or during PCI debug.
Also
Common Freescale code for PCI initialization now exists, so migrate X-ES
boards to use it.
Signed-off-by: Peter Tyser pty...@xes-inc.com
CC: Kumar Gala ga...@kernel.crashing.org
---
board/xes/common/fsl_8xxx_pci.c | 328 ++-
include/configs/XPEDITE5170.h |
From: John Schmoller jschmol...@xes-inc.com
Add board_flash_wp_on() to check a pca9557 gpio pin to see
if non-volatile memory write protection is enabled.
Previously, write protected NOR flashes would fail initialization which
resulted in a bootup error such as:
...
DTT: 53 C local / 64 C
Some U-Boot images for X-ES boards support multiple products in the same
family. For example, the XPedite5370, XPedite5371, and XPedite5372 are
similar enough that one U-Boot image can work on all 3 cards. To make it
clear that a U-Boot image can work on boards of the same family, rename
the
- Clean up ifdeffery
- Update coding style
No functional change should have occurred.
Signed-off-by: Peter Tyser pty...@xes-inc.com
Acked-by: Heiko Schocher h...@denx.de
---
post/drivers/i2c.c | 48 +++-
1 files changed, 23 insertions(+), 25
The logic previously used in the I2C post was a bit convoluted.
Signed-off-by: Peter Tyser pty...@xes-inc.com
Acked-by: Heiko Schocher h...@denx.de
---
post/drivers/i2c.c | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/post/drivers/i2c.c
According to the I2C specification device address 0 is the general call
address, ie a broadcast address. The I2C specification states that the
format of a general call uses at least 2 bytes, which U-Boot's probing
routine does not adhere to.
Not probing device address 0 will prevent possible
Add the ability to not report an I2C POST error for a set of given I2C
addresses on bootup. This is useful for cases when a device may or may
not be present, and neither case is considered an error. For example:
- Some form factors such as XMC and Compact PCI Express have an I2C
EEPROM whose
The PIC's TFRR register doesn't affect hardware and is generally unused,
so use as storage for the POST word.
Signed-off-by: Peter Tyser pty...@xes-inc.com
CC: Kumar Gala ga...@kernel.crashing.org
---
include/post.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
Add memory and I2C posts to the XPedite517x/520x/537x board families.
Signed-off-by: Peter Tyser pty...@xes-inc.com
CC: Kumar Gala ga...@kernel.crashing.org
---
include/configs/xpedite517x.h | 17 +
include/configs/xpedite520x.h | 10 ++
include/configs/xpedite537x.h
Signed-off-by: Peter Tyser pty...@xes-inc.com
CC: h...@denx.de
---
doc/README.POST | 11 -
include/configs/KUP4K.h |6 ++--
include/configs/KUP4X.h |6 ++--
include/configs/TB5200.h |8 +++---
include/configs/TQM5200.h |8 +++---
include/configs/cm5200.h
From: John Schmoller jschmol...@xes-inc.com
Initial support for Extreme Engineering Solutions XPedite5500 -
a P2020-based PMC/XMC single board computer.
Signed-off-by: John Schmoller jschmol...@xes-inc.com
Signed-off-by: Peter Tyser pty...@xes-inc.com
CC: Kumar Gala ga...@kernel.crashing.org
---
With debug the follow is printed:
= saveenv
Saving Environment to Flash...
Data to save 0x18000
Data (start 0xfff48000, len 0x18000) saved at 0x7fe63f20
Protect off FFF4 ... FFF5
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash...
The RAM relocated address is useful when debugging or there is u-boot
crash dump. So always print it instead of debug.
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
Cc: Wood Scott-B07421 b07...@freescale.com
I use a similar patch here too so:
Acked-by: Joakim Tjernlund
Hello, Stefano,
It looks that your framebuffer patch supports one framebuffer only on IPU DI0.
Could you please consider to add the support for framebuffer on IPU
DI1, as someone may design a board whose primary display device is
connected with IPU DI1.
And, it will be better if the following
Hello Peter,
Peter Tyser wrote:
Signed-off-by: Peter Tyser pty...@xes-inc.com
CC: h...@denx.de
---
doc/README.POST | 11 -
include/configs/KUP4K.h |6 ++--
include/configs/KUP4X.h |6 ++--
include/configs/TB5200.h |8 +++---
include/configs/TQM5200.h
98 matches
Mail list logo
