Remy Bohmer wrote:
> In a few minutes I will post a patch which I hope it will solve this.
> Can you please try it on your board?
I have tried, the old error is gone, but the board hangs probably after
getting the first packets:
$ tftp 0xa001 u-boot.bin
dm9000 i/o: 0x800, id: 0x9a46
Guys,
I think I have found a reason / partial fix, after getting some parameters
tweaked and pimping out the debug routine to printf() almost the entire SPD
table here is what I found.
1) The SPD tables for DDR1 and DDR2 are dfferent by about 10-15%. We'll need
to add a separate SPD struct to fu
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Menon, Nishanth
> Sent: Wednesday, May 21, 2008 11:31 AM
> To: Sascha Hauer
> Cc: u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed Mohammed,
> Khasim; Laurent Desnogues;
> [EMAIL PROTECTED]
> Su
Sascha,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Menon, Nishanth
> Sent: Wednesday, May 21, 2008 11:31 AM
> To: Sascha Hauer
> Cc: u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed Mohammed,
> Khasim; Laurent Desnogues;
> [EMAIL PROTECT
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 3:27 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasi
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 12:49 PM
> To: Menon, Nishanth
> Cc: Peter Pearse; u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed
> Mohammed, Khasim; Laurent
> Desnogues; [EMAIL PROTECTED]
> Subject: Re: [
Sascha,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Menon, Nishanth
> Sent: Wednesday, May 21, 2008 11:30 AM
> To: Sascha Hauer
> Cc: u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed Mohammed,
> Khasim; Laurent Desnogues;
> [EMAIL PROTECT
Sascha,
> -Original Message-
> From: Menon, Nishanth
> Sent: Tuesday, June 03, 2008 10:38 AM
> To: 'Laurent Desnogues'; u-boot-users@lists.sourceforge.net; [EMAIL
> PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim
> Subject: RE: [Patch 10/17] U-Boot-V
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 12:47 PM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khas
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 10:24 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khas
Sascha,
Makefiles were updated in last couple of days.
Retrying with further fixes for sparse to work:
CFLAGS: "-D __ARM__" should have been "-D__ARM__".
Further -nostdinc in Makefile is redfined by
commit ID:847934bc960ba1588c87e283118318dfdd78d4c0
This is unnecessary as NOSTDINC_FLAGS in root Mak
Dear all,
I study the U-boot.bin file using the objdump command, I don't know how the
CPU can find the right string address when puts() string.
For example, In my binary file, the string "Call backtrace: " in func
"print_backtrace()" address is :0x0002b280, the func address is
0xfff03564, How th
On Jun 3, 2008, at 7:35 PM, Andy Fleming wrote:
> On Thu, May 29, 2008 at 11:22 AM, Kumar Gala <[EMAIL PROTECTED]
> > wrote:
>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>> ---
>> cpu/mpc85xx/fdt.c | 128 +++
>> ++
>> 1 files changed, 128 inse
Dear Wolfgang,
I've removed CONFIG_OF_FLAT_TREE as a cleanup. It would be nice to get
it into the 1.34 release, but it can wait for 1.35 if anybody is
uncomfortable with this. Since it is enabled on only two boards, it
doesn't affect most boards either way.
Best regards,
gvb
The following
This was configured to use the deprecated CONFIG_OF_FLAT_TREE, change
to CONFIG_OF_LIBFDT.
WARNING: This conversion is untested because I do not have a board to
test it on.
NOTE: The FDT blob (DTS) must have an /aliases/ethernet0 and (optionally)
/aliases/ethernet1 property for the ethernet to wo
The following troika of patches switch the final two boards (mpc7448hpc2
and stxxst) from using CONFIG_OF_FLAT_TREE to CONFIG_OF_LIBFDT and then
remove support for CONFIG_OF_FLAT_TREE.
Since I don't have access to the boards I could not test them. If someone
can test the conversions and provide p
This was configured to use the deprecated CONFIG_OF_FLAT_TREE, change
to CONFIG_OF_LIBFDT.
WARNING: It appears that this board lost its ability to boot via a
flattened device tree prior to this changeset.
WARNING: This conversion was untested because I do not have a board to
test it on.
Signed-o
This was configured to use the deprecated CONFIG_OF_FLAT_TREE, change
to CONFIG_OF_LIBFDT.
WARNING: This conversion is untested because I do not have a board to
test it on.
NOTE: The FDT blob (DTS) must have an /aliases/ethernet0 and (optionally)
/aliases/ethernet1 property for the ethernet to wo
The following troika of patches switch the final two boards (mpc7448hpc2
and stxxst) from using CONFIG_OF_FLAT_TREE to CONFIG_OF_LIBFDT and then
remove support for CONFIG_OF_FLAT_TREE.
Since I don't have access to the boards I could not test them. If someone
can test the conversions and provide p
Use CONFIG_OF_LIBFDT instead to support flattened device trees. It is
cleaner, has better functionality, and is better supported.
Signed-off-by: Gerald Van Baren <[EMAIL PROTECTED]>
---
README|9 +-
board/freescale/mpc7448hpc2/mpc7448hpc2.c | 22 +--
boa
All,
Correct, I did some math and they almost work out for DDR1 values
However into DDR2 clocks speeds it gets increasingly bad.
Going through the SPD tables I have found, it looks like there is not a
mathematical way to convert those values, as they are in nanoseconds but
only some are actually
On Thu, May 29, 2008 at 11:22 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> cpu/mpc85xx/fdt.c | 128
> +
> 1 files changed, 128 insertions(+), 0 deletions(-)
>
> diff --git a/cpu/mpc85xx/fdt.c
"Russell McGuire" <[EMAIL PROTECTED]> wrote on 06/03/2008
04:15:55 PM:
>
> I haven't gone through the rest yet, but most likely if we want to keep
SPD
> working for DDR2, we'll have to add the DDR2 definitions SPD into the
code,
> as it looks like the DDR2 port is only partially complete.
>
>
On Mon, Jun 2, 2008 at 6:22 PM, Andy Fleming <[EMAIL PROTECTED]> wrote:
> On Wed, May 28, 2008 at 12:53 PM, <[EMAIL PROTECTED]> wrote:
>> From: Wolfgang Grandegger <[EMAIL PROTECTED]>
>>
>> Move all TQM board directories to the vendor specific directory "tqc"
>> for modules from TQ-Components GmbH
On Thu, May 29, 2008 at 1:21 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
>
> Fix warning that the first version introduced.
applied, gracias
-
Check out the new SourceForge
Bruce,
I think you've hit upon something here.
After checking the SPD tables during the intial comparison for data rates,
it is clear that 1) the DDR2 bit fields are not defined properly. i.e. it
looks like the big if-if-else statement specifically does not have valid
DDR2 values defined for clk_c
>
> Today, I went to my local PC store, and bought EVERY type of DDR2
> SODIMM memory they had, Kingston, Crucial, PC4200, PC5300 four
> different kinds of memory, and NONE of them will boot with U-boot now.
>
Hay Russell,
I don't have patches, and I haven't worked on this in a long time beca
Hi Russell,
> Reposting on previous issue that is becoming a lot more painful.
>
> Today, I went to my local PC store, and bought EVERY type of DDR2 SODIMM
> memory they had, Kingston, Crucial, PC4200, PC5300 four different kinds
> of memory, and NONE of them will boot with U-boot now.
>
> We
Guys,
Reposting on previous issue that is becoming a lot more painful.
Today, I went to my local PC store, and bought EVERY type of DDR2 SODIMM
memory they had, Kingston, Crucial, PC4200, PC5300 four different kinds of
memory, and NONE of them will boot with U-boot now.
We apparently ha
On Mon, 2 Jun 2008 16:03:56 -0700
"Russell McGuire" <[EMAIL PROTECTED]> wrote:
> To work around this we need to remove the clearing of the FDX bit while in
> RGMII, RTBI, TBI, or GMII modes.
>
> The only modes that can clear the FDX bit are MII or RMII.
>
> Since I am not the author of the drive
The following changes since commit 1f1554841a4c8e069d331176f0c3059fb2bb8280:
Wolfgang Denk (1):
Merge branch 'master' of /home/wd/git/u-boot/custodians
are available in the git repository at:
git://www.denx.de/git/u-boot-cfi-flash.git master
Vasiliy Leoenenko (2):
cfi_flash: su
On Wednesday 07 May 2008, Vasiliy Leoenenko wrote:
> cfi_flash: enable M18 flash chips family support.
>
> Added new command set ID. Buffered write command processing is changed in
> order to support M18 flash chips family.
Applied to u-boot-cfi-flash. Thanks.
Best regards,
Stefan
==
On Wednesday 07 May 2008, Vasiliy Leoenenko wrote:
> cfi_flash: support of long cmd in U-boot.
>
> Some NOR flash chips needs support of commands with length grether than max
> value size of uchar. For example all M18 family chips use 0x1ff command in
> buffered write mode as value of program loops
On Mon, 2 Jun 2008 15:16:02 +0200
Tor Krill <[EMAIL PROTECTED]> wrote:
> +U_BOOT_CMD (bubbacmd, 3, 1, do_bubbacmd,
> + "bubbacmd- Board specific commands for Bubba TWO\n",
> + "spindown [dev] - spin down disk dev\n"
> + "bubbacmd spinup [dev] - spin up disk dev
> Hi there
>> But if I do that when there is no network u-boot never recovers. Can
>> someone tell > me the way out. It is successful when network is
>> available, >>though.
>Are you using a old (really old) u-boot. This behaviour was observed
>on u-boot 1.1.2, but when we upgraded to 1
Hi,
On Mon, Jun 2, 2008 at 1:21 PM, Avinash Vijayvergia
<[EMAIL PROTECTED]> wrote:
> Hi there
> But if I do that when there is no network u-boot never recovers. Can someone
> tell > me the way out. It is successful when network is available,
> though.
Are you using a old (really old)
The following changes since commit 10a3367955bc2033b288915f8f10d0e507fe2fa1:
Stefan Roese (1):
Merge branch 'master' of /home/stefan/git/u-boot/u-boot
are available in the git repository at:
git://www.denx.de/git/u-boot-ppc4xx.git master
Grant Erickson (3):
PPC4xx: Simplified p
On Friday 30 May 2008, Matthias Fuchs wrote:
> This patch removes some dead code from CPCI405 board's
> config files. JFFS2 support is also removed. It's not used and
> CPCI4052 does not build anymore without some size reduction.
Applied to u-boot-ppc4xx repo. Thanks.
Best regards,
Stefan
==
On Thursday 29 May 2008, Kenneth Johansson wrote:
> UNDEF_SYM is a shell variable in the main Makefile used to force the
> linker to add all u-boot commands to the final image. It has no use here.
Applied to u-boot-ppc4xx repo. Thanks.
Best regards,
Stefan
===
On Thursday 22 May 2008, Grant Erickson wrote:
> This patch (Part 2 of 2):
>
> * Rolls up a suite of changes to enable correct primordial stack and
> global data handling when the data cache is used for such a purpose
> for PPC40x-variants (i.e. CFG_INIT_DCACHE_CS).
>
> * Related to the first,
On Thursday 22 May 2008, Grant Erickson wrote:
> This patch (Part 1 of 2):
>
> * Rolls up a suite of changes to enable correct primordial stack and
> global data handling when the data cache is used for such a purpose
> for PPC40x-variants (i.e. CFG_INIT_DCACHE_CS).
>
> * Related to the first,
On Wednesday 21 May 2008, Grant Erickson wrote:
> This patch simplifies post_word_{load,store} by using the preprocessor
> to eliminate redundant, copy-and-pasted code.
Applied to u-boot-ppc4xx repo. Thanks.
Best regards,
Stefan
===
According to the Application Notes of the DM9000, only the 2 bits 0:1 of
the status byte need to be checked to identify a valid packet in the fifo
But, The several different Application Notes do not all speak the same
language on these bits. They do not disagree, but only 1 Application Note
noted
Hello Stefano,
> this patch does not work on the trizeps board. I get the following error:
> Loading: DM9000 error: status check fail: 0x6d
I think I know where this one comes from.
The code reporting this error is actually not changed, but the pace in
which it is called is much faster with the
On Jun 3, 2008, at 12:13 PM, Morrison, Tom wrote:
> OK - wrong list - sorry Kumar - yes, I do have a 8572 DS system -
>
> So, there is no support plans in uboot 1.3.3 for sbc8572 as there
> is for boards like sbc8548 and sbc8641D?
You'd have to ask who ever creates the sbc8572 board that questio
On Tue, Jun 03, 2008 at 10:36:05AM -0500, Menon, Nishanth wrote:
> Sascha,
> > -Original Message-
> > From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 03, 2008 3:18 AM
> > To: Menon, Nishanth
> > Cc: Peter Pearse; u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed
On Tue, Jun 03, 2008 at 10:29:03AM -0500, Menon, Nishanth wrote:
> Sascha,
> > -Original Message-
> > From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 03, 2008 3:09 AM
> > To: Menon, Nishanth
> > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL
> > PROT
OK - wrong list - sorry Kumar - yes, I do have a 8572 DS system -
So, there is no support plans in uboot 1.3.3 for sbc8572 as there
is for boards like sbc8548 and sbc8641D?
tom
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 12:11 PM
To: Morri
Hi Wolfgang,
> Andy Fleming wrote:
>> On Wed, May 28, 2008 at 1:12 PM, Wolfgang Grandegger <[EMAIL PROTECTED]>
>> wrote:
>>> The boot output is now aligned poperly with other boot output
>>> lines, e.g.:
>>>
>>> FLASH: 128 MB
>>> L2:512 KB enabled
>>>
>>> Signed-off-by: Wolfgang Grandegger
Ben Warren wrote:
> Wolfgang,
>
> Is the merge window open for the rest of today, or is it closed? If
> open, I'll look at this patch set later today and act on it. Otherwise
> this goes into the 'for later' bin.
>
Hi,
this patch does not work on the trizeps board. I get the following error:
Hi Hugo,
> Detlev Zundel wrote:
>> Hi Wolfgang and Hugo,
>>
>> while studying the mail footer of Hugo, I found a slightly
>> problematic phrasing:
>>
>>> THIS MESSAGE AND ALL...
>>
>> So Hugo, please get rid of that message or I will advise Wolfgang to
>> heed your footer...
>
> I got rid of th
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 10:14 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khas
The following changes since commit 1f1554841a4c8e069d331176f0c3059fb2bb8280:
Wolfgang Denk (1):
Merge branch 'master' of /home/wd/git/u-boot/custodians
are available in the git repository at:
git://www.denx.de/git/u-boot-nand-flash.git master
Dirk Behme (1):
nand: Correct NAND
On Jun 3, 2008, at 9:41 AM, Morrison, Tom wrote:
> I am wondering if there is a development branch that contains
> support for the Freescale 8572CDS…Looking in the latest uboot
> version (1.3.3) there is support for sbc8641 & sbc8548 – but
> no specific support for a sbc8572?
Such questions are
> -Original Message-
> From: Laurent Desnogues [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 3:23 AM
> To: Menon, Nishanth; u-boot-users@lists.sourceforge.net; Laurent Desnogues;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed
> Mohammed,
> Khasim
>
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 3:18 AM
> To: Menon, Nishanth
> Cc: Peter Pearse; u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed
> Mohammed, Khasim; Laurent
> Desnogues; [EMAIL PROTECTED]
> Subject: Re: [P
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 3:09 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasi
On Tue, Jun 03, 2008 at 10:04:29AM -0500, Menon, Nishanth wrote:
> Sascha,
>
> > -Original Message-
> > From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 03, 2008 3:08 AM
> > To: Menon, Nishanth
> > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL
> > P
On Tue, Jun 03, 2008 at 09:39:51AM -0500, Menon, Nishanth wrote:
> Sascha,
> > -Original Message-
> > From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 03, 2008 9:15 AM
> > To: Menon, Nishanth
> > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL
> > PROT
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 3:09 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khas
Wolfgang,
Is the merge window open for the rest of today, or is it closed? If
open, I'll look at this patch set later today and act on it. Otherwise
this goes into the 'for later' bin.
regards,
Ben
Remy Bohmer wrote:
> The following 6 patches contain several fixes and cleanups for
> the DM9000
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 3:08 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khas
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 9:15 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasi
On Tue, Jun 03, 2008 at 07:47:25AM -0500, Menon, Nishanth wrote:
> Sascha,
> > -Original Message-
> > From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 03, 2008 3:08 AM
> > To: Menon, Nishanth
> > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL
> > PROT
U-boot can complain a lot about 'checksum bad' when it is attached to the
network.
It is annoying for ordinary users who start to doubt the network connection
in general when they see messages like this.
This is caused by the routine NetCksumOk() which cannot handle IP-headers longer
than 20 byte
The eth_send routine of the U-boot DM9000x driver does not match the
DM9000 or DM9000A application notes/programming guides.
This change improves the stability of the DM9000A network controller.
This change has been tested with DM9000A, DM9000E, DM9000EP.
Signed-off-by: Remy Bohmer <[EMAIL PROTE
The following 6 patches contain several fixes and cleanups for
the DM9000A network controller. It turned out that the U-boot DM9000 driver
was not working with this particular version of the DM9000 series.
At low speeds (10MBit) it was sometimes capable of getting a peer-2-peer
connection, but 100
Some lines of the U-boot DM9000x driver are longer than 80 characters, or
need some other minor cleanup.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
drivers/net/dm9000x.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
Index: u-boot-git
According to the application notes of the DM9000 v1.22 chapter 5.2 bullet 2,
the
reset procedure must be done twice to properly reset the DM9000 by means of
software.
This errata is not needed anymore for the DM9000A, but it does not bother it.
This change has been tested with DM9000A, DM9000E,
The DM9000A network controller does not work with the U-boot DM9000x driver.
Analysis showed that many incoming packets are lost.
The DM9000A Application Notes V1.20 (section 5.6.1) recommend that the poll to
check for a valid rx packet be done on the interrupt status register, not
directly by per
It seems that the debugging code of the DM9000x driver in U-boot has not been
compiled for a long time, because it cannot compile...
Also rearranged some loglines to get more useful info while debugging.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
drivers/net/dm9000x.c | 33 +++
The U-boot DM9000x driver contains a compile time bus-width definition for
the databus connected to the network controller.
This compile check makes the code unclear, inflexible and is unneccessary.
It can be asked to the network controller what its bus-width is by reading bits
6 and 7 of the inte
The option CONFIG_BOOTP_RANDOM_DELAY does not compile, because of a
missing 'extern' inside the net/bootp.h header.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
net/bootp.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: u-boot-git-22052008/net/bootp.h
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 3:08 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasi
The driver need wait for the device updating signature
to host. if we don't wait for it, the driver can not detect
the device(disk) when the system power up.
Signed-off-by: Dave Liu <[EMAIL PROTECTED]>
---
drivers/block/fsl_sata.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
On Wed, May 21, 2008 at 11:29:45AM -0500, Menon, Nishanth wrote:
> This patch adds the generic OMAP headers and OMAP specific headers.
>
> Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]>
Looks mostly ok, only one comment...
>
> ---
> include/asm-arm/arch-omap/bits.h | 65
> in
On Tue, Jun 3, 2008 at 10:12 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote:
> Is this really ARMCORTEX specific or arm v7 specific?
This is not Cortex A8 specific, it's v7-A (and hopefully will be the same
in upcoming ARM architectures).
> Anyway, this looks
> like the start of another ifdef mess, w
On Wed, May 28, 2008 at 10:39:07AM -0500, Menon, Nishanth wrote:
> As per the thread in:
> http://www.nabble.com/-Patch-06-17--U-Boot-V2%3AARM%3A-Add-sizes.h-tt17372780.html#a17372780
> sizes.h dependency is removed from the following patch. This is a
> resubmission.
>
> This patch introduces sup
On Wed, May 21, 2008 at 11:28:55AM -0500, Menon, Nishanth wrote:
> This patch adds support for OMAP3 platforms. This is mainly to setup the
> infrastructure. ARMV7 requires a different I/D cache cleanup code which is
> introduced in this patch.
>
> Thanks to Laurent in pointing out the Cortex-A8
On Wed, May 21, 2008 at 11:28:29AM -0500, Menon, Nishanth wrote:
> This introduces support for NS16550 and related OMAP support. This driver is
> a port from Uboot v1 driver from OMAP's Uboot tree.
> OMAP U-Boot V1 source is available here:
> http://linux.omap.com/pub/bootloader/3430sdp/u-boot-v1
On Wed, May 21, 2008 at 11:28:12AM -0500, Menon, Nishanth wrote:
> This patch provides support for loadb and loady and enables the broken
> feature. xyzModem.c is brought in from U-Boot V1, Lindent, checkpatch and
> sparse cleaned :).
>
> Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]>
>
> ---
On Wed, May 21, 2008 at 11:26:25AM -0500, Menon, Nishanth wrote:
> The default setup of ARM memory allocation is as follows:
>
> Stack Area
>
> Heap Area
> ---
> _u_boot_start
> Rest of U-Boot..
>
> This is an excellent strategy to catch stack overflow and memory buffer
> overflow iss
On Wed, May 21, 2008 at 11:25:15AM -0500, Menon, Nishanth wrote:
> get_time_ns does a simplistic delta = cycle_now - cycle_last. It is possible
> that the h/w counter reached max and reset back to 0.
> This patch addresses this issue by checking for rollover condition.
>
> NOTE 1: This does not g
NAND FSL UPM: driver re-write using the hwcontrol callback
This is a re-write of the NAND FSL UPM driver using the more universal
hwcontrol callback (instead of the cmdfunc callback). Here is a brief
list of furher modifications:
- For the time being, the UPM setup writing the UPM array has been
Andy Fleming wrote:
> On Wed, May 28, 2008 at 1:12 PM, Wolfgang Grandegger <[EMAIL PROTECTED]>
> wrote:
>> The boot output is now aligned poperly with other boot output
>> lines, e.g.:
>>
>> FLASH: 128 MB
>> L2:512 KB enabled
>>
>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
>
>
85 matches
Mail list logo
