Re: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.
Hi Detlev, On 8/13/2010 1:20 AM, Detlev Zundel wrote: > Hi Jocke, > Instead of always performing an autoneg, check if the PHY already has a link and if it matches one of the requested modes. Initially only 100MbFD is optimized this way. >>> Isn't it about time that we think about _not_ stopping the ethernet >>> device after every transaction? >> Hi Detlev >> >> UEC does this already, my patch was to address the initial delay >> you get for the first transaction. Now my PHY based boards gets the link >> up just as quick as Fixed PHY for the first transaction. > Forgive me to not look into this any deeper, but do I understand you > correctly that you do this by essentially no-oping the eth_halt() > function? Isn't this then effectively violating what net.c expects the > device to do? > > I was thinking that net.c itself should not do this continous start/stop > thing as it has problems on many interfaces. On one ARM machine I've > again seen problems with the MAC address programming because the > eth_halt() resets the controller and so it forgets its address again. > Also the USB-CDC example where the _whole interface_ on the host side is > being torn down after each tftp transfer prompts me to think along this > line. > > So in effect I guess my response was rather a ping to Ben, sorry for > that ;) > Sorry for the delay on this. I'm all for changing the existing behavior. It seems to me that the only time we would ever want to wind an interface down is if we switch the active one (even then, I'm not sure). My world view is limited, but I can't imagine that even changing interfaces happens much in real world U-boot usage, that is the non-lab, non-interactive use cases. What would you think about adding something like ifup and ifdown commands so that users could explicitly start/stop interfaces? > Cheers >Detlev > regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] help with HP mv2120 debricking
Dear members, I was playing with my MH mv2120 NAS device and it happened to me that I stored some u-boot values and the device now hangs on boot. I am stupid I know. Last thing I did was that I've set: setenv enaPost Yes setenv enaCpuStream Yes and saved them: saveenv Now my device hangs like this (taken from serial console) . \___/|/ \___/ \___/ \__| ** Forcing LOADER mode only ** ** MARVELL BOARD: RD-88F5182-NAS-P2 LE U-Boot 1.1.4 (Oct 12 2007 - 12:30:28) Marvell version: 2.3.11_hp_1_3_1_bu...@hp U-Boot code: 0020 -> 0026FFF0 BSS: -> 0027FDBC Soc: 88F5182 A2 (DDR2) CPU running @ 500Mhz SysClock = 166Mhz , TClock = 166Mhz DRAM CS[0] base 0x size 128MB DRAM Total size 128MB 32bit width Memory test pattern: 0x, 0x, Pass [51...@fff8] Flash: 512 kB Addresses 4M - 0M are saved for the U-Boot usage. Mem malloc Initialization (4M - 3M): Done CPU : ARM926 (Rev 0) Orion 1 streaming enabled And here it hangs. I wonder if there is any way hot to reset u-boot settings. I mean some interrupt the POST by some magic key from serial consoler or something. Do you think there is any possibility to debrick my device? Thanks, Mirek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] I2C: Add support for multiple I2C busses for SNTP (effect to RTC)
Hello Heiko,
Hello Ben,
> Hello Stephan,
>
> added Ben Warren to cc: because this is a change in net,
> which also falls in his area of responsibility ...
OK, fine ...
>
> Stephan Linz wrote:
> > This patch switches to the desired I2C bus when the SNTP
> > network service is called. This can be configured using the
> > CONFIG_SYS_RTC_BUS_NUM define.
> >
> > In my eyes this is a bad and quick hack, but the same as
> > was making for the date and dtt commands (commit: 0dc018e).
> > The right way would be to move all the hardware specific i2c
> > code down to the rtc driver layer.
>
> Yes, thats would the best way, but why you don;t go this
> way?
It's easy: time Joking apart, this patch brings the network layer in
harmony to the command layer regardless of how beautiful it is. In one of the
next steps I (we) can create a new patch to resolve this unsightly condition
and move the hardware specifics into the rtc layer. Even such a patch will grow
up and change more than a dozen of files.
I'm a friend of more small steps. So I've changed this small piece. I offer to
make the big change in the next few weeks ... ?
> Beside of that, this patch look good to me ...
OK.
Ben, what do you mean?
>
> > Signed-off-by: Stephan Linz
> > ---
> > net/sntp.c | 18 ++
> > 1 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/sntp.c b/net/sntp.c
> > index 76c10ec..5544570 100644
> > --- a/net/sntp.c
> > +++ b/net/sntp.c
> > @@ -10,6 +10,14 @@
> > #include
> > #include
> >
> > +/*
> > + * FIXME: The i2c dependency should move into the RTC drivers itself.
> > + * This higher network layer must not know about hardware specifics!
> > + */
> > +#if defined(CONFIG_CMD_DATE)
> > +#include
> > +#endif
> > +
> > #include "sntp.h"
> >
> > #define SNTP_TIMEOUT 1UL
> > @@ -53,6 +61,9 @@ SntpHandler (uchar *pkt, unsigned dest, unsigned src,
> unsigned len)
> > struct sntp_pkt_t *rpktp = (struct sntp_pkt_t *)pkt;
> > struct rtc_time tm;
> > ulong seconds;
> > +#if defined(CONFIG_CMD_DATE)
> > + int old_bus;
> > +#endif
> >
> > debug("%s\n", __func__);
> >
> > @@ -66,7 +77,14 @@ SntpHandler (uchar *pkt, unsigned dest, unsigned src,
> unsigned len)
> >
> > to_tm(ntohl(seconds) - 2208988800UL + NetTimeOffset, &tm);
> > #if defined(CONFIG_CMD_DATE)
> > + /* switch to correct I2C bus */
> > + old_bus = I2C_GET_BUS();
> > + I2C_SET_BUS(CONFIG_SYS_RTC_BUS_NUM);
> > +
> > rtc_set (&tm);
> > +
> > + /* switch back to original I2C bus */
> > + I2C_SET_BUS(old_bus);
> > #endif
> > printf ("Date: %4d-%02d-%02d Time: %2d:%02d:%02d\n",
> > tm.tm_year, tm.tm_mon, tm.tm_mday,
>
> bye
> Heiko
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>
--- original Nachricht Ende
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] help with HP mv2120 debricking
Dne Po 23. srpna 2010 09:19:05 Miroslav Petricek napsal(a): > Dear members, > > > > I was playing with my MH mv2120 NAS device and it happened to me that I > stored some u-boot values and the device now hangs on boot. I am stupid I > know. > Why don't you ask your vendor ? Cheers > > > Last thing I did was that I've set: > > > > setenv enaPost Yes > > setenv enaCpuStream Yes > > > > and saved them: > > > > saveenv > > > > Now my device hangs like this (taken from serial console) > > > > . > > \___/|/ \___/ \___/ \__| ** Forcing LOADER mode only ** > > ** MARVELL BOARD: RD-88F5182-NAS-P2 LE > > > > U-Boot 1.1.4 (Oct 12 2007 - 12:30:28) Marvell version: > 2.3.11_hp_1_3_1_bu...@hp > > > > U-Boot code: 0020 -> 0026FFF0 BSS: -> 0027FDBC > > > > Soc: 88F5182 A2 (DDR2) > > CPU running @ 500Mhz > > SysClock = 166Mhz , TClock = 166Mhz > > > > DRAM CS[0] base 0x size 128MB > > DRAM Total size 128MB 32bit width > > Memory test pattern: 0x, 0x, Pass > > [51...@fff8] Flash: 512 kB > > Addresses 4M - 0M are saved for the U-Boot usage. > > Mem malloc Initialization (4M - 3M): Done > > > > CPU : ARM926 (Rev 0) > > Orion 1 streaming enabled > > > > And here it hangs. I wonder if there is any way hot to reset u-boot > settings. I mean some interrupt the POST by some magic key from serial > consoler or something. > > > > Do you think there is any possibility to debrick my device? > > > > Thanks, > > > > Mirek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] help with HP mv2120 debricking
On 2010/08/23 9:19 AM, Miroslav Petricek wrote: > Dear members, > > I was playing with my MH mv2120 NAS device and it happened to me that I > stored some u-boot values and the device now hangs on boot. I am stupid I > know. > > Last thing I did was that I've set: > > setenv enaPost Yes > > setenv enaCpuStream Yes > > and saved them: > > saveenv > It sounds like you may have to investigate a JTAG cable. Try opening it up, and seeing if you can find a 12 or 14 pin header. It *MAY* be a jtag header. Google for more information about JTAG and the Orion5x devices. Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.
Ben Warren wrote on 2010/08/23 09:08:17: > > Hi Detlev, > > On 8/13/2010 1:20 AM, Detlev Zundel wrote: > > Hi Jocke, > > > Instead of always performing an autoneg, check if the PHY > already has a link and if it matches one of the requested > modes. Initially only 100MbFD is optimized this way. > >>> Isn't it about time that we think about _not_ stopping the ethernet > >>> device after every transaction? > >> Hi Detlev > >> > >> UEC does this already, my patch was to address the initial delay > >> you get for the first transaction. Now my PHY based boards gets the link > >> up just as quick as Fixed PHY for the first transaction. > > Forgive me to not look into this any deeper, but do I understand you > > correctly that you do this by essentially no-oping the eth_halt() > > function? Isn't this then effectively violating what net.c expects the > > device to do? > > > > I was thinking that net.c itself should not do this continous start/stop > > thing as it has problems on many interfaces. On one ARM machine I've > > again seen problems with the MAC address programming because the > > eth_halt() resets the controller and so it forgets its address again. > > Also the USB-CDC example where the _whole interface_ on the host side is > > being torn down after each tftp transfer prompts me to think along this > > line. > > > > So in effect I guess my response was rather a ping to Ben, sorry for > > that ;) > > > Sorry for the delay on this. I'm all for changing the existing > behavior. It seems to me that the only time we would ever want to wind > an interface down is if we switch the active one (even then, I'm not > sure). My world view is limited, but I can't imagine that even changing > interfaces happens much in real world U-boot usage, that is the non-lab, > non-interactive use cases. What would you think about adding something > like ifup and ifdown commands so that users could explicitly start/stop > interfaces? Sure, bringing I/F's up and down needlessly isn't a good thing. However my patch doesn't change that behaviour. It only optimizes the need for a PHY AN the first time one performs a eth transaction. Jocke > > Cheers > >Detlev > > > regards, > Ben > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/13] x86: Make CONFIG_RELOC_FIXUP_WORKS generic for all x86 boards
Hello. Graeme Russ wrote: > Relocation is not board-specific fir the x86 architectrure, so s/fir/for/ > CONFIG_RELOC_FIXUP_WORKS can be defined globally in the common.h You mean config.h? > Signed-off-by: Graeme Russ [...] > diff --git a/arch/i386/include/asm/config.h b/arch/i386/include/asm/config.h > index 049c44e..1952de7 100644 > --- a/arch/i386/include/asm/config.h > +++ b/arch/i386/include/asm/config.h > @@ -21,4 +21,6 @@ > #ifndef _ASM_CONFIG_H_ > #define _ASM_CONFIG_H_ > > +#define CONFIG_RELOC_FIXUP_WORKS > + > #endif WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Hi again, On Friday 20 August 2010 03:35:57 pm Stefano Babic wrote: > > Just figured out one big mistake. I was debugging spi_flash.c, and had > > CONFIG_ENV_IS_IN_SPI_FLASH set. That means, first SPI access is done > > before malloc is available, and guess what? spi_setup_slave() uses malloc > > ;-) > > I have CONFIG_ENV_IS_IN_SPI_FLASH set, too. > I try to figure out how the functions are called, but I do not get the > same issue. I set with the debugger two breakpoints, one in > mem_malloc_init and the second one in spi_setup_slave. I see that > mem_alloc_init is hit first, and when spi_setup_slave is called, malloc > is available. I get a valid pointer for the private structure. It seems > there something in our config files that makes the things different. I > do not yet know why. Are you sure? In arch/arm/lib/board.c function start_armboot(), init_sequence is processed first, which contains env_init() before dram_init() and just after completing init_sequence, mem_malloc_init() is called. How can you have working malloc then? > > The C++ comments show original code, the line below is new. > > Understood, if malloc is not called, we have to use static or (better) > try to call mem_malloc_init() first I don't know if that is possible. I know that physically RAM is initialized before u-boot even starts (it runs from RAM), but logically, dram_init() is called _after_ env_init(), so I'm not sure if you are supposed to call mem_malloc_init() in env_init()... > > I see a one byte access followed by a 5 byte access, > > That is correct, you see the code in spi_flash.c. First the ID command > is sent (0x97), without reading nothing (that is, din is NULL). Then the > answer is read (dout is NULL), and the id buffer is 5 bytes long. I am slowly progressing... now the transfer succeeds, but I only read FF ;-) > > [...] > I am trying another approach. As the MX51 has 32 bytes FIFO, it makes > sense to use it and not send a single word, if we can. This must not > change the behavior for the MX31, because this processor has no FIFO and > a single word can be sent. > So I replaced completely spi_xfer, and the logic you put in spi_xfer I > have (more or less, I have not checked in details) moved inside the > spi_xcgh:single, that now has the meaning for me as single transation: > up to 1 word for i.MX31, up to 32 words (128 bytes) for i.MX51. > > Take into account that loading the kernel using a single word takes a > lot of time.. A good point. I was following the premise that u-boot drivers should be simple, but a little bit of speed for booting is surely not a bad idea ;-) > >> However, I am currently working on several issues for MX51. It should be > >> nice to know which are your plans to save both some time ;-) > > > > Well, I am in a bit of a hurry, and essentially what I need is to be able > > to access SPI-nor flash (spansion type) for environment and booting > > linux. MMC/SD access would be nice, but is not yet necessary. > > Ok, quite the same. I have a ST flash, but we get the same problems, I see. I am just now picking up where I left last week, so give me a few hours and I should have something working, I guess. > > I know. I thought to do it in two steps: Fix mxc_spi.c with a workaround > > for the pmic driver (which amounts to '#define spi_xfer spi_xfer_fsl' at > > the beginning of this driver basically) and fix the pmic driver later, > > since it is probably not trivial, and needs to be done carefully (you > > know, one can smoke a board by mistake :-) > > I know, this makes funny setting voltages via software I always say: "Electronics work on smoke. If the smoke escapes, it stops working" :-) Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
On Monday 23 August 2010 10:50:53 am David Jander wrote: > I am just now picking up where I left last week, so give me a few hours and > I should have something working, I guess. Ok, I guess I was pessimistic. There is a weird bug in mxc_spi.c: CPOL is negated! I just saw that in the mx51evk.h header file CONFIG_FSL_PMIC_MODE was set to low-active clock (CPOL=1), which is not supposed to work. But it did work, and on the scope clock-polarity was active-high. In spi_cfg(), I saw this line: if (!(mode & SPI_CPOL)) sclkpol = 1; AFAIK, this should be: if (mode & SPI_CPOL) sclkpol = 1; At least for the MX51. Can you confirm that this is different on the MX31? Now I get a correct flash id. Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AUTO: Richard Strange is out of the office. (returning 31/08/2010)
I am out of the office until 31/08/2010. Note: This is an automated response to your message "U-Boot Digest, Vol 27, Issue 25" sent on 21/08/2010 11:00:03. This is the only notification you will receive while this person is away. Any files attached to this e-mail will have been checked with virus detection software prior to transmission but you should carry out your own virus check before opening any attachment. Invensys Rail does not accept liability for any damage or loss which may be caused by software viruses. This e-mail and any associated files are intended solely for the individual or entity to whom they are addressed. Please do not copy it or use it for any purposes, or disclose its contents to any other person. Further, this e-mail and any associated files may be confidential and further may be legally privileged. This email is from the Invensys Rail Limited business unit of Invensys plc which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within Invensys Rail business group, please click here If you have received this e-mail in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Thank you for your co-operation. You may contact our Helpdesk on +44 (0)20 7821 3859 / 2105 or email inet.hqhelpd...@invensys.com This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote:
> Hi again,
>
Hi David,
> Are you sure? In arch/arm/lib/board.c function start_armboot(), init_sequence
> is processed first, which contains env_init() before dram_init() and just
> after completing init_sequence, mem_malloc_init() is called. How can you have
> working malloc then?
Well, I tried to investigate to see if I get the same issue, env_init is
called before mem_malloc_init, but it does nothing (in env_sf.c):
int env_init(void)
{
/* SPI flash isn't usable before relocation */
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = 1;
return 0;
}
And really I can see that mem_malloc_init() is called before
spi_setup_slave(). I guess there is a different configuration on our
targets, that makes the difference, but I do not know which one.
> I don't know if that is possible. I know that physically RAM is initialized
> before u-boot even starts (it runs from RAM), but logically, dram_init() is
> called _after_ env_init(), so I'm not sure if you are supposed to call
> mem_malloc_init() in env_init()...
Yes, but as I see env_init does not read from flash and does not call
spi_setup_flash(). This is done by env_relocate_spec(), but this
function is called later.
> I am slowly progressing... now the transfer succeeds, but I only read FF ;-)
I think I have a good status now. I can correctly read/write the whole
flash. I have still an issue with saveenv (the first time does not work,
and it works after I called "sf probe"...crazy, but probably depends on
my target, I am investigating), but I should find a fix for that too.
> A good point. I was following the premise that u-boot drivers should be
> simple, but a little bit of speed for booting is surely not a bad idea ;-)
Even using the whole FIFO I need about 8 Seconds to read the whole Flash
(4 MB). In normal case, this means I need 3 Seconds for a kernel.
> I am just now picking up where I left last week, so give me a few hours and I
>
> should have something working, I guess.
Ok. We can make a point later. As I said, things are not so bad on my
target.
> I always say: "Electronics work on smoke. If the smoke escapes, it stops
> working" :-)
;-)))
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote: > Ok, I guess I was pessimistic. There is a weird bug in mxc_spi.c: CPOL is > negated! > I just saw that in the mx51evk.h header file CONFIG_FSL_PMIC_MODE was set to > low-active clock (CPOL=1), which is not supposed to work. But it did work, > and > on the scope clock-polarity was active-high. Ok > > In spi_cfg(), I saw this line: > > if (!(mode & SPI_CPOL)) > sclkpol = 1; > > AFAIK, this should be: > > if (mode & SPI_CPOL) > sclkpol = 1; > > At least for the MX51. Can you confirm that this is different on the MX31? Agree. According to the MX51 Manual, the register must be set with: 0 Active high polarity (0 = Idle). 1 Active low polarity (1 = Idle). So we need to change both CONFIG_FSL_PMIC_MODE in config and in mxc_spi.c. Do you send a patch or do you prefer I will do this job ? I will add your signed-off-by if you agree. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: S5P: rename from CONFIG_S5PC1XX to CONFIG_S5P
Use the same configuration around S5P SoCs.
(s5pc100, s5pc110, s5pc210 and so on)
Signed-off-by: Minkyu Kang
---
common/serial.c |4 ++--
drivers/gpio/Makefile |2 +-
drivers/mtd/onenand/samsung.c |6 +++---
drivers/serial/Makefile |2 +-
include/configs/s5p_goni.h|2 +-
include/configs/smdkc100.h|2 +-
include/serial.h |2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/common/serial.c b/common/serial.c
index fceabfa..9e5759e 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -78,7 +78,7 @@ struct serial_device *__default_serial_console (void)
#else
#error "CONFIG_SERIAL? missing."
#endif
-#elif defined(CONFIG_S5PC1XX)
+#elif defined(CONFIG_S5P)
#if defined(CONFIG_SERIAL0)
return &s5p_serial0_device;
#elif defined(CONFIG_SERIAL1)
@@ -162,7 +162,7 @@ void serial_initialize (void)
serial_register(&s3c24xx_serial1_device);
serial_register(&s3c24xx_serial2_device);
#endif
-#if defined(CONFIG_S5PC1XX)
+#if defined(CONFIG_S5P)
serial_register(&s5p_serial0_device);
serial_register(&s5p_serial1_device);
serial_register(&s5p_serial2_device);
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 528ca2e..07d395d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -29,7 +29,7 @@ COBJS-$(CONFIG_AT91_GPIO) += at91_gpio.o
COBJS-$(CONFIG_KIRKWOOD_GPIO) += kw_gpio.o
COBJS-$(CONFIG_MX31_GPIO) += mx31_gpio.o
COBJS-$(CONFIG_PCA953X)+= pca953x.o
-COBJS-$(CONFIG_S5PC1XX)+= s5p_gpio.o
+COBJS-$(CONFIG_S5P)+= s5p_gpio.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index f2be687..20b4912 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -67,7 +67,7 @@ do {
\
#define MAP_01 (0x1 << 24)
#define MAP_10 (0x2 << 24)
#define MAP_11 (0x3 << 24)
-#elif defined(CONFIG_S5PC1XX)
+#elif defined(CONFIG_S5P)
#define MAP_00 (0x0 << 26)
#define MAP_01 (0x1 << 26)
#define MAP_10 (0x2 << 26)
@@ -121,7 +121,7 @@ static unsigned int s3c_mem_addr(int fba, int fpa, int fsa)
{
return (fba << 12) | (fpa << 6) | (fsa << 4);
}
-#elif defined(CONFIG_S5PC1XX)
+#elif defined(CONFIG_S5P)
static unsigned int s3c_mem_addr(int fba, int fpa, int fsa)
{
return (fba << 13) | (fpa << 7) | (fsa << 5);
@@ -614,7 +614,7 @@ void s3c_onenand_init(struct mtd_info *mtd)
#if defined(CONFIG_S3C64XX)
onenand->base = (void *)0x7010;
onenand->ahb_addr = (void *)0x2000;
-#elif defined(CONFIG_S5PC1XX)
+#elif defined(CONFIG_S5P)
onenand->base = (void *)0xE710;
onenand->ahb_addr = (void *)0xB000;
#endif
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index c731bfb..6d45a8e 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -36,7 +36,7 @@ COBJS-$(CONFIG_OPENCORES_YANU) += opencores_yanu.o
COBJS-$(CONFIG_SYS_NS16550) += ns16550.o
COBJS-$(CONFIG_DRIVER_S3C4510_UART) += s3c4510b_uart.o
COBJS-$(CONFIG_S3C64XX) += s3c64xx.o
-COBJS-$(CONFIG_S5PC1XX) += serial_s5p.o
+COBJS-$(CONFIG_S5P) += serial_s5p.o
COBJS-$(CONFIG_SYS_NS16550_SERIAL) += serial.o
COBJS-$(CONFIG_CLPS7111_SERIAL) += serial_clps7111.o
COBJS-$(CONFIG_IMX_SERIAL) += serial_imx.o
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index c8ea8fd..dc01ceb 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -30,7 +30,7 @@
/* High Level Configuration Options */
#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
#define CONFIG_SAMSUNG 1 /* in a SAMSUNG core */
-#define CONFIG_S5PC1XX 1 /* which is in a S5PC1XX Family */
+#define CONFIG_S5P 1 /* which is in a S5P Family */
#define CONFIG_S5PC110 1 /* which is in a S5PC110 */
#define CONFIG_MACH_GONI 1 /* working with Goni */
diff --git a/include/configs/smdkc100.h b/include/configs/smdkc100.h
index 76a47c4..595d174 100644
--- a/include/configs/smdkc100.h
+++ b/include/configs/smdkc100.h
@@ -34,7 +34,7 @@
*/
#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
#define CONFIG_SAMSUNG 1 /* in a SAMSUNG core */
-#define CONFIG_S5PC1XX 1 /* which is in a S5PC1XX Family */
+#define CONFIG_S5P 1 /* which is in a S5P Family */
#define CONFIG_S5PC100 1 /* which is in a S5PC100 */
#define CONFIG_SMDKC1001 /* working with SMDKC100 */
diff --git a/include/serial.h b/include/serial.h
index 6513d8e..9e4a226 100644
--- a/include/serial.h
+++ b/include/serial.h
@@ -52,7 +52,7 @@ extern str
Re: [U-Boot] help with HP mv2120 debricking
On Mon, 23 Aug 2010 09:19:05 +0200, "Miroslav Petricek" wrote: > And here it hangs. I wonder if there is any way hot to reset u-boot > settings. I mean some interrupt the POST by some magic key from serial > consoler or something. > > Do you think there is any possibility to debrick my device? If the U-boot configuration settings are stored at the top end of the flash memory, you might try to shorten the highest address line of the flash to the ground with a needle. Then U-boot will read a corrupted environment and fall back to its defaults. (try at own risk) -- Bas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Hi Stefano, On Monday 23 August 2010 12:37:16 pm Stefano Babic wrote: >[...] > > In spi_cfg(), I saw this line: > > > > if (!(mode & SPI_CPOL)) > > sclkpol = 1; > > > > AFAIK, this should be: > > > > if (mode & SPI_CPOL) > > sclkpol = 1; > > > > At least for the MX51. Can you confirm that this is different on the > > MX31? > > Agree. According to the MX51 Manual, the register must be set with: > 0 Active high polarity (0 = Idle). > 1 Active low polarity (1 = Idle). I just checked in the reference manual of the i.MX31, and there the meaning of this bit has the same polarity as on the i.MX51, so you'll need to fix this also at the end of the spi_setup_slave() function, in the #else path of the #ifdef CONFIG_MX51 directive. if (!(mode & SPI_CPOL)) ctrl_reg |= MXC_CSPICTRL_POL; should be: if (mode & SPI_CPOL) ctrl_reg |= MXC_CSPICTRL_POL; Would be nice if someone with a MX31 board could verify this. > So we need to change both CONFIG_FSL_PMIC_MODE in config and in > mxc_spi.c. Do you send a patch or do you prefer I will do this job ? I > will add your signed-off-by if you agree. I agree, and I guess you can better include it in your patch-set, otherwise I'd have to wait for your patches and then provide my own patch on top of that too complicated :-) I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later. Right now I have correct detection of the chip, but the environment is not saved and read back correctly. Still investigating... maybe some chip configuration prolem in the spansion driver? Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [TESTING] da8xx: fixup ARM relocation support
Hi Ben,
On Thu, Aug 19, 2010 at 18:32:48, Ben Gardiner wrote:
> Hi Sudhakar,
>
> Thank you for reviewing this patch.
>
> On Thu, Aug 19, 2010 at 2:25 AM, Sudhakar Rajashekhara
> wrote:
> > Ben Gardiner nanometrics.ca> writes:
> >
> > [...] snip
> >
> >> +
> >> +void dram_init_banksize (void)
> >> +{
> >> + gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> >> + gd->bd->bi_dram[0].size = gd->ram_size;
> >> +}
> >> +#endif
> >>
> >
> > dram_init() gets called from arch/arm/lib/board.c and initializes
> > gd->ram_size
> > but who is calling dram_init_banksize to initialize gd->bd->bi_dram[0].start
> > and gd->bd->bi_dram[0].size?
>
> As of commit a716b323f10d4f2bce6b4ae01f6d1544e5781ed8 on the
> arm-reloc-and-cache-support branch of
> git://git.denx.de/u-boot-testing.git , dram_init_banksize() is called
> from board_init_f which is executed just before relocation.
>
Though you have mentioned in your changelog, I just want to make sure
that gd->ramsize will be ZERO only when CONFIG_SYS_ARM_WITHOUT_RELOC is
defined. Is it right? Otherwise get_ram_size() needs to be called in both cases.
I was also about to comment about the line length in your patch but Heiko has
given the same comment. Please fix that and re-submit the patch. I can post
Acked-by/Reviewed-by on that version.
Regards,
Sudhakar
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
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
---
drivers/mtd/spi/spansion.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index d6c1a5f..14cd6d3 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -52,12 +52,14 @@
#define SPSN_ID_S25FL128P 0x2018
#define SPSN_EXT_ID_S25FL128P_256KB0x0300
#define SPSN_EXT_ID_S25FL128P_64KB 0x0301
+#define SPSN_EXT_ID_S25FL032P 0x4d00
#define SPANSION_SR_WIP(1 << 0)/* Write-in-Progress */
struct spansion_spi_flash_params {
u16 idcode1;
u16 idcode2;
+ u16 idmask2;
u16 page_size;
u16 pages_per_sector;
u16 nr_sectors;
@@ -79,6 +81,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL008A,
.idcode2 = 0,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 16,
@@ -87,6 +90,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL016A,
.idcode2 = 0,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 32,
@@ -95,6 +99,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL032A,
.idcode2 = 0,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 64,
@@ -103,6 +108,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL064A,
.idcode2 = 0,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 128,
@@ -111,6 +117,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL128P,
.idcode2 = SPSN_EXT_ID_S25FL128P_64KB,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 256,
@@ -119,11 +126,21 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL128P,
.idcode2 = SPSN_EXT_ID_S25FL128P_256KB,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 1024,
.nr_sectors = 64,
.name = "S25FL128P_256K",
},
+ {
+ .idcode1 = SPSN_ID_S25FL032A,
+ .idcode2 = SPSN_EXT_ID_S25FL032P,
+ .idmask2 = 0xff00,
+ .page_size = 256,
+ .pages_per_sector = 256,
+ .nr_sectors = 64,
+ .name = "S25FL032P",
+ },
};
static int spansion_wait_ready(struct spi_flash *flash, unsigned long
timeout)
@@ -317,7 +334,7 @@ struct spi_flash *spi_flash_probe_spansion(struct
spi_slave *spi, u8 *idcode)
for (i = 0; i < ARRAY_SIZE(spansion_spi_flash_table); i++) {
params = &spansion_spi_flash_table[i];
if (params->idcode1 == jedec) {
- if (params->idcode2 == ext_jedec)
+ if (params->idcode2 == (ext_jedec & params->idmask2))
break;
}
}
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] [TESTING] da8xx: fixup ARM relocation support
Split the existing dram_init for da8xx when ARM reloc is enabled, like the
changes to arch/arm/cpu/arm926ejs/orion5x/dram.c in
0f234d263b17ccf1b8fd776eb8c15b7cdb27a887 by Heiko Schocher .
Without these changes gd->ram_size is '0' which leads to incorrect relocation
when CONFIG_SYS_ARM_WITHOUT_RELOC is defined and the board does not boot.
We use get_ram_size to dynamically calculate the available RAM because it runs
on different board version with different ram, as suggested by Heiko in private
communication.
Tested on a da850evm with 128M of DDR2 installed; with both
CONFIG_SYS_ARM_WITHOUT_RELOC defined and undefined.
Signed-off-by: Ben Gardiner
CC: Sudhakar Rajashekhara
CC: Heiko Schocher
---
This patch is submitted for the arm-reloc-and-cache-support branch of
git://git.denx.de/u-boot-testing.git
V2:
* added Nori Sehkar to the to: list
* indicated for which branch of testing this patch is submitted.
V3:
* fix checkpatch errors
* directed to Sudhakar Rajashekhara instead of Nori Sehkar
---
board/davinci/common/misc.c | 17 +
include/configs/da850evm.h |1 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
index 25ca326..86a875e 100644
--- a/board/davinci/common/misc.c
+++ b/board/davinci/common/misc.c
@@ -33,6 +33,7 @@
DECLARE_GLOBAL_DATA_PTR;
+#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
int dram_init(void)
{
gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
@@ -40,6 +41,22 @@ int dram_init(void)
return(0);
}
+#else
+int dram_init(void)
+{
+ /* dram_init must store complete ramsize in gd->ram_size */
+ gd->ram_size = get_ram_size(
+ (volatile void *)CONFIG_SYS_SDRAM_BASE,
+ CONFIG_MAX_RAM_BANK_SIZE);
+ return 0;
+}
+
+void dram_init_banksize(void)
+{
+ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = gd->ram_size;
+}
+#endif
#ifdef CONFIG_DRIVER_TI_EMAC
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 016a21e..d02b196 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -47,6 +47,7 @@
#define CONFIG_SYS_GBL_DATA_SIZE 128 /* reserved for initial data */
#define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */
#define PHYS_SDRAM_1_SIZE (64 << 20) /* SDRAM size 64MB */
+#define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/
/* memtest start addr */
#define CONFIG_SYS_MEMTEST_START (PHYS_SDRAM_1 + 0x200)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Non-experimental U-Boot compilation
Dear all, I am using the AT91SAM9G20EK kit and want to port Linux on this. I am using the AT91SAM9260ek configuration as it seems the closest. The problem is after building the U-boot with the sources for this board, generating the .bin, loading and a power on reset (POR), there isn't a command prompt exposed (u-boot>). After POR, 1 1 2 1 1 2 continuosly prints on the hyperterminal. I read from AT91.com that this is the expected behavior for the demo version. What is rge procedure to get the prompt ? Are there any separate configuration settings? Please help as I am stuck. Thanks & regards Sandeep. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Compact Flash Support on Omap 3530
Hi there, I would like to know if u-boot has compact flash support on OMAP 3530, if it does, what version of u-boot should I get? Thanks, Tony smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add generic support for samsung s3c2440
This patch adds generic support for the Samsung s3c2440 processor.
Started from patch posted 2009-06-19 by
Kevin Morfitt. Then modified for changes in the code that have occurred
since.
Signed-off-by: Craig Nauman diagraph.com>
---
diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
b/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
index 15f53dd..d4abd24 100644
--- a/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
+++ b/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
@@ -82,6 +82,10 @@ struct s3c24x0_interrupt {
u32 SUBSRCPND;
u32 INTSUBMSK;
#endif
+#ifdef CONFIG_S3C2440
+ u32 SUBSRCPND;
+ u32 INTSUBMSK;
+#endif
};
@@ -91,10 +95,16 @@ struct s3c24x0_dma {
#ifdef CONFIG_S3C2410
u32 DISRCC;
#endif
+#ifdef CONFIG_S3C2440
+ u32 DISRCC;
+#endif
u32 DIDST;
#ifdef CONFIG_S3C2410
u32 DIDSTC;
#endif
+#ifdef CONFIG_S3C2440
+ u32 DIDSTC;
+#endif
u32 DCON;
u32 DSTAT;
u32 DCSRC;
@@ -106,6 +116,9 @@ struct s3c24x0_dma {
#ifdef CONFIG_S3C2410
u32 res[7];
#endif
+#ifdef CONFIG_S3C2440
+ u32 res[7];
+#endif
};
struct s3c24x0_dmas {
@@ -122,6 +135,9 @@ struct s3c24x0_clock_power {
u32 CLKCON;
u32 CLKSLOW;
u32 CLKDIVN;
+#if defined(CONFIG_S3C2440)
+ u32 CAMDIVN;
+#endif
};
@@ -147,9 +163,16 @@ struct s3c24x0_lcd {
u32 LCDINTMSK;
u32 LPCSEL;
#endif
+#ifdef CONFIG_S3C2440
+ u32 LCDINTPND;
+ u32 LCDSRCPND;
+ u32 LCDINTMSK;
+ u32 LPCSEL;
+#endif
};
+#ifdef CONFIG_S3C2410
/* NAND FLASH (see S3C2410 manual chapter 6) */
struct s3c2410_nand {
u32 NFCONF;
@@ -159,6 +182,23 @@ struct s3c2410_nand {
u32 NFSTAT;
u32 NFECC;
};
+#endif
+#ifdef CONFIG_S3C2440
+/* NAND FLASH (see S3C2440 manual chapter 6) */
+struct s3c2440_nand {
+ u32 NFCONF;
+ u32 NFCONT;
+ u32 NFCMD;
+ u32 NFADDR;
+ u32 NFDATA;
+ u32 NFECCD0;
+ u32 NFECCD1;
+ u32 NFECCD;
+ u32 NFSTAT;
+ u32 NFSTAT0;
+ u32 NFSTAT1;
+};
+#endif
/* UART (see manual chapter 11) */
@@ -447,6 +487,65 @@ struct s3c24x0_gpio {
u32 GSTATUS3;
u32 GSTATUS4;
#endif
+#if defined(CONFIG_S3C2440)
+ u32 GPACON;
+ u32 GPADAT;
+ u32 res1[2];
+ u32 GPBCON;
+ u32 GPBDAT;
+ u32 GPBUP;
+ u32 res2;
+ u32 GPCCON;
+ u32 GPCDAT;
+ u32 GPCUP;
+ u32 res3;
+ u32 GPDCON;
+ u32 GPDDAT;
+ u32 GPDUP;
+ u32 res4;
+ u32 GPECON;
+ u32 GPEDAT;
+ u32 GPEUP;
+ u32 res5;
+ u32 GPFCON;
+ u32 GPFDAT;
+ u32 GPFUP;
+ u32 res6;
+ u32 GPGCON;
+ u32 GPGDAT;
+ u32 GPGUP;
+ u32 res7;
+ u32 GPHCON;
+ u32 GPHDAT;
+ u32 GPHUP;
+ u32 res8;
+
+ u32 MISCCR;
+ u32 DCLKCON;
+ u32 EXTINT0;
+ u32 EXTINT1;
+ u32 EXTINT2;
+ u32 EINTFLT0;
+ u32 EINTFLT1;
+ u32 EINTFLT2;
+ u32 EINTFLT3;
+ u32 EINTMASK;
+ u32 EINTPEND;
+ u32 GSTATUS0;
+ u32 GSTATUS1;
+ u32 GSTATUS2;
+ u32 GSTATUS3;
+ u32 GSTATUS4;
+
+ u32 res9;
+ u32 DSC0;
+ u32 DSC1;
+ u32 MSLCON;
+ u32 GPJCON;
+ u32 GPJDAT;
+ u32 GPJUP;
+ u32 res10;
+#endif
};
diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c24x0_cpu.h
b/arch/arm/include/asm/arch-s3c24x0/s3c24x0_cpu.h
index c37d4a1..54184c4 100644
--- a/arch/arm/include/asm/arch-s3c24x0/s3c24x0_cpu.h
+++ b/arch/arm/include/asm/arch-s3c24x0/s3c24x0_cpu.h
@@ -22,6 +22,8 @@
#include
#elif defined CONFIG_S3C2410
#include
+#elif defined CONFIG_S3C2440
+ #include
#else
#error Please define the s3c24x0 cpu type
#endif
diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
b/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
new file mode 100644
index 000..7e4518e
--- /dev/null
+++ b/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
@@ -0,0 +1,163 @@
+/*
+ * (C) Copyright 2003
+ * David Müller ELSOFT AG Switzerland. d.muel...@elsoft.ch
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MER
Re: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.
Hi Jocke, On Monday, August 23, 2010, Joakim Tjernlund wrote: > Ben Warren wrote on 2010/08/23 09:08:17: >> >> Hi Detlev, >> >> On 8/13/2010 1:20 AM, Detlev Zundel wrote: >> > Hi Jocke, >> > >> Instead of always performing an autoneg, check if the PHY >> already has a link and if it matches one of the requested >> modes. Initially only 100MbFD is optimized this way. >> >>> Isn't it about time that we think about _not_ stopping the ethernet >> >>> device after every transaction? >> >> Hi Detlev >> >> >> >> UEC does this already, my patch was to address the initial delay >> >> you get for the first transaction. Now my PHY based boards gets the link >> >> up just as quick as Fixed PHY for the first transaction. >> > Forgive me to not look into this any deeper, but do I understand you >> > correctly that you do this by essentially no-oping the eth_halt() >> > function? Isn't this then effectively violating what net.c expects the >> > device to do? >> > >> > I was thinking that net.c itself should not do this continous start/stop >> > thing as it has problems on many interfaces. On one ARM machine I've >> > again seen problems with the MAC address programming because the >> > eth_halt() resets the controller and so it forgets its address again. >> > Also the USB-CDC example where the _whole interface_ on the host side is >> > being torn down after each tftp transfer prompts me to think along this >> > line. >> > >> > So in effect I guess my response was rather a ping to Ben, sorry for >> > that ;) >> > >> Sorry for the delay on this. I'm all for changing the existing >> behavior. It seems to me that the only time we would ever want to wind >> an interface down is if we switch the active one (even then, I'm not >> sure). My world view is limited, but I can't imagine that even changing >> interfaces happens much in real world U-boot usage, that is the non-lab, >> non-interactive use cases. What would you think about adding something >> like ifup and ifdown commands so that users could explicitly start/stop >> interfaces? > > Sure, bringing I/F's up and down needlessly isn't a good thing. However my > patch doesn't change that behaviour. It only optimizes the need for a PHY AN > the first time one performs a eth transaction. > I know. I guess my e-mail was more directed towards Detlev's musings. > Jocke Regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-experimental U-Boot compilation
Dear sandeep suresh, > Dear all, > I am using the AT91SAM9G20EK kit and want to port Linux on this. I am > using > the AT91SAM9260ek configuration as it seems the closest. The problem is after > building the U-boot with the sources for this board, generating the .bin, > loading and a power on reset (POR), there isn't a command prompt exposed > (u-boot>). After POR, 1 1 2 1 1 2 continuosly prints on the hyperterminal. I > read from AT91.com that this is the expected behavior for the demo version. > What > is rge procedure to get the prompt ? Are there any separate configuration > settings? > Please help as I am stuck. Try to define CONFIG_AT91SAM9G20EK in the board configuration ;) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Kernel copy from NOR to RAM
Hi guys, I'm using OMAP-L138 (ARM based) with NOR flash and I'll like to know in which file uboot copies kernel from NOR to RAM? Thanks Nicolas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.
Ben Warren wrote on 2010/08/23 16:12:07: > > Hi Jocke, > > On Monday, August 23, 2010, Joakim Tjernlund > wrote: > > Ben Warren wrote on 2010/08/23 09:08:17: > >> > >> Hi Detlev, > >> > >> On 8/13/2010 1:20 AM, Detlev Zundel wrote: > >> > Hi Jocke, > >> > > >> Instead of always performing an autoneg, check if the PHY > >> already has a link and if it matches one of the requested > >> modes. Initially only 100MbFD is optimized this way. > >> >>> Isn't it about time that we think about _not_ stopping the ethernet > >> >>> device after every transaction? > >> >> Hi Detlev > >> >> > >> >> UEC does this already, my patch was to address the initial delay > >> >> you get for the first transaction. Now my PHY based boards gets the link > >> >> up just as quick as Fixed PHY for the first transaction. > >> > Forgive me to not look into this any deeper, but do I understand you > >> > correctly that you do this by essentially no-oping the eth_halt() > >> > function? Isn't this then effectively violating what net.c expects the > >> > device to do? > >> > > >> > I was thinking that net.c itself should not do this continous start/stop > >> > thing as it has problems on many interfaces. On one ARM machine I've > >> > again seen problems with the MAC address programming because the > >> > eth_halt() resets the controller and so it forgets its address again. > >> > Also the USB-CDC example where the _whole interface_ on the host side is > >> > being torn down after each tftp transfer prompts me to think along this > >> > line. > >> > > >> > So in effect I guess my response was rather a ping to Ben, sorry for > >> > that ;) > >> > > >> Sorry for the delay on this. I'm all for changing the existing > >> behavior. It seems to me that the only time we would ever want to wind > >> an interface down is if we switch the active one (even then, I'm not > >> sure). My world view is limited, but I can't imagine that even changing > >> interfaces happens much in real world U-boot usage, that is the non-lab, > >> non-interactive use cases. What would you think about adding something > >> like ifup and ifdown commands so that users could explicitly start/stop > >> interfaces? > > > > Sure, bringing I/F's up and down needlessly isn't a good thing. However my > > patch doesn't change that behaviour. It only optimizes the need for a PHY AN > > the first time one performs a eth transaction. > > > > I know. I guess my e-mail was more directed towards Detlev's musings. Ah, great. You will apply this patch then? Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel copy from NOR to RAM
Le 23/08/2010 16:48, Nicolas Luna a écrit : > Hi guys, > > I'm using OMAP-L138 (ARM based) with NOR flash and I'll like to know in > which file uboot copies kernel from NOR to RAM? > > Thanks > > Nicolas Nicolas, Your question, as it is expressed, does not make much sense to me. What kind of 'file' are you talking about exactly? and what kernel to you mean? the Linux kernel? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
Hi Jef, >>> 10) The system I work on is a bareboard embedded system using U-boot >>> to start up. That is why we are trying to use S-record files for >>> uploading new programs, and not the more efficient FTP used in Linux. >> So you do have a network interface on your board? Heck, why don;t you >> use TFTP then??? > > I didn't say that. I was trying to say that our bareboard system > doesn't support Ethernet and does not have TCP/IP stack (like Linux). > If our system was a Linux system, we wouldn't be having this > conversation. We use tftp in U-Boot exactly because we also do not have a TCP/IP stack :) tftp needs only udp is thus "not too complex" to implement on bare ethernet. Maybe you can implement a server on your hardware? Just a thought... Cheers Detlev -- To summarize: It is a well known and lamented fact that those people who most want to rule people are, ipso facto, those least suited to do it. To summarize the summary: anyone who is capable of getting themselves made President should on no account be allowed to do the job. -- The Hitchhikers Guide To The Galaxy -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel copy from NOR to RAM
Ok I would like to improve the copy of linux kernel from NOR to RAM. I would like to replace the current copy and use EDMA instead. I traced the uboot code but I can't find in which file (uboot source code) the copy (from NOR to RAM) takes place. Thanks. Regards, Nicolas On Mon, Aug 23, 2010 at 11:04 AM, Albert ARIBAUD wrote: > Le 23/08/2010 16:48, Nicolas Luna a écrit : > > Hi guys, > > > > I'm using OMAP-L138 (ARM based) with NOR flash and I'll like to know in > > which file uboot copies kernel from NOR to RAM? > > > > Thanks > > > > Nicolas > > Nicolas, > > Your question, as it is expressed, does not make much sense to me. What > kind of 'file' are you talking about exactly? and what kernel to you > mean? the Linux kernel? > > Amicalement, > -- > Albert. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel copy from NOR to RAM
On Mon, Aug 23, 2010 at 10:14 AM, Nicolas Luna wrote: > Ok > > I would like to improve the copy of linux kernel from NOR to RAM. I would > like to replace the current copy and use EDMA instead. I traced the uboot > code but I can't find in which file (uboot source code) the copy (from NOR > to RAM) takes place. usually is done with the command cp -> copy command - as this is usually a memory to memory copy operation. > > Thanks. > > Regards, > Nicolas > > > > On Mon, Aug 23, 2010 at 11:04 AM, Albert ARIBAUD > wrote: > please stop top posting.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Start/stop of network devices (was: Re: [PATCH] UEC PHY: Speed up initial PHY neg.)
Hi Ben, [Jocke deleted from CC as this is not about the patch anymore] > Sorry for the delay on this. I'm all for changing the existing > behavior. It seems to me that the only time we would ever want to > wind an interface down is if we switch the active one (even then, I'm > not sure). My world view is limited, but I can't imagine that even > changing interfaces happens much in real world U-boot usage, that is > the non-lab, non-interactive use cases. What would you think about > adding something like ifup and ifdown commands so that users could > explicitly start/stop interfaces? Actually I was thinking of an automatic initialisiation once we do a network transfer. This would be more in line with the current command line interface. For this we would need a state variable per device and start the device if it is down. The "ifdown" _may_ be implemented as a command, but I think this should be done automatically once we boot a kernel. For USB we already have to do something like this as USB host controllers tend to DMA frame numbers into memory as long as they are running. This was an especially difficult problem to diagnose back then. From this lesson I think we should learn and call "stop" methods for every initialized device. What do you think? Once more this is going into the "device" model dicussion that we already thought about a while ago [1]. Maybe someday somebody finds some time and starts to work on it ;) Cheers Detlev [1] http://www.denx.de/wiki/view/U-Boot/OLSUbootBOF -- A foolish consistency is the hobgoblin of little minds. -- Ralph Waldo Emerson -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel copy from NOR to RAM
Well I mean at the boot time not in uboot prompt. Regards, Nicolas On Mon, Aug 23, 2010 at 11:16 AM, Nishanth Menon wrote: > On Mon, Aug 23, 2010 at 10:14 AM, Nicolas Luna wrote: > > Ok > > > > I would like to improve the copy of linux kernel from NOR to RAM. I would > > like to replace the current copy and use EDMA instead. I traced the uboot > > code but I can't find in which file (uboot source code) the copy (from > NOR > > to RAM) takes place. > > usually is done with the command cp -> copy command - as this is > usually a memory to memory copy operation. > > > > > Thanks. > > > > Regards, > > Nicolas > > > > > > > > On Mon, Aug 23, 2010 at 11:04 AM, Albert ARIBAUD >wrote: > > > please stop top posting.. > > Regards, > Nishanth Menon > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel copy from NOR to RAM
On 2010/08/23 5:19 PM, Nicolas Luna wrote: > Well I mean at the boot time not in uboot prompt. > > Regards, > Nicolas The cp command may be executed as part of the automatic boot script. Alternatively, the bootm command may perform the copy from NOR to RAM automatically as part of the boot sequence. Take a look at cmd_bootm.c. It may be platform dependent, though. What architecture are you working with? Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel copy from NOR to RAM
Hi Nicolas, > I'm using OMAP-L138 (ARM based) with NOR flash and I'll like to know in > which file uboot copies kernel from NOR to RAM? This will be the UBL which runs before U-Boot gets a chance to run. Just before Stefano Babic's work on the dm365 platform all davinci U-Boot ports configured CONFIG_SKIP_LOWLEVEL_INIT and thus relied on being loaded by some other entity into RAM to the link address specified during compilation. In such setups U-Boot is actually a payload in an AIS image. There is some documentation out there on the web ([1], esp. [2]) - if you have further questions, go ahead ;) Cheers Detlev [1] http://processors.wiki.ti.com/index.php/Category:OMAPL1 [2] http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138 -- Deutsches Grundgesetz Artikel 21 Absatz 1: Die Parteien wirken bei der politischen Willensbildung des Volkes mit. Ihre Gründung ist frei. Ihre innere Ordnung muß demokratischen Grundsätzen ent- sprechen. Sie müssen über die Herkunft und Verwendung ihrer Mittel sowie über ihr Vermögen öffentlich Rechenschaft geben. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel copy from NOR to RAM
In fact I'm using OMAPL138 platform and I think that it is not UBL that is copying kernel under that platform. I have been able to find the kernel image relocation in cmd_bootm.c but that is not the inital copy. I added printf/puts into the code to find where exactly it happens and my last print before the copy is displayed from file: hush.c function: static int run_pipe_real(struct pipe *pi) line: rcode = (cmdtp->cmd) (cmdtp, flag,child->argc-i,&child->argv[i]); This is a function pointer and I just don't know where it jumps and it's what I trying to find. Any idea? Thanks Nicolas On Mon, Aug 23, 2010 at 11:28 AM, Detlev Zundel wrote: > Hi Nicolas, > > > I'm using OMAP-L138 (ARM based) with NOR flash and I'll like to know in > > which file uboot copies kernel from NOR to RAM? > > This will be the UBL which runs before U-Boot gets a chance to run. > Just before Stefano Babic's work on the dm365 platform all davinci > U-Boot ports configured CONFIG_SKIP_LOWLEVEL_INIT and thus relied on > being loaded by some other entity into RAM to the link address specified > during compilation. In such setups U-Boot is actually a payload in an > AIS image. > > There is some documentation out there on the web ([1], esp. [2]) - if > you have further questions, go ahead ;) > > Cheers > Detlev > > [1] http://processors.wiki.ti.com/index.php/Category:OMAPL1 > [2] > http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138 > > -- > Deutsches Grundgesetz Artikel 21 Absatz 1: > Die Parteien wirken bei der politischen Willensbildung des Volkes mit. Ihre > Gründung ist frei. Ihre innere Ordnung muß demokratischen Grundsätzen ent- > sprechen. Sie müssen über die Herkunft und Verwendung ihrer Mittel sowie > über > ihr Vermögen öffentlich Rechenschaft geben. > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote: > Hi Stefano, > Hi David, > I just checked in the reference manual of the i.MX31, and there the meaning > of > this bit has the same polarity as on the i.MX51, so you'll need to fix this > also at the end of the spi_setup_slave() function, in the #else path of the > #ifdef CONFIG_MX51 directive. > > if (!(mode & SPI_CPOL)) > ctrl_reg |= MXC_CSPICTRL_POL; > > should be: > > if (mode & SPI_CPOL) > ctrl_reg |= MXC_CSPICTRL_POL; > > Would be nice if someone with a MX31 board could verify this. I can test myself on a qong board - I hope someone else can test on other MX.31 boards. > I agree, and I guess you can better include it in your patch-set, otherwise > I'd have to wait for your patches and then provide my own patch on top of > that too complicated :-) I will do it - I think I could send in a short time the whole patchset for review :-). > > I am also adding support for S25FL032P chips to the spansion driver. Will > post > a patch later. I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC). > Right now I have correct detection of the chip, but the environment is not > saved and read back correctly. Still investigating... maybe some chip > configuration prolem in the spansion driver? Probably. I have got some issues with the ST that do not depend from the modifications in SPI driver. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
Hi Albert, I've been trying to figure out why I could not erase sectors in my flash greater than SA70. It turned out that this was on a megabyte boundary, and in fact, was exactly half way through my flash. The flash is a 64Mbit part, i.e. 8MB, and I could only access the first 4MB of it, even though the ORION5X_SZ_BOOTROM parameter was set to (8 * 1024 * 1024). By "access" I mean that even md.b commands simply returned "00", and flash erase commands returned immediately without actually doing anything. Doubling the value for ORION5X_SZ_BOOTROM allowed me to access the additional sectors, but that makes me wonder what the reason for it is. I know that the flash chip is wired up strangely, but would that also affect the window mappings? If that is the case, I just need to document WHY the parameter is doubled, but if not, it would be good to understand the real reason for the change. Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
On Monday, August 23, 2010 09:12:16 David Jander wrote:
> + {
> + .idcode1 = SPSN_ID_S25FL032A,
> + .idcode2 = SPSN_EXT_ID_S25FL032P,
> + .idmask2 = 0xff00,
what does the idcode2 look like such that you need a mask ?
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
On 2010-08-23, Detlev Zundel wrote: > Hi Jef, > 10) The system I work on is a bareboard embedded system using U-boot to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux. >>> So you do have a network interface on your board? Heck, why don;t you >>> use TFTP then??? >> >> I didn't say that. I was trying to say that our bareboard system >> doesn't support Ethernet and does not have TCP/IP stack (like Linux). >> If our system was a Linux system, we wouldn't be having this >> conversation. > > We use tftp in U-Boot exactly because we also do not have a TCP/IP > stack :) > > tftp needs only udp is thus "not too complex" to implement on bare > ethernet. Doesn't "our bareboard system doesn't support Ethernet" preclude the use of Ethernet (UDP or otherwise)? > Maybe you can implement a server on your hardware? What sort of server? -- Grant Edwards grant.b.edwardsYow! If I pull this SWITCH at I'll be RITA HAYWORTH!! gmail.comOr a SCIENTOLOGIST! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
On Monday 23 August 2010 17:55:44 Stefano Babic wrote: > > I am also adding support for S25FL032P chips to the spansion driver. Will > > post a patch later. > > I have seen. However, it should be better if you send the patch also to > the maintainer for the MTD subsystem (Stefan Roese, I set his address in > CC). Small correction: I'm not the custodian of the "MTD subsystem", but of the CFI flash driver (amongst others). And I have never really taken care of the SPI flash patches before (and never used one of those drivers before). IIRC, then Mike (added to Cc) has the most insight here. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel copy from NOR to RAM
Nicolas Luna wrote: > In fact I'm using OMAPL138 platform and I think that it is not UBL that is > copying kernel under that platform. The UBL set up the processor in a fixed way, and have no knowledge about the kernel. It loads u-boot, and the kernel is copied inside u-boot. > I added printf/puts into the code to find where exactly it happens and my > last print before the copy is displayed from > > file: hush.c > function: static int run_pipe_real(struct pipe *pi) > line: rcode = (cmdtp->cmd) (cmdtp, flag,child->argc-i,&child->argv[i]); > > This is a function pointer and I just don't know where it jumps and it's > what I trying to find. Of course, you find only the point where the shell starts the function executing a command. However, as already reported, you have to take a look to the "cp" command, whose function do_mem_cp is in common/cmd_mem.c. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
Hi Grant, > On 2010-08-23, Detlev Zundel wrote: >> Hi Jef, >> > 10) The system I work on is a bareboard embedded system using U-boot > to start up. That is why we are trying to use S-record files for > uploading new programs, and not the more efficient FTP used in Linux. So you do have a network interface on your board? Heck, why don;t you use TFTP then??? >>> >>> I didn't say that. I was trying to say that our bareboard system >>> doesn't support Ethernet and does not have TCP/IP stack (like Linux). >>> If our system was a Linux system, we wouldn't be having this >>> conversation. >> >> We use tftp in U-Boot exactly because we also do not have a TCP/IP >> stack :) >> >> tftp needs only udp is thus "not too complex" to implement on bare >> ethernet. > > Doesn't "our bareboard system doesn't support Ethernet" preclude the > use of Ethernet (UDP or otherwise)? Yes, sorry. I was mislead by the "and not the more efficient FTP used in Linux". The pure mentioning of FTP which does not make any sense without a network port made me read the following statement not close enough. >> Maybe you can implement a server on your hardware? > > What sort of server? It would be a tftp server of course but that is out of the question without a network hardware. Cheers Detlev -- So maybe I lost track of my point. But if I left a mark, C-x C-x should be all I need. -- David Kastrup, emacs-devel.gnu.org <87hbj37v4x@lola.goethe.zz> -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Hi Stefan, > On Monday 23 August 2010 17:55:44 Stefano Babic wrote: >> > I am also adding support for S25FL032P chips to the spansion driver. Will >> > post a patch later. >> >> I have seen. However, it should be better if you send the patch also to >> the maintainer for the MTD subsystem (Stefan Roese, I set his address in >> CC). > > Small correction: > > I'm not the custodian of the "MTD subsystem", but of the CFI flash driver > (amongst others). And I have never really taken care of the SPI flash patches > before (and never used one of those drivers before). IIRC, then Mike (added > to > Cc) has the most insight here. In fact I cannot see that you extended the CC list. Wanna have another go? ;) Cheers Detlev -- Paul Simon sang "Fifty Ways to Lose Your Lover", because quite frankly, "A Million Ways to Tell a Developer He Is a D*ckhead" doesn't scan nearly as well. But I'm sure he thought about it. -- linux/Documentation/ManagementStyle -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
On 2010-08-23, Detlev Zundel wrote: I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation. >>> >>> We use tftp in U-Boot exactly because we also do not have a TCP/IP >>> stack :) >>> >>> tftp needs only udp is thus "not too complex" to implement on bare >>> ethernet. >> >> Doesn't "our bareboard system doesn't support Ethernet" preclude the >> use of Ethernet (UDP or otherwise)? > > Yes, sorry. I was mislead by the "and not the more efficient FTP > used in Linux". The pure mentioning of FTP which does not make any > sense without a network port made me read the following statement not > close enough. I thought maybe I had lost track of who posted what. :) >>> Maybe you can implement a server on your hardware? >> >> What sort of server? > > It would be a tftp server of course but that is out of the question > without a network hardware. Now that you mention it, I have implemented a tftp server for U-Boot. We needed a way to recover "bricked" units in the field, and there's simply no way we could require out customers to install a tftp server on their machines. Making U-Boot the tftp server and our "restore" program the client solved several problems. I also find have U-Boot be the server is a lot more convenient for development use. [It also U-Boot commands to be sent via the tftp protocol.] I thought about submitting patches (it's pretty much a stand-alone addition except for 3-4 lines in net.[ch]). But it was made abundantly clear that tftp server code for U-Boot would never be considered -- I was scolded for even asking about it. -- Grant Edwards grant.b.edwardsYow! Life is a POPULARITY at CONTEST! I'm REFRESHINGLY gmail.comCANDID!! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
Hi Grant, On 8/23/2010 2:10 PM, Grant Edwards wrote: > On 2010-08-23, Detlev Zundel wrote: > > I didn't say that. I was trying to say that our bareboard system > doesn't support Ethernet and does not have TCP/IP stack (like Linux). > If our system was a Linux system, we wouldn't be having this > conversation. We use tftp in U-Boot exactly because we also do not have a TCP/IP stack :) tftp needs only udp is thus "not too complex" to implement on bare ethernet. >>> Doesn't "our bareboard system doesn't support Ethernet" preclude the >>> use of Ethernet (UDP or otherwise)? >> Yes, sorry. I was mislead by the "and not the more efficient FTP >> used in Linux". The pure mentioning of FTP which does not make any >> sense without a network port made me read the following statement not >> close enough. > I thought maybe I had lost track of who posted what. :) > Maybe you can implement a server on your hardware? >>> What sort of server? >> It would be a tftp server of course but that is out of the question >> without a network hardware. > Now that you mention it, I have implemented a tftp server for U-Boot. > > We needed a way to recover "bricked" units in the field, and there's > simply no way we could require out customers to install a tftp server > on their machines. Making U-Boot the tftp server and our "restore" > program the client solved several problems. I also find have U-Boot > be the server is a lot more convenient for development use. [It also > U-Boot commands to be sent via the tftp protocol.] > > I thought about submitting patches (it's pretty much a stand-alone > addition except for 3-4 lines in net.[ch]). But it was made > abundantly clear that tftp server code for U-Boot would never be > considered -- I was scolded for even asking about it. > I can see how this could be useful. Please reconsider and we'll try to keep the scolding to a minimum :) regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
Hi Grant, Maybe you can implement a server on your hardware? >>> >>> What sort of server? >> >> It would be a tftp server of course but that is out of the question >> without a network hardware. > > Now that you mention it, I have implemented a tftp server for U-Boot. Nice job! > We needed a way to recover "bricked" units in the field, and there's > simply no way we could require out customers to install a tftp server > on their machines. Making U-Boot the tftp server and our "restore" > program the client solved several problems. I also find have U-Boot > be the server is a lot more convenient for development use. Yes, I can see that this is very nice in some scenarios. > [It also U-Boot commands to be sent via the tftp protocol.] Now this is actually very intersting. I never considered something like this. Of course it has the possibility to do "bad things" from the outside, but the netconsole code has the same problem. But unlike netconsole the "client side" is fully standard. Indeed very interesting. Can you pass back results, i.e. the output of an md command? > I thought about submitting patches (it's pretty much a stand-alone > addition except for 3-4 lines in net.[ch]). But it was made > abundantly clear that tftp server code for U-Boot would never be > considered -- I was scolded for even asking about it. Maybe I can talk you into posting the patches? It would be an awful waste of effort not to at least post your (working!) implementation here and thus (at least) get it archieved. In Free Software written code always has the potential to change minds ;) Cheers Detlev -- ... what [Microsoft] Exchange provides is *like* email, but it is *not* email. Once you start trying to use it for real email, you find it's broken by design in a large number of ways. It makes no sense for [a company] to require that you use Exchange for Internet email, because that's not what Exchange does. -- David Woodhouse <1281348164.12908.47.ca...@localhost> -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
On Monday, August 23, 2010 09:12:16 David Jander wrote:
> @@ -79,6 +81,7 @@ static const struct spansion_spi_flash_params
> spansion_spi_flash_table[] = {
also, your e-mailer appears to have mangled this patch. please use `git send-
email` so that it doesnt screw things up.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fixing spi erase for S25FL128P_256K
On Tuesday, August 10, 2010 09:02:09 Marc-André Hébert wrote: > @@ -262,7 +262,6 @@ int spansion_erase(struct spi_flash *flash, u32 > offset, size_t len) > return -1; seems your mailer too is broken. please use `git send-email` when posting patches so they dont get screwed up. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
On 2010-08-23, Ben Warren wrote: > On 8/23/2010 2:10 PM, Grant Edwards wrote: >> Now that you mention it, I have implemented a tftp server for U-Boot. >> >> We needed a way to recover "bricked" units in the field, and there's >> simply no way we could require out customers to install a tftp server >> on their machines. Making U-Boot the tftp server and our "restore" >> program the client solved several problems. I also find have U-Boot >> be the server is a lot more convenient for development use. [It also >> U-Boot commands to be sent via the tftp protocol.] >> >> I thought about submitting patches (it's pretty much a stand-alone >> addition except for 3-4 lines in net.[ch]). But it was made >> abundantly clear that tftp server code for U-Boot would never be >> considered -- I was scolded for even asking about it. > > I can see how this could be useful. Please reconsider and we'll try to > keep the scolding to a minimum :) OK. I need clean up the sources a little. There's still some debug code that doesn't really need to be there any longer. There's one bit of ugliness on which I could use some advice. The tftp server knows how to write to NAND flash, and uses a RAM buffer the same size as an erase block. Right now I just arbitrarily use a 128K block of RAM starting 256K below text base. That works for my board, but I'm sure isn't the "right" way to do things. What is the right way for a command to allocate a large, temporary buffer? Increasing the stack/heap size to accomodate a 128K buffer doesn't seem like the right thing to do, nor does statically allocating it. It also only supports a single nand device. In the meantime, here's the document describing how it works: The U-Boot tftp server is run as a normal U-Boot command and uses special filenames to specify source/destination of data and actions to be performed: Destination (used with "put" or "write" requests) r...@12345678 Writes receive data into ram starting at address 12345678 (decimal). n...@0x2c0 Writes receive data into nand flash starting at address 0x2C0. Nand will be erased before writing. Writes to nand flash must start on 128K page boundaries and write sizes will be rounded up to the next 4K page boundary. c...@ubootcmdstring Discards any data sent. After transfer completes, interprets 'ubootcmdstring' as if it were entered at the U-Boot command prompt. Command output will appear on normal console device. Source (used with "get" or "read" request) n...@0x12345678:4321 Sends 4321 bytes of data from nand flash starting at address 0x12345678. Reads from nand must start on a 512 byte boundary. r...@0x12345678:0x4321 Sends 0x4321 bytes of data from ram starting at address 0x12345678. c...@ubootcmdstring Interprets 'ubootcmdstring' as if it were entered at the U-Boot command prompt and then sends the output of that command as tftp data. If this is used for commands like "boot", the transfer will hang because executing the command will terminate U-Boot. Such commands should be executed using a "write" request rather than a "read" request. Either Destination or source (either "put" or "get") The following "filenames" return 0 bytes of data when read from and will discard any data when written to. After the 0 byte "data transfer" completes, they invoke the actions described. nander...@0x80:0x2 Erases 0x2 bytes of nand flash starting at address 0x80. Erase operation must start on 128K page boundary and erase size must be an integral multiple of 128K. g...@0x12345678 Jump to address 0x12345678. reset@ Reset the board. exitok@ Exit tftp server with "success" status. exitfail@ Exit tftp server with "fail" status. When invoking the U-Boot tftp server, an idle-timeout (in seconds) may be specified. If no tftp requests are received within that time, the server will terminate (with a "success" status). If two arguments are specified, the first is the idle-timeout at startup, and the second is the idle-timeout that is used after the first tftp request has been handled. Timeout values of 0 mean 'run until somebody hits Ctrl-C on the console'. When the tftpserver terminates due to an idle timeout after an initial command has been received, it exits with a "failure" status. -- Grant Edwards grant.b.edwardsYow! This is a NO-FRILLS at flight --
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
On Monday, August 23, 2010 17:03:24 Detlev Zundel wrote: > Hi Stefan, > > On Monday 23 August 2010 17:55:44 Stefano Babic wrote: > >> > I am also adding support for S25FL032P chips to the spansion driver. > >> > Will post a patch later. > >> > >> I have seen. However, it should be better if you send the patch also to > >> the maintainer for the MTD subsystem (Stefan Roese, I set his address in > >> CC). > > > > Small correction: > > > > I'm not the custodian of the "MTD subsystem", but of the CFI flash driver > > (amongst others). And I have never really taken care of the SPI flash > > patches before (and never used one of those drivers before). IIRC, then > > Mike (added to Cc) has the most insight here. > > In fact I cannot see that you extended the CC list. Wanna have another > go? ;) i did since he added me to the cc ... but as David said, he posted a sep patch, so i'll stick to that thread. i generally delete threads about parts i dont care about (like whatever a "MX3" and "MX5" are). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
On 2010-08-23, Detlev Zundel wrote: > Hi Grant, > > Maybe you can implement a server on your hardware? What sort of server? >>> >>> It would be a tftp server of course but that is out of the question >>> without a network hardware. >> >> Now that you mention it, I have implemented a tftp server for U-Boot. > > Nice job! > >> We needed a way to recover "bricked" units in the field, and there's >> simply no way we could require out customers to install a tftp server >> on their machines. Making U-Boot the tftp server and our "restore" >> program the client solved several problems. I also find have U-Boot >> be the server is a lot more convenient for development use. > > Yes, I can see that this is very nice in some scenarios. > >> [It also U-Boot commands to be sent via the tftp protocol.] > > Now this is actually very intersting. I never considered something like > this. Of course it has the possibility to do "bad things" from the > outside, but the netconsole code has the same problem. True. In order to be useful for de-brikcing, the tftp server must let "outsiders" write stuff into flash. Once you've decided to allow that... > But unlike netconsole the "client side" is fully standard. Exactly. > Indeed very interesting. Can you pass back results, i.e. the output > of an md command? Yes: $ atftp -g -l foo.txt -r 'c...@md.b 0 0x100' 10.0.0.99 $ cat foo.txt : 0d 00 00 ea 05 00 00 ea 05 00 00 ea 05 00 00 ea 0010: 05 00 00 ea ac 11 00 00 05 00 00 ea 05 00 00 ea 0020: fe ff ff ea fe ff ff ea fe ff ff ea fe ff ff ea 0030: fe ff ff ea fe ff ff ea fe ff ff ea d4 d0 9f e5 0040: d4 00 9f e5 00 10 90 e5 01 20 a0 e3 02 10 11 e0. .. 0050: 09 00 00 1a c4 00 9f e5 01 19 a0 e3 01 20 a0 e3. .. 0060: 02 10 81 e1 00 10 80 e5 ac 00 9f e5 00 10 90 e5 0070: 01 20 a0 e3 02 10 11 e0 fb ff ff 0a a0 00 9f e5. .. 0080: 03 10 a0 e3 00 20 90 e5 01 20 02 e0 00 10 a0 e3. ... .. 0090: 02 00 51 e1 0e 00 00 1a 01 10 a0 e3 00 20 a0 e3..Q.. .. 00a0: 02 10 81 e1 00 10 80 e5 6c 00 9f e5 00 10 90 e5l... 00b0: 08 20 a0 e3 02 10 11 e0 fb ff ff 0a 64 20 9f e5. ..d .. 00c0: 1a 00 92 e8 04 00 53 e1 04 20 91 34 04 20 83 34..S.. .4. .4 00d0: fb ff ff 3a 34 20 8f e2 18 00 92 e8 00 20 a0 e3...:4 ... .. 00e0: 04 00 53 e1 04 20 83 34 fc ff ff 3a 38 40 9f e5..S.. .4...:8...@.. 00f0: 0f e0 a0 e1 14 ff 2f e1 30 10 9f e5 0f e0 a0 e1../.0... >> I thought about submitting patches (it's pretty much a stand-alone >> addition except for 3-4 lines in net.[ch]). But it was made >> abundantly clear that tftp server code for U-Boot would never be >> considered -- I was scolded for even asking about it. > > Maybe I can talk you into posting the patches? It would be an awful > waste of effort not to at least post your (working!) implementation > here and thus (at least) get it archieved. In Free Software written > code always has the potential to change minds ;) OK, I'll clean it up and post it. -- Grant Edwards grant.b.edwardsYow! People humiliating at a salami! gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add support for Winbond W25Q64 SPI flash (updated)
ive imported this into my sf branch so it doesnt get lost. cheers ! -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
On Monday, August 23, 2010 17:35:03 Mike Frysinger wrote:
> On Monday, August 23, 2010 09:12:16 David Jander wrote:
> > @@ -79,6 +81,7 @@ static const struct spansion_spi_flash_params
> > spansion_spi_flash_table[] = {
>
> also, your e-mailer appears to have mangled this patch. please use `git
> send- email` so that it doesnt screw things up.
although i fixed up the commit and merged it manually. but you only get one
pass, so next time i'll wait for a proper resend :P.
this is in my sf branch so it wont get lost
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fixing spi erase for S25FL128P_256K
On Monday, August 23, 2010 17:37:44 Mike Frysinger wrote: > On Tuesday, August 10, 2010 09:02:09 Marc-André Hébert wrote: > > @@ -262,7 +262,6 @@ int spansion_erase(struct spi_flash *flash, u32 > > offset, size_t len) > > > > return -1; > > seems your mailer too is broken. please use `git send-email` when posting > patches so they dont get screwed up. although i fixed up the commit and merged it manually. but you only get one pass, so next time i'll wait for a proper resend :P. this is in my sf branch so it wont get lost -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SPI: cmd_spi.c: add option to specify bus and mode
were you going to send an updated version ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB
Add support for 4bpp bitmaps, but only when writing to a GDF_32BIT_X888RGB.
Signed-off-by: Timur Tabi
---
I only added support for GDF_32BIT_X888RGB because that's the only mode
that my video device supports in U-Boot. I wouldn't be able to test any
other mode, and it took a lot of trial and error to get this one mode working
correctly.
drivers/video/cfb_console.c | 26 +-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index fae5417..1d52819 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1114,8 +1114,32 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
}
#endif
- /* We handle only 8bpp or 24 bpp bitmap */
+ /* We handle only 4, 8, or 24 bpp bitmaps */
switch (le16_to_cpu (bmp->header.bit_count)) {
+ case 4:
+ padded_line -= width / 2;
+ ycount = height;
+
+ switch (VIDEO_DATA_FORMAT) {
+ case GDF_32BIT_X888RGB:
+ while (ycount--) {
+ WATCHDOG_RESET ();
+ /* Don't assume that 'width' is an even number
*/
+ for (xcount = 0; xcount < width; xcount++) {
+ if (xcount & 1) {
+ cte = bmp->color_table[*bmap &
0xF];
+ bmap++;
+ } else
+ cte = bmp->color_table[*bmap >>
4];
+ FILL_32BIT_X888RGB(cte.red, cte.green,
cte.blue);
+ }
+ bmap += padded_line;
+ fb -= (VIDEO_VISIBLE_COLS + width) *
VIDEO_PIXEL_SIZE;
+ }
+ break;
+ }
+ break;
+
case 8:
padded_line -= width;
if (VIDEO_DATA_FORMAT == GDF__8BIT_INDEX) {
--
1.7.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
Le 24/08/2010 07:21, Chris Moore a écrit : > Hi Rogan, > > Le 23/08/2010 18:06, Rogan Dawes a écrit : >> Doubling the value for ORION5X_SZ_BOOTROM allowed me to access the >> additional sectors, but that makes me wonder what the reason for it is. >> >> I know that the flash chip is wired up strangely, but would that also >> affect the window mappings? If that is the case, I just need to document >> WHY the parameter is doubled, but if not, it would be good to understand >> the real reason for the change. >> > > I am (very rashly) stabbing in the dark here because I don't know much > about U-Boot and I haven't followed your previous posts (hence this > off-list reply). > > However if your device size is half the bus size (like an 8-bit device > on a 16-bit bus) it would seem logical to have to double the window size. > > Cheers, > Chris Hi Chris, BTW. :) Rogan, Seeing as ORION5X_SZ_BOOTROM is only used as a byte address limit for window mapping, and device vs bus size govern the maximum amout in a single bus access but do not govern its addressing, I don't think device width is involved here. I'd rather ask whether this could be a window alignment issue, i.e is the flash base address 8 MB aligned? Seems like it, because IIRC its base is FF80, which is 8MB-aligned. Can you still try the original u-boot? Does it allow reading the full 8 MB? If so, can you do a 'md.l 0xF102 40' in it, and then in your own u-boot with ORION5X_SZ_BOOTROM set to 8MB then 16MB? These are the window mapping registers, and it will allow us to know what the CPU really thinks boot ROM looks like. Also dump F101046C, that's the boot device bus configuration, again in both U-boots. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
On Monday 23 August 2010 06:31:26 pm Mike Frysinger wrote:
> On Monday, August 23, 2010 09:12:16 David Jander wrote:
> > + {
> > + .idcode1 = SPSN_ID_S25FL032A,
> > + .idcode2 = SPSN_EXT_ID_S25FL032P,
> > + .idmask2 = 0xff00,
>
> what does the idcode2 look like such that you need a mask ?
> -mike
According to the datasheet the RDID command (0x9f) returns the following
bytes:
byte 0: Manufacturer ID = 0x01
byte 1,2: Device ID = 0x02, 0x15 (same as S25FL032A)
byte 3: Extended ID = 0x4d
byte 4,5,6: Spansion reserved (do not use).
byte 4 is read as 0x00 on my part, but due to the above explaination, I cannot
say for sure it is always the same, so I had to implement a mask to check for
it.
Best regards,
--
David Jander
Protonic Holland.
tel.: +31 (0) 229 212928
fax.: +31 (0) 229 210930
Factorij 36 / 1689 AL Zwaag
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
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
---
drivers/mtd/spi/spansion.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index d6c1a5f..14cd6d3 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -52,12 +52,14 @@
#define SPSN_ID_S25FL128P 0x2018
#define SPSN_EXT_ID_S25FL128P_256KB0x0300
#define SPSN_EXT_ID_S25FL128P_64KB 0x0301
+#define SPSN_EXT_ID_S25FL032P 0x4d00
#define SPANSION_SR_WIP(1 << 0)/* Write-in-Progress */
struct spansion_spi_flash_params {
u16 idcode1;
u16 idcode2;
+ u16 idmask2;
u16 page_size;
u16 pages_per_sector;
u16 nr_sectors;
@@ -79,6 +81,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL008A,
.idcode2 = 0,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 16,
@@ -87,6 +90,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL016A,
.idcode2 = 0,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 32,
@@ -95,6 +99,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL032A,
.idcode2 = 0,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 64,
@@ -103,6 +108,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL064A,
.idcode2 = 0,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 128,
@@ -111,6 +117,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL128P,
.idcode2 = SPSN_EXT_ID_S25FL128P_64KB,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 256,
.nr_sectors = 256,
@@ -119,11 +126,21 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
{
.idcode1 = SPSN_ID_S25FL128P,
.idcode2 = SPSN_EXT_ID_S25FL128P_256KB,
+ .idmask2 = 0x,
.page_size = 256,
.pages_per_sector = 1024,
.nr_sectors = 64,
.name = "S25FL128P_256K",
},
+ {
+ .idcode1 = SPSN_ID_S25FL032A,
+ .idcode2 = SPSN_EXT_ID_S25FL032P,
+ .idmask2 = 0xff00,
+ .page_size = 256,
+ .pages_per_sector = 256,
+ .nr_sectors = 64,
+ .name = "S25FL032P",
+ },
};
static int spansion_wait_ready(struct spi_flash *flash, unsigned long timeout)
@@ -317,7 +334,7 @@ struct spi_flash *spi_flash_probe_spansion(struct spi_slave
*spi, u8 *idcode)
for (i = 0; i < ARRAY_SIZE(spansion_spi_flash_table); i++) {
params = &spansion_spi_flash_table[i];
if (params->idcode1 == jedec) {
- if (params->idcode2 == ext_jedec)
+ if (params->idcode2 == (ext_jedec & params->idmask2))
break;
}
}
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
