Hello
I'm porting U-Boot on ARM926EJ-S based board, which has one NOR flash
(specified in the subject line). For debug purpose I compiled U-Boot
to run from RAM via JTAG; therefore the configuration of flash is as
follows:
#define CFG_FLASH_BASE 0x2C00
#define CFG_MAX_FLASH_BANKS 1
Dear Mike Frysinger,
In message <200812112130.02918.vap...@gentoo.org> you wrote:
>
> > > -#ifndef CONFIG_SF_DEFAULT_SPEED
> > > -# define CONFIG_SF_DEFAULT_SPEED 100
> > > +#ifndef CONFIG_SF_DEFAULT_HZ
> > > +# define CONFIG_SF_DEFAULT_HZ100
> >
> > I consider "FREQ" (and even "SPEED)
On Friday 12 December 2008, Wolfgang Denk wrote:
> > btw, does nand_init() fall into the same category ? should i convert
> > that to a "nand init" step ?
>
> Yes, it does.
>
> I'm not sure here, though. Many people seem to find at least the NAND
> flash size output useful.
Yes. And please don't
Hello
2008/12/12 Roman Mashak :
[skip]
> So I believe 'default_environment[]' has correct "baudrate"
> environment set and on startup it will be picked up by
> 'init_baudrate()' from $(UBOOT)/lib_arm/board.c
Problem is fixed, it was due to a bug in the function configuring
clock frequency, which
>Hmm, I have 170kB free - minus 128kB (assuming you're using a 128kB flash
>rather than my 256kB) leaves 42kB, so you are using ~36kB more than my 86kB
>Looks like you may have some places to carve out some code.
>Good luck, glad to be of service
I changed the space to 256KB, and build OK. Than
On Thursday 11 December 2008 18:59:46 Wolfgang Denk wrote:
> In message Mike Frysinger you wrote:
> > The term "hz" is used everywhere else when talking about the frequency of
> > the SPI bus, so have the sf command use it as well to stay consistent.
> > It even presents itself as "hz" when showin
Commit af1c2b84 added a generic phy support, with an ID of zero
and a 32 bit mask; meaning that it will match on any PHY ID.
The problem is that there is a test that checked if a matching
PHY was found, and if not, it printed the non-matching ID.
But since there will always be a match (on the gene
Hello
2008/12/12 Roman Mashak :
> Certainly.
>
> * CPU is arm926ejs based processor with standard peripherals (UART,
> I2C, timers etc.)
> * our custom board
> * U-Boot-1.3.4
Forgot to mention the serial settings in my board's configuration file:
#define CONFIG_BAUDRATE 115200
#define CF
On Dec 11, 2008, at 5:51 PM, Mike Frysinger wrote:
> Rather than have the board code initialize SATA automatically during
> boot,
> make the user manually run "sata init". This brings the SATA
> subsystem in
> line with common U-Boot policy.
>
> Along these lines, the "is_sata_supported()" h
Mike Frysinger wrote:
> On Thursday 11 December 2008 18:53:00 Wolfgang Denk wrote:
>> And if they do, the code should fail gracefully, i. e. print some
>> friendly error message like that S-ATA is not available.
>
> in this case, i think that's up to the controller. i.e. the controller
> doesnt
On Dec 11, 2008, at 6:01 PM, Wolfgang Denk wrote:
> Dear Kumar,
>
> In message <29E3D6BF-AA38-40C3-
> ac21-87dcbbb82...@kernel.crashing.org> you wrote:
>>
>>
>>> I agree with Kumare - having to run "sata init" manually is
>>> annoying.
>
> Sorry for the bodus 'e' here.
>
>>> We should auto-run
Dear Kumar,
In message you wrote:
>
> On Dec 4, 2008, at 10:58 AM, Kumar Gala wrote:
>
> > We have an issue with inbound windows overlapping outbound windows.
> > This is fine, but it does mean that pci_hose_{bus_to_phys,phys_to_bus}
> > can return the wrong thing.
> >
> > I was wondering if th
Dear Kumar,
In message <29e3d6bf-aa38-40c3-ac21-87dcbbb82...@kernel.crashing.org> you wrote:
>
>
> > I agree with Kumare - having to run "sata init" manually is annoying.
Sorry for the bodus 'e' here.
> > We should auto-run it upon the first "sata" command if it hasn't been
> > called before (
Dear Mike Frysinger,
In message <1229034488-26048-1-git-send-email-vap...@gentoo.org> you wrote:
> The term "hz" is used everywhere else when talking about the frequency of
> the SPI bus, so have the sf command use it as well to stay consistent. It
> even presents itself as "hz" when showing user
On Thursday 11 December 2008 18:53:00 Wolfgang Denk wrote:
> In message Mike Frysinger you wrote:
> > > Also, in the code you removed we do a runtime check on 8536 to see if
> > > SATA is even available. That check is still valid.
> >
> > why ? if the hardware doesnt support it, then the user sho
Dear Mike Frysinger,
In message <200812111624.20543.vap...@gentoo.org> you wrote:
>
> it made sense when the init step was automatic. but you're telling me users
And we still want to have it automatic, just deferred.
> of your board are incapable of looking at it and going "hmm, this has a SAT
> "Wolfgang" == Wolfgang Denk writes:
Wolfgang> Dear Peter Korsgaard,
Wolfgang> In message <1228922656-27689-1-git-send-email-jac...@sunsite.dk> you
wrote:
>> Support bootdelay=0 in abortboot for the CONFIG_AUTOBOOT_KEYED case
>> similar to the CONFIG_ZERO_BOOTDELAY_CHECK support for the
Dear Mike Frysinger,
In message <200812111607.10866.vap...@gentoo.org> you wrote:
>
> having init_sata() be automatic though would prevent hotplugging ... but
> maybe
> people dont care about that ...
No - if you also allow to run "sata init" manually. the thing is that
it just should be done
Dear Mike Frysinger,
In message <200812111556.23044.vap...@gentoo.org> you wrote:
>
> > Also, in the code you removed we do a runtime check on 8536 to see if
> > SATA is even available. That check is still valid.
>
> why ? if the hardware doesnt support it, then the user shouldnt be
> attemptin
Rather than have the board code initialize SATA automatically during boot,
make the user manually run "sata init". This brings the SATA subsystem in
line with common U-Boot policy.
Along these lines, the "is_sata_supported()" hook is no longer needed, so
scrub it from the tree.
Signed-off-by: Mi
Dear Kumar Gala,
In message <3b24dcfa-1309-4b92-a4ae-d9943d332...@kernel.crashing.org> you wrote:
>
> > and ...), so it isnt a big deal imo. i asked if Wolfgang wanted it
> > automated
> > and he preferred making the user do it themselves.
>
> This seems backwards to me..
ACK here.
> 'sata
Dear Mike Frysinger,
In message <200812111503.54148.vap...@gentoo.org> you wrote:
>
> it's already standard behavior with most mass storage things (like mmc and sf
> and ...), so it isnt a big deal imo. i asked if Wolfgang wanted it automated
> and he preferred making the user do it themselves.
On Thursday 11 December 2008 18:22:06 Wolfgang Denk wrote:
> In message Mike Frysinger you wrote:
> > btw, does nand_init() fall into the same category ? should i convert
> > that to a "nand init" step ?
>
> Yes, it does.
>
> I'm not sure here, though. Many people seem to find at least the NAND
>
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message <1228948562-12728-1-git-send-email-plagn...@jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
>
> diff --git a/Makefile b/Makefile
> index 2ac8141..0e31697 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2586,6 +2586,7 @@
Dear Mike Frysinger,
In message <1228941641-27682-1-git-send-email-vap...@gentoo.org> you wrote:
> Some images can be quite large, so add an option to compress the image data
> with gzip in the U-Boot image. Then at runtime, the board can decompress it
> with the normal zlib functions.
...
> +
The stmicro_wait_ready() func tries to show the actual opcode that was sent
to the device, but instead it displays the array pointer. Fix it to pull
out the opcode from the start of the array.
Signed-off-by: Mike Frysinger
---
drivers/mtd/spi/stmicro.c |2 +-
1 files changed, 1 insertions(+
Dear Peter Korsgaard,
In message <1228922656-27689-1-git-send-email-jac...@sunsite.dk> you wrote:
> Support bootdelay=0 in abortboot for the CONFIG_AUTOBOOT_KEYED case
> similar to the CONFIG_ZERO_BOOTDELAY_CHECK support for the
> !CONFIG_AUTOBOOT_KEYED case.
Ummm... how do you enter the "passwor
Dear Mike,
In message <200812090056.25498.vap...@gentoo.org> you wrote:
>
> > -: ${JOBS:=}
> > +# Determine number of CPU cores if no default was set
> > +: ${BUILD_NCPUS:"`getconf _NPROCESSORS_ONLN`"}
> > +
> > +if [ "$BUILD_NCPUS" -gt 1 ]
>
> no point in quoting here ... if it isnt numeric, then
On Dec 4, 2008, at 10:58 AM, Kumar Gala wrote:
> We have an issue with inbound windows overlapping outbound windows.
> This is fine, but it does mean that pci_hose_{bus_to_phys,phys_to_bus}
> can return the wrong thing.
>
> I was wondering if there was any issue if PCI_REGION_MEMORY was set
> for
On Dec 11, 2008, at 5:18 PM, Wolfgang Denk wrote:
> Dear Mike Frysinger,
>
> In message <1228991549-11486-1-git-send-email-vap...@gentoo.org> you
> wrote:
>> Rather than have the board code initialize SATA automatically
>> during boot,
>> make the user manually run "sata init". This brings t
Dear Mike Frysinger,
In message <200812110747.19343.vap...@gentoo.org> you wrote:
>
> btw, does nand_init() fall into the same category ? should i convert that to
> a "nand init" step ?
Yes, it does.
I'm not sure here, though. Many people seem to find at least the NAND
flash size output usefu
Dear Mike Frysinger,
In message <1228991549-11486-1-git-send-email-vap...@gentoo.org> you wrote:
> Rather than have the board code initialize SATA automatically during boot,
> make the user manually run "sata init". This brings the SATA subsystem in
> line with common U-Boot policy.
I agree with
Hello
2008/12/11 Jean-Christophe PLAGNIOL-VILLARD :
[skip]
> First could you give us few information as which CPU, Target and U-Boot
> version do you work on?
Certainly.
* CPU is arm926ejs based processor with standard peripherals (UART,
I2C, timers etc.)
* our custom board
* U-Boot-1.3.4
--
R
The term "hz" is used everywhere else when talking about the frequency of
the SPI bus, so have the sf command use it as well to stay consistent. It
even presents itself as "hz" when showing user help.
Signed-off-by: Mike Frysinger
---
common/cmd_sf.c | 10 +-
1 files changed, 5 insert
On Thursday 11 December 2008 16:36:12 Scott Wood wrote:
> Mike Frysinger wrote:
> > it made sense when the init step was automatic. but you're telling me
> > users of your board are incapable of looking at it and going "hmm, this
> > has a SATA disk" ? it isnt like disks are tiny and they have to
Mike Frysinger wrote:
> it made sense when the init step was automatic. but you're telling me users
> of your board are incapable of looking at it and going "hmm, this has a SATA
> disk" ? it isnt like disks are tiny and they have to scan a board for some
> obscure IC. disks are friggin huge.
On Thursday 11 December 2008 15:52:25 Mike Frysinger wrote:
> the `sf probe` command does:
> static int do_spi_flash_probe(...)
> {
> ...
> new = spi_flash_probe(bus, cs, speed, mode);
> if (flash)
> spi_flash_free(flash);
> flash = new;
> ...
> }
oh, i
On Thursday 11 December 2008 16:16:12 Scott Wood wrote:
> Mike Frysinger wrote:
> > On Thursday 11 December 2008 16:01:33 Scott Wood wrote:
> >> Mike Frysinger wrote:
> >>> why ? if the hardware doesnt support it, then the user shouldnt be
> >>> attempting to use it. if they do, that's their faul
On Dec 11, 2008, at 2:29 PM, Paul Gortmaker wrote:
> Commit af1c2b84 added a generic phy support, with an ID of zero
> and a 32 bit mask; meaning that it will match on any PHY ID.
>
> The problem is that there is a test that checked if a matching
> PHY was found, and if not, it printed the non-ma
Mike Frysinger wrote:
> On Thursday 11 December 2008 16:01:33 Scott Wood wrote:
>> Mike Frysinger wrote:
>>> why ? if the hardware doesnt support it, then the user shouldnt be
>>> attempting to use it. if they do, that's their fault for doing something
>>> stupid.
>> There's no need to be unneces
On Wednesday 09 July 2008 18:37:06 Wolfgang Denk wrote:
> In message Jason McMullan wrote:
> > Add support for the Winbond W25X16/32/64 series of
> > SPI Flash devices.
>
> Signed-off-by line is missing.
>
> > --- /dev/null
> > +++ b/drivers/mtd/spi/winbond.c
> > @@ -0,0 +1,331 @@
> > +/*
> > + * C
On Thursday 11 December 2008 16:01:33 Scott Wood wrote:
> Mike Frysinger wrote:
> > On Thursday 11 December 2008 15:51:32 Kumar Gala wrote:
> >> 'sata init' isn't safe. It seems like you should only be able to call
> >> it once. However I think we can keep issuing it and cause bad things
> >> to
Mike Frysinger wrote:
> On Thursday 11 December 2008 15:51:32 Kumar Gala wrote:
>> 'sata init' isn't safe. It seems like you should only be able to call
>> it once. However I think we can keep issuing it and cause bad things
>> to happen.
>
> i dont think so. the SATA driver should be doing the
in your original drivers/mtd/spi/spi_flash.c commit, you had this:
#ifdef CONFIG_SPI_FLASH_SPANSION
case 0x01:
flash = spi_flash_probe_spansion(spi, idcode);
break;
#endif
does that mean you have a spansion driver sitting around but it just wasnt
merged ? if i dont have to wr
On Thursday 11 December 2008 15:51:32 Kumar Gala wrote:
> On Dec 11, 2008, at 2:03 PM, Mike Frysinger wrote:
> > On Thursday 11 December 2008 11:17:56 Kumar Gala wrote:
> >> On Dec 11, 2008, at 4:32 AM, Mike Frysinger wrote:
> >>> Rather than have the board code initialize SATA automatically during
On Fri, Dec 05, 2008 at 02:13:51PM +0300, Maxim Artamonov wrote:
> +#ifdef CONFIG_NAND_SPL
> +/* somewhat macro to reduce bin size for CONFIG_NAND_SPL*/
> +.macro FILLREGS begreg, val, count, step
Why not use this macro always?
> @@ -32,6 +35,15 @@
> #include
> .globl _start
> _start: bre
Dear Peter,
In message you wrote:
>
> >> ~$ git clone git://git.denx.de/u-boot.git
> > ...
> >> ~/uboot$ git rebase v1.3.3
> >
> > What exactly do you expect this command to do?
>
> I have some patches that apply against v1.3.3 and work fine. Moving
> them to v2008.10 did not work so far, so I
the `sf probe` command does:
static int do_spi_flash_probe(...)
{
...
new = spi_flash_probe(bus, cs, speed, mode);
if (flash)
spi_flash_free(flash);
flash = new;
...
}
looks good ... if the user ran `sf probe` once already, then we need to fr
On Dec 11, 2008, at 2:03 PM, Mike Frysinger wrote:
> On Thursday 11 December 2008 11:17:56 Kumar Gala wrote:
>> On Dec 11, 2008, at 4:32 AM, Mike Frysinger wrote:
>>> Rather than have the board code initialize SATA automatically during
>>> boot,
>>> make the user manually run "sata init". This b
The values given for the PHY address were wrong, so the code
read no valid PHY ID, and fell through to the generic PHY
support, which would work on 1000M but would not auto negotiate
down to 100M or 10M.
Signed-off-by: Paul Gortmaker
---
include/configs/sbc8548.h |4 ++--
1 files changed, 2
Hi Andy,
Would you please merge these three sbc8548 patches via the mpc85xx tree?
This fixes an incorrect PHY address issue that was masked by the tsec
driver inadvertently doing an "if (0) {...}" Rather than put in bogus
PHY address for the eTSEC3 and eTSEC4, I just purged them from the
board
Lets make things a bit more user friendly. It isn't 1985 anymore.
Signed-off-by: Paul Gortmaker
---
include/configs/sbc8548.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/sbc8548.h b/include/configs/sbc8548.h
index b27b282..e93b861 100644
--- a/includ
These interfaces don't have usable connectors on the board, so don't
bother enumerating or configuring them.
Signed-off-by: Paul Gortmaker
---
include/configs/sbc8548.h | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/include/configs/sbc8548.h b/include/con
Hello Michael,
2008/12/11 Michael Trimarchi :
> From e2f57c5cee96b506d9580cf93d4bd2a0de1c3e3d Mon Sep 17 00:00:00 2001
> From: michael
> Date: Thu, 11 Dec 2008 13:43:55 +0100
> Subject: [PATCH] This patch add varius fix to the ehci.
> - fix ehci_readl, ehci_writel
> - introduce new define in eh
On Thursday 11 December 2008 11:17:56 Kumar Gala wrote:
> On Dec 11, 2008, at 4:32 AM, Mike Frysinger wrote:
> > Rather than have the board code initialize SATA automatically during
> > boot,
> > make the user manually run "sata init". This brings the SATA
> > subsystem in
> > line with common U-B
On Thursday 11 December 2008 11:18:36 Kumar Gala wrote:
> On Dec 11, 2008, at 4:32 AM, Mike Frysinger wrote:
> > diff --git a/board/freescale/mpc8536ds/mpc8536ds.c b/board/freescale/
> > mpc8536ds/mpc8536ds.c
> > index 2b17612..ada8020 100644
> > --- a/board/freescale/mpc8536ds/mpc8536ds.c
> > +++
On Sat, Dec 06, 2008 at 02:40:55AM -0500, Mike Frysinger wrote:
> Rather than putting the function prototype for board_nand_init() in the one
> place where it gets called, put it into nand.h so that every place that also
> defines it gets the prototype. Otherwise, errors can go silently unnoticed
On Thu, Dec 11, 2008 at 07:47:18AM -0500, Mike Frysinger wrote:
> btw, does nand_init() fall into the same category ?
Hmm, in general I'd say yes, but that raises the issue with certain
drivers (such as fsl elbc) of how to communicate the ECC layout being
used to the kernel. Currently (or at lea
This patch adds bad block skipping for nboot command by using
nand_read_skip_bad function.
The initial read size had to be increased because there seems to be an
issue with
nand_read_skip_bad and read sizes less than erasesize when the first block
needs to be skipped.
Since our kernel images are
Hi Curtis,
Please copy the U-boot mailing list on all correspondence.
Curtis Wald wrote:
>
> Hi,
>
> As you’re listed as the custodian for the U-Boot Network Library I had
> a question:
>
> Looking in net/net.c NetLoop() starting at line 322:
>
> eth_halt();
>
> #ifdef CONFIG_NET_MULTI
>
> eth_s
On Thu, 11 Dec 2008 17:01:57 +0100, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>> ~$ git clone git://git.denx.de/u-boot.git
> ...
>> ~/uboot$ git rebase v1.3.3
>
> What exactly do you expect this command to do?
I have some patches that apply against v1.3.3 and work fine. Moving
them to v2008.10 did
On Wed, Dec 10, 2008 at 09:05:00AM +0900, Kyungmin Park wrote:
> >> diff --git a/cpu/arm1136/start.S b/cpu/arm1136/start.S
> >> index e622338..132cc4a 100644
> >> --- a/cpu/arm1136/start.S
> >> +++ b/cpu/arm1136/start.S
> >> @@ -33,23 +33,7 @@
> >> .globl _start
> >> _start: breset
> >> #ifd
On Dec 11, 2008, at 4:32 AM, Mike Frysinger wrote:
> diff --git a/board/freescale/mpc8536ds/mpc8536ds.c b/board/freescale/
> mpc8536ds/mpc8536ds.c
> index 2b17612..ada8020 100644
> --- a/board/freescale/mpc8536ds/mpc8536ds.c
> +++ b/board/freescale/mpc8536ds/mpc8536ds.c
> @@ -582,17 +582,6 @@ ge
On Dec 11, 2008, at 4:32 AM, Mike Frysinger wrote:
> Rather than have the board code initialize SATA automatically during
> boot,
> make the user manually run "sata init". This brings the SATA
> subsystem in
> line with common U-Boot policy.
>
> Along these lines, the "is_sata_supported()" h
Dear "Peter Vollmer",
In message <[EMAIL PROTECTED]> you wrote:
> Hi all,
>
> I just tried to do a git bisect in my clone of the u-boot git repo
> to trace some commits in the past, but I noticed there
> is a problem doing a rebase in an unchanged fresh
> clone of git.denx.de/u-boot.git. Thats wh
Signed-off-by: Shinya Kuribayashi <[EMAIL PROTECTED]>
---
Hi Jean,
in the commit 6d0f6bcf (rename CFG_ macros to CONFIG_SYS), this README
file was added into ${TOPDIR} dir. Was this intended?
Thanks,
Shinya
README.nios_CONFIG_SYS_NIOS_CPU | 140 ---
do
Hi Wolfgang,
>> This patch adds diagnosis functions for the buzzer, UARTs and digital
>
> Such hardware test code should be implemented as part of the POST
> system, i. e. please create a post/board/inka4x0/ directory for it,
> and make it part of the POST.
But these tests cannot be part of any P
Hi Wolfgang,
> Dear [EMAIL PROTECTED],
>
> In message <[EMAIL PROTECTED]> you wrote:
>> From: Andreas Pfefferle <[EMAIL PROTECTED]>
>>
>> This patch adds the board specific communication routines needed
>> by the external 4543 RTC.
>
> No, that's broken by design. An RTC is not board-dependent,
The idea and most of the code is from the following thread
http://lists.denx.de/pipermail/u-boot/2008-July/036604.html
The idea is that existing bad blocks can reduce the usable size in the
partition.
User defines partition table only once but bad blocks are different on
different chips.
Add commands which operate on partitions. They are:
1. onenand partwrite : Write image / data to partition skipping bad blocks.
2. onenand partread: Read image / data from partition skipping bad blocks.
3. onenand lastslcpart : Configure Flex-OneNAND boundary to
Currently, environment variables partition can only be one block.
However, this block can be bad. With this patch, user can give many blocks to
environment variables partition. This is done by changing
CONFIG_ENV_SIZE or CONFIG_ENV_SIZE_FLEX macro.
The variables are written to first block in the p
Hi,
The following patches improve partitioning and bad block support
for OneNAND / Flex-OneNAND devices.
The idea is to be able to use U-Boot as a utility to write images
to flash.
Any comments are much appreciated.
Thanks,
Rohit
___
U-Boot mailing
Jerry Van Baren wrote:
> Wolfgang Denk wrote:
>> Dear Richard Retanubun,
>>
>> In message <[EMAIL PROTECTED]> you wrote:
>>> I am trying to limit the amount of memory needed to load and boot a linux
>>> kernel (2.6.26)
>>> to do this I loaded my fdt at address 0x20_ and uImage at 0x_30_
>
Add command for changing Flex-OneNAND SLC / MLC boundary.
Signed-off-by: Rohit Hagargundgi <[EMAIL PROTECTED]>
---
common/cmd_onenand.c | 65 +++---
1 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/common/cmd_onenand.c b/common/cmd_onen
Add sanity check for the partitions.
Some special cases handled by the check are:
- A partition can span across erase regions.
- A region can have odd number of blocks.
Signed-off-by: Rohit Hagargundgi <[EMAIL PROTECTED]>
---
common/cmd_jffs2.c | 65 +
Define and use CONFIG_ENV_ADDR_FLEX and CONFIG_ENV_SIZE_FLEX
for storing environment variables.
Signed-off-by: Rohit Hagargundgi <[EMAIL PROTECTED]>
---
common/env_onenand.c | 10 ++
include/configs/apollon.h |2 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git
This patch adds support for MLC OneNAND and Flex-OneNAND devices.
The differences are like this.
OneNAND features:
1. 2KB page
2. 64 pages per block.
3. Upto 4 writes to a page allowed.
4. 1 ECC register
5. OOB read and OOB write commands present.
MLC OneN
Hi,
This is a repost of support for Flex-OneNAND devices.
Changes since v1(last post):
- Rebased to u-boot-nand-flash.
- Updated review comments from MTD list.
- Support eraseregions with odd number of blocks.
- JFFS2 commands support for Flex-OneNAND.
I have split the patches so that it is more
Hi all,
I just tried to do a git bisect in my clone of the u-boot git repo
to trace some commits in the past, but I noticed there
is a problem doing a rebase in an unchanged fresh
clone of git.denx.de/u-boot.git. Thats what I did:
~$ git --version
git version 1.5.6.5
~$ git clone git://git.denx.
> > The earlier I was using u-boot ver 1.1.6 and my nand driver
> was working fine.
> > With migration to latest u-boot I am always getting bad
> block errors
> > (Skipping bad block 0x)
> could you be a few more specific?
>
Hi J
Just now it is working
I set chip_delay=1000 in board specifi
On 02:07 Thu 11 Dec , Prafulla Wadaskar wrote:
> Hi Jean,
> First of all sorry for late feedback
> Thanks for your help.
> I tried to apply the above patch but it has lot of diff,
> On the other thread I have migrated to latest u-boot version and the problem
> got resolved :-)
> I think your p
Signed-off-by:Frederic Rodo <[EMAIL PROTECTED]>
---
drivers/nand/nand_imx.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/nand/nand_imx.c b/drivers/nand/nand_imx.c
index 3bf67de..fbef9b7 100644
--- a/drivers/nand/nand_imx.c
+++ b/drivers/nand/nand_imx.c
@@ -3
Signed-off-by:Frederic Rodo <[EMAIL PROTECTED]>
---
drivers/nand/nand_imx.c | 94
+--
include/asm-arm/arch-imx/imx-nand.h |2 +-
2 files changed, 79 insertions(+), 17 deletions(-)
diff --git a/drivers/nand/nand_imx.c b/drivers/nand/nand_imx.c
inde
>From e2f57c5cee96b506d9580cf93d4bd2a0de1c3e3d Mon Sep 17 00:00:00 2001
From: michael <[EMAIL PROTECTED]>
Date: Thu, 11 Dec 2008 13:43:55 +0100
Subject: [PATCH] This patch add varius fix to the ehci.
- fix ehci_readl, ehci_writel
- introduce new define in ehci.h
- introduce the handshake functio
btw, does nand_init() fall into the same category ? should i convert that to
a "nand init" step ?
-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/listi
Dear Mike,
In message <[EMAIL PROTECTED]> you wrote:
>
> On Thursday 11 December 2008 05:22:49 Wolfgang Denk wrote:
> > erase 4000 +1
>
> when was this notation added ? i'm not familiar with it ... but until
> recently, i was living with u-boot-1.1.6 ...
Then you have that code:
...
Wolfgang Denk wrote:
> Dear Richard Retanubun,
>
> In message <[EMAIL PROTECTED]> you wrote:
>> I am trying to limit the amount of memory needed to load and boot a linux
>> kernel (2.6.26)
>> to do this I loaded my fdt at address 0x20_ and uImage at 0x_30_
FWIIW, your FDT blob should be
Mike Frysinger wrote:
> If both CONFIG_ENV_SECT_SIZE and CONFIG_ENV_SIZE are defined, and the sect
> size is larger than the env size, then it means the env is embedded in a
> block. So we have to save/restore the part of the sector which is not the
> environment. Previously, saving the environme
On 20:37 Thu 11 Dec , Roman Mashak wrote:
> Hello
>
> 2008/12/11 Roman Mashak <[EMAIL PROTECTED]>:
> > Briefly about the memory map: before remap NOR flash is at 0x0 and
> > SDRAM 0x1000, after remap -- SDRAM is mapped at 0x0. I've built
> > a U-Boot image linked to 0x0, as I want to loa
Hello
2008/12/11 Roman Mashak <[EMAIL PROTECTED]>:
> Briefly about the memory map: before remap NOR flash is at 0x0 and
> SDRAM 0x1000, after remap -- SDRAM is mapped at 0x0. I've built
> a U-Boot image linked to 0x0, as I want to load it in RAM, so I linked
> it to 0x0.
>
> Loading this ima
If both CONFIG_ENV_SECT_SIZE and CONFIG_ENV_SIZE are defined, and the sect
size is larger than the env size, then it means the env is embedded in a
block. So we have to save/restore the part of the sector which is not the
environment. Previously, saving the environment in SPI flash in this
setup
This patch adds the CONFIG_FLASH_NOT_MEM_MAPPED define which can be
used on boards where the NOR FLASH is not memory-mapped and
special accessor functions are needed to access the NOR FLASH.
This affects the memory commands (cmd_mem.c) and the environment
(env_flash.c).
Boards using CONFIG_FLASH_N
Kumar Gala schrieb:
>
> On Dec 9, 2008, at 12:01 PM, Andre Schwarz wrote:
>
>> Jon Loeliger schrieb:
>>> On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
>>>
Kim,
I'd like to change my DDR setup code since it looks like my computed
values are not perfectly stable on our 8
On Wednesday 10 December 2008, Scott Wood wrote:
> On Wed, Dec 10, 2008 at 11:41:11AM +0100, Stefan Roese wrote:
> > +void *board_flash_read_memcpy(void *__to, __const__ void *__from, int
> > n); +
> > +#if defined(CONFIG_FLASH_NOT_MEM_MAPPED)
> > +static inline int flash_read(void *__to, __const__
Hello
I've just come across a problem. I have ARM-based board with its
originally shipped bootloader (not U-Boot, and having less
functionality) placed in NOR flash. However it initializes CPU, memory
controller, does remap.
Briefly about the memory map: before remap NOR flash is at 0x0 and
SDRAM
On Thursday 11 December 2008 05:22:49 Wolfgang Denk wrote:
> erase 4000 +1
when was this notation added ? i'm not familiar with it ... but until
recently, i was living with u-boot-1.1.6 ...
and any tips on which flash systems are known to support this syntax ? i can
look at fixing t
Rather than have the board code initialize SATA automatically during boot,
make the user manually run "sata init". This brings the SATA subsystem in
line with common U-Boot policy.
Along these lines, the "is_sata_supported()" hook is no longer needed, so
scrub it from the tree.
Signed-off-by: Mi
Dear Mike Frysinger,
In message <[EMAIL PROTECTED]> you wrote:
>
> the different flash subsystems dont exactly all operate the same,
> specifically
> when it comes to erasing. some require you to specify lengths that are
> aligned exactly to the erase sector size whereas others are much more
Hi Jean,
First of all sorry for late feedback
Thanks for your help.
I tried to apply the above patch but it has lot of diff,
On the other thread I have migrated to latest u-boot version and the problem
got resolved :-)
I think your patch is mainlined.
But I am facing now new problem...
The earlie
Dear Mike Frysinger,
In message <[EMAIL PROTECTED]> you wrote:
>
> the SATA/IDE/etc... layers seem to go against the u-boot policy when it comes
> to initialization. in other words, if support for them is enabled, then they
> are unconditionally initialized in board code (see ide_init / sata_init
1 - 100 of 104 matches
Mail list logo
