Dear Albert ARIBAUD,
In message 4cf74fed.2030...@free.fr you wrote:
BTW... Why on Earth is it an uint8? Probably a space saving measure, but
one I think is not really fruitful, because of probable paddings and
alignments; making it an int would allow using smsc_id directly as
values for
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Thursday, December 02, 2010 1:21 PM
To: Wolfgang Denk
Cc: u-boot@lists.denx.de; Premi, Sanjeev
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Hi Wolfgang,
Le
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Thursday, December 02, 2010 12:30 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev; Wolfgang Denk
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 22:39,
Le 02/12/2010 09:13, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4cf74fed.2030...@free.fr you wrote:
BTW... Why on Earth is it an uint8? Probably a space saving measure, but
one I think is not really fruitful, because of probable paddings and
alignments; making it an int would
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Thursday, December 02, 2010 1:57 PM
To: Wolfgang Denk
Cc: u-boot@lists.denx.de; Premi, Sanjeev
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
[snip]
So Sanjeev
Hi Sanjeev,
Le 02/12/2010 09:30, Premi, Sanjeev a écrit :
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Thursday, December 02, 2010 1:57 PM
To: Wolfgang Denk
Cc: u-boot@lists.denx.de; Premi, Sanjeev
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker
Dear Albert ARIBAUD,
In message 4cf7583c.7000...@free.fr you wrote:
Does it help when you change the *(.bss) in
arch/arm/cpu/armv7/u-boot.lds into *(.*bss)
(so it also includes any .sbss objects) ?
No change.
Hm... Maybe it is indeed not a good idea to mix short objects with
those
Hi Sekhar,
Hmm, I had tested DA850 EVM yesterday with U-Boot 2010.12-rc2,
and was able to successfully boot (at least most of the times).
---logs
Booting with TI UBL
Device OPP (300MHz, 1.2V)
U-Boot 2010.12-rc2 (Nov 30 2010 - 11:55:35)
I2C: ready
DRAM: 128 MiB
Using default
I have changed the davinci timer code to work with the, originally at91
only, gd variables:
unsigned long timer_rate_hz;
unsigned long tbl;
unsigned long tbu;
unsigned long long timer_reset_value;
It does use the timer_reset_value to keep compatibility
Hi!
thanks for your quick replys. More helpful than the manufacturer thats
for sure.
I totally admit that im a newbie at all this, so sorry if I dont
understand things.
I was under the impression that the MAC address was supplied by the
hardware supplier. (at least this seems to be the
Mark,
Please do not write your answers above the text you answer to (i.e., do
not top-post)
Le 02/12/2010 10:48, Mark Underwood a écrit :
Hi!
thanks for your quick replys. More helpful than the manufacturer thats
for sure.
I totally admit that im a newbie at all this, so sorry if I dont
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board
This patch adds the support MFP support for Marvell ARMADA100 SoCs
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log v3 REPOST:
macro MFPR_PTR_UPDATE added
arch/arm/include/asm/arch-armada100/mfp.h | 231 +
1 files changed, 231 insertions(+), 0
Dear Prafulla Wadaskar,
In message 1291302695-15561-2-git-send-email-prafu...@marvell.com you wrote:
This patch adds the support MFP support for Marvell ARMADA100 SoCs
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log v3 REPOST:
macro MFPR_PTR_UPDATE added
Hi Prafulla,
On Thu, Dec 2, 2010 at 11:11 PM, Prafulla Wadaskar prafu...@marvell.com wrote:
This patch adds the support MFP support for Marvell ARMADA100 SoCs
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log v3 REPOST:
macro MFPR_PTR_UPDATE added
This patch does following changes:
* Change the type (u8 - int) for omap3_evm_version.
* Introduce an 'undefined' board revision for init
value.
* Use of #define instead of magic numbers
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/ti/evm/evm.c | 39
Dear Prafulla Wadaskar,
In message 1291302695-15561-1-git-send-email-prafu...@marvell.com you wrote:
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Thursday, December 02, 2010 2:12 PM
To: Premi, Sanjeev
Cc: Wolfgang Denk; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Hi Sanjeev,
Le
Dear Prafulla Wadaskar,
In message f766e4f80769bd478052fb6533fa745d19a9291...@sc-vexch4.marvell.com
you wrote:
Since the mfp.c is for generic case, and should be made as generic at
the beginning...
Sure.. but I don't know how it will be on other SoCs?
Apart from that what would be
Dear Lei Wen,
In message aanlktimztfsml0bzbti+exrzjkg5jh9kxqzukevrc...@mail.gmail.com you
wrote:
Do we really need this? I think the better way to configure GPIO MFP
is doing like below.
That is create each GPIO name, and define its MFPD and MFP_AF.
+/* UART2 */
+#define MFP47_UART2_RXD
Dear Sanjeev Premi,
In message 1291288812-12653-1-git-send-email-pr...@ti.com you wrote:
This patch does following changes:
* Change the type (u8 - int) for omap3_evm_version.
* Introduce an 'undefined' board revision for init
value.
* Use of #define instead of magic numbers
Dear Premi, Sanjeev,
In message b85a65d85d7eb246be421b3fb0fbb5930247b9a...@dbde02.ent.ti.com you
wrote:
Just posted the patch. The u-boot comes up on the EVM - only after
sort related change in the Makefile. Haven't debuged it yet.
Could you ***please*** be a bit more precise?
What EXACTLY
On 01/12/10 12:16, Prafulla Wadaskar wrote:
After ARM relocation,
any code executed directly or indirectly by board_init_f() have
global (BSS) variables need to be fixed. mostly timer.c needs to
fix on most of the ARM platforms.
This patch makes timer related variables in gd_t available for
Le 02/12/2010 12:37, Wolfgang Denk a écrit :
Dear Sanjeev Premi,
In message1291288812-12653-1-git-send-email-pr...@ti.com you wrote:
This patch does following changes:
* Change the type (u8 - int) for omap3_evm_version.
* Introduce an 'undefined' board revision for init
value.
Dear Albert ARIBAUD,
In message 4cf7896b.5090...@free.fr you wrote:
Note that initialization should be unnecessary if the static variable is
int rather than u8.
It should ALWAYS be not necessary.
Otherwise we have a bug, and that bug needs to be fixed rather than
papered over.
Best
Le 02/12/2010 13:01, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4cf7896b.5090...@free.fr you wrote:
Note that initialization should be unnecessary if the static variable is
int rather than u8.
It should ALWAYS be not necessary.
I understand your point re: the linker warning,
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Thursday, December 02, 2010 5:09 PM
To: Premi, Sanjeev
Cc: Albert ARIBAUD; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Dear Premi, Sanjeev,
In message
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Thursday, December 02, 2010 5:07 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
Dear Sanjeev Premi,
In message
Hi Nick,
On Thu, Dec 2, 2010 at 4:39 AM, Nick Thompson nick.thomp...@ge.com wrote:
I have changed the davinci timer code to work with the, originally at91
only, gd variables:
unsigned long timer_rate_hz;
unsigned long tbl;
unsigned long tbu;
unsigned long
Maybe in init sequens asm func, i used turn on led to check which func faild.
--
View this message in context:
http://old.nabble.com/-U-Boot--OMAP3%3A-relocation-and-bss-usage-%28timer%2C-gpmc%2C-...%29-tp30341173p30358424.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
This change allows the davinci timer functions to be used before
relocation since it avoids using static variables prior to BSS being
made available.
The code is based on that used in the at91 timers, modified to use
a davinci specific hardware timer. It also maintains reset_timer()
to allow
Dear Albert ARIBAUD,
In message 4cf7922b.3020...@free.fr you wrote:
Now, on an unrelated note, omap3_emv's code arbitrarily uses an u8 where
an int (or enum) would be more appropriate, and this should be changed
not because it removes a linker warning, but because the u8 choice is
Dear Premi, Sanjeev,
In message b85a65d85d7eb246be421b3fb0fbb5930247b9a...@dbde02.ent.ti.com you
wrote:
Do you still need to remove the $(sort) call for the LIBS? That
should NOT be done.
...
I know it shouldn't be done - but just trying to take problem one by
one. Unless you want me to
The link_name variable is declared inside the if block and it is used
outside it through the name pointer.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
fs/ubifs/ubifs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ubifs/ubifs.c
Hi Nick,
On Thu, Dec 2, 2010 at 8:57 AM, Nick Thompson nick.thomp...@ge.com wrote:
This change allows the davinci timer functions to be used before
relocation since it avoids using static variables prior to BSS being
made available.
The code is based on that used in the at91 timers, modified
On 02/12/10 14:18, Ben Gardiner wrote:
Hi Nick,
On Thu, Dec 2, 2010 at 8:57 AM, Nick Thompson nick.thomp...@ge.com wrote:
This change allows the davinci timer functions to be used before
relocation since it avoids using static variables prior to BSS being
made available.
Signed-off-by:
Seems original implementation forget to set the pointer to point
to the oobbuf, so when we want to see oob buf, we see nothing...
Fix it by get pointer as the oobbuf set.
Signed-off-by: Lei Wen lei...@marvell.com
---
common/cmd_onenand.c |2 ++
1 files changed, 2 insertions(+), 0
Am 02.12.2010 14:33, schrieb zfsdk:
Maybe in init sequens asm func, i used turn on led to check which func faild.
Using a LED for debugging is time consuming. And you won't see which
code still uses BSS before relocation as such code does not have to fail
(it still might work). I prefer
Yaffs image require to use the oob to store some info, so when we
burn the yaffs image, we need to also write the image's oob part
into flash.
This patch add addition suffix to onenand write to give the uboot
the power to directly burn the yaffs image to onenand.
Signed-off-by: Lei Wen
Hi Wolfgang,
sorry for the late reply. I just stumbled again over this mail.
On Monday 01 November 2010 20:05:00 Wolfgang Denk wrote:
I still wonder what's the logic behind this code. When will
read_block() return -ENOENT (aka No such file or directory) ?
What are the other possible error
Le 02/12/2010 14:58, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4cf7922b.3020...@free.fr you wrote:
Now, on an unrelated note, omap3_emv's code arbitrarily uses an u8 where
an int (or enum) would be more appropriate, and this should be changed
not because it removes a linker
Hi Lei,
Lei Wen wrote:
Since the ether may not be the only one usb gadget would be used
in the uboot, it is neccessary to do the register each time the
eth begin to work to make usb gadget driver less confussed when
we want to use two different usb gadget at the same time.
Usb gadget
Hi Kumar,
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Acked-by: Peter Tyser pty...@xes-inc.com
Tested-by: Peter Tyser pty...@xes-inc.com
snip
index e0a1fa4..9d87eaf 100644
--- a/include/configs/xpedite537x.h
+++ b/include/configs/xpedite537x.h
@@ -375,6 +375,12 @@ extern unsigned
From: John Schmoller jschmol...@xes-inc.com
According to Freescale reference manuals (eg section 13.4.4.2
Programming the UPMs of the P4080 Reference Manual):
Since the result of any update to the MxMR/MDR register must be in
effect before the dummy read or write to the UPM region, a write to
Scott Wood wrote:
If you were to immediately follow it with out_8 as currently defined,
yes. But setbits_8 should be OK.
I don't want my flash_writeX functions to make any assumptions about what
set_mux_to_diu() does. Can I just replace the __raw_readb() with an in_8()?
--
Timur Tabi
Linux
On Tue, Nov 30, 2010 at 8:00 AM, Wolfgang Denk w...@denx.de wrote:
Hello everybody.
I apologise for being a bit late with this announcement:
* U-Boot v2010.12-rc2 was released on Sunday, November 28.
* Release v2010.12 is (still) scheduled in 13 days:
on December 13, 2010.
Please help
Dear Albert ARIBAUD,
In message 4cf7c7f4.6030...@free.fr you wrote:
Well, an u8 is as good a data type as any other. The available range
of 0...255 seems more than sufficient to store the needed
information, so why should I waste 4 bytes of storage when a single
byte is sufficient as
Am 30.11.2010 20:45, schrieb Andreas Bießmann:
From: Andreas Bießmann biessm...@corscience.de
Signed-off-by: Andreas Bießmann biessm...@corscience.de
---
I can confirm this patch. It works with eb+cpux9k2 board.
regard Jens
___
U-Boot mailing list
Le 02/12/2010 19:51, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4cf7c7f4.6030...@free.fr you wrote:
Well, an u8 is as good a data type as any other. The available range
of 0...255 seems more than sufficient to store the needed
information, so why should I waste 4 bytes of
From: Matt Waddel matt.wad...@linaro.org
This patch fixes build errors in the vexpress system:
- Removed sys_proto.h requirement from syslib.c.
- Switched vexpress to the default armv7 linker script.
- Renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE.
Signed-off-by: Matt Waddel
Hi Wolfgang,
On 12/02/2010 11:13 AM, John Rigby wrote:
On Tue, Nov 30, 2010 at 8:00 AM, Wolfgang Denk w...@denx.de wrote:
Hello everybody.
I apologise for being a bit late with this announcement:
* U-Boot v2010.12-rc2 was released on Sunday, November 28.
* Release v2010.12 is (still)
Hi Albert,
On 12/01/2010 08:42 AM, Albert ARIBAUD wrote:
Hi Darius,
Le 30/11/2010 10:19, Darius Augulis a écrit :
I understand, that there is such rule in u-boot, but it's ... at least
strange.
Even linux kernel doesn't use such approach and uses simple defines instead.
One big
Hi Kumar,
#elif defined (CONFIG_MPC85xx)
#include asm/immap_85xx.h
-#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + offsetof(ccsr_pic_t, tfrr))
+#define _POST_WORD_ADDR (CONFIG_SYS_IMMR +
CONFIG_SYS_MPC85xx_PIC_OFFSET + \
+ offsetof(ccsr_pic_t, tfrr))
Dear Albert ARIBAUD,
A second problem, the board does not restart (reset command).
I find out that a NULL pointer used by reset code, was also
relocated.
How did you come to this conclusion? NULL pointers are constants and
thus are *not* relocated.
This problem will be gone with Andreas
Le 02/12/2010 21:27, Jens Scharsig a écrit :
I suggest visually running through all (board or cpu-specific) code that
runs as part of execution board_init_f() and checking that no global is
ever used -- BSS or initialized.
Andreas mirror BSS check says OK, But the board hangs on write access
Some of the times, the boot hung after printing DRAM: 128 MiB,
but never did it hang without printing anything.
The same here.
Beagleboard xM rev.A hangs after DRAM: 256 MiB
Regards,
--
Carlo Caione
___
U-Boot mailing list
U-Boot@lists.denx.de
This isn't used - delete it.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
include/configs/MPC8569MDS.h |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/include/configs/MPC8569MDS.h b/include/configs/MPC8569MDS.h
index c7973b4..720b5b6 100644
---
Modeled after the MPC8540DS code; this will allow us to use a common
initdram() once that is available. There should be no functional
change.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
board/mpc8540eval/mpc8540eval.c | 64 +-
1 files changed,
Some platforms might want to override the default wimge=0 for
DDR. Add CONFIG_DDR_TLB_WIMGE for those platforms to use.
This will initially only be used by TQM85xx, but could be
useful for other boards or testing going forward.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
This is for boards that use the SDRAM mode on the LBC but don't
require any additional setup.
I'm merging all the initdram() calls into a single function for 85xx,
and have to be able to distinguish between boards that require an
sdram_init() function, and those that do not. We could have
As far as I can tell, this board doesn't actually configure the LBC
for SDRAM. I've renamed this to avoid confusion (and to make the
initdram() cleanup easier later.)
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
board/pm854/law.c |5 ++---
board/pm854/tlb.c |4
This patch series consists of a bunch of cleanups that allow us to use
a common initdram() on all of the non-corenet 85xx-based boards. Also,
switch to using phys_size_t to represent the size of memory returned.
Most of these patches are just code rearranges or renaming things to
get a common
This will help us go to a fixed initdram() for all 85xx boards going
forward. sdram_setup() had an argument that it didn't need, since the
value was #defined.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
board/socrates/sdram.c |4 ++--
1 files changed, 2 insertions(+), 2
Also, change this code to use phys_size_t instead of long int.
Using common naming for this function will enable us to use the common
initdram() for 85xx going forward. Other than the type change,
this is just a code rearrange.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
This board does not actually configure anything for SDRAM - change
the name to avoid confusion and make it easier to go to a common
initdram going forward.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
board/pm856/law.c |5 ++---
board/pm856/tlb.c |4 ++--
This is needed to distinguish between boards with lbc sdram
that require additional initialization and those that do not.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
include/configs/stxgp3.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
This is used to distinguish between boards that require extra setup
to use LBC sdram, and those that don't
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
include/configs/SBC8540.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/SBC8540.h
This config option is for an erratum workaround; rename it to be more
clear. Also, drop it from config files don't need it and were
undefining it.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++
arch/powerpc/cpu/mpc85xx/cpu.c|
Correct initdram to use phys_size_t to represent the size of
dram; instead of changing this all over the place, and correcting
all the other random errors I've notived, create a
common initdram that is used by all non-corenet 85xx parts. Most
of the initdram() functions were identical, with 2
On Dec 2, 2010, at 10:50 AM, Peter Tyser wrote:
Hi Kumar,
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Acked-by: Peter Tyser pty...@xes-inc.com
Tested-by: Peter Tyser pty...@xes-inc.com
snip
index e0a1fa4..9d87eaf 100644
--- a/include/configs/xpedite537x.h
+++
On Thu, 2 Dec 2010 18:19:08 -0600
Kumar Gala ga...@kernel.crashing.org wrote:
[Adding Scott W. - would like his ack on this]
Acked-by: Scott Wood scottw...@freescale.com
- k
On Dec 2, 2010, at 11:43 AM, Peter Tyser wrote:
From: John Schmoller jschmol...@xes-inc.com
According to
On Thu, Dec 2, 2010 at 5:45 PM, Becky Bruce bec...@kernel.crashing.org wrote:
This is for boards that use the SDRAM mode on the LBC but don't
require any additional setup.
I'm merging all the initdram() calls into a single function for 85xx,
and have to be able to distinguish between boards
Hi Vitaly,
On Fri, Dec 3, 2010 at 12:34 AM, Vitaly Kuzmichev vkuzmic...@mvista.com wrote:
Hi Lei,
Lei Wen wrote:
Since the ether may not be the only one usb gadget would be used
in the uboot, it is neccessary to do the register each time the
eth begin to work to make usb gadget driver less
This file has been synced (copy) from Linux source code.
This commit was based on kernel 2.6.32.
It updates gigabit related phy registers and basic definitions.
Signed-off-by: Macpaul Lin macp...@andestech.com
---
include/linux/mii.h | 270 +--
1
Sehr geehrte
Ich heibe Christian Schroeder und ich habe ein Angebot fur Sie!
Unser Unternehmen Jasckson Logistic sucht im Moment neue Arbeitskrafte! Wir
haben Ihre Bewerbungsunterlagen bei uns vor einige Zeit
liegen gefunden und jetzt mochten wir Ihnen eine Stelle von unseren
On Thursday, December 02, 2010 22:25:53 Macpaul Lin wrote:
This file has been synced (copy) from Linux source code.
pulling in updates is fine, but i dont think it makes sense to pull in
types/prototypes that arent used in u-boot
+/* This structure is used in all SIOCxMIIxxx ioctl calls */
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
On Behalf Of Carlo Caione
Sent: Friday, December 03, 2010 3:11 AM
To: U-Boot@lists.denx.de
Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released
Some of the times, the boot hung after
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Thursday, December 02, 2010 5:05 PM
To: Lei Wen
Cc: Prafulla Wadaskar; Eric Miao; Manas Saksena; Lei Wen; Yu Tang; u-
b...@lists.denx.de; Ashish Karkare; Kiran Vedere; Prabhanjan Sarnaik
Subject: Re: [U-Boot]
Mike Frysinger [mailto:vap...@gentoo.org]
???: u-boot@lists.denx.de
Macpaul Chih-Pin Lin
Re: [U-Boot] [PATCH] include/linux/mii.h: update for supporting GE
On Thursday, December 02, 2010 22:25:53 Macpaul Lin wrote:
This file has been synced (copy) from Linux source code.
pulling
Hi All,
I am trying to read images from SD cards attached to
a USB card reader. usb start command shows errors
as per logs copied below.
Is there any known issue in supporting usb card readers
In general or it's compatibility issue with few card
readers?
Regards,
Ajay
1) Card reader - [A]
This file has been synced (copy) from Linux source code.
This commit was based on kernel 2.6.32.
It updates gigabit related phy registers and basic definitions.
Signed-off-by: Macpaul Lin macp...@andestech.com
---
Change v1: pull header file from Linux.
Change v2: clean up unused code for u-boot.
Hi,
I am trying to read images from SD cards attached to
a USB card reader. usb start command shows errors
as per logs copied below.
I tested with uboot version 2009.11 and will try with latest
Uboot and update the results.
Ajay
Is there any known issue in supporting usb card readers
In
This patch introduces an extra mask-field in spansion_spi_flash_params
to support flash chips with 1-byte extended ID (like the S25FL032P).
Signed-off-by: David Jander da...@protonic.nl
The extension ID has been checked with the datasheet.
SMRDATA in a/a/c/arm920t/at91/lowlevel_init.c has wrong size. This patch
reduces it to correct size of 40 byte.
Signed-off-by: Andreas Bießmann biessm...@corscience.de
---
Dear all,
I thougt about a problem in lowlevel_init() cause of errornous booting from
NOR flash on at91rm9200ek last night .
84 matches
Mail list logo
