Hello Sughosh,
Sughosh Ganu wrote:
> hi Christian,
>
> On Tue, Jan 31, 2012 at 7:26 PM, Christian Riesch <
> christian.rie...@omicron.at> wrote:
>
>> The V bit of the c1 register of CP15 should not be cleared
>> since the SoC has no valid memory at 0x.
>>
>> Signed-off-by: Christian Ries
Hi Tom, Hi Matt,
On Tuesday, January 31, 2012, Tom Rini wrote:
> From: Matt Porter
>
> Adds support for loading U-Boot from UART using YMODEM protocol.
> If YMODEM support is enabled in SPL and the romcode indicates
> that SPL loaded via UART then SPL will wait for start of a
> YMODEM transfer v
Eric,
On Tue, Jan 31, 2012 at 9:39 PM, Eric Nelson
wrote:
> On 01/30/2012 11:51 PM, Jason Liu wrote:
>>
>> Eric,
>>
>> 2012/1/31 Eric Nelson:
>>>
>>> This patch set refactors mxc_spi as described in
>>> http://lists.denx.de/pipermail/u-boot/2010-March/068791.html
>>> and requested in
>>> ht
On Tuesday 31 January 2012 17:07:05 Bud Miljkovic wrote:
> Hi there,
>
>
>
> While getting acquainted with possible u-Boot development issues, I read
> FAQ "14.2.1. Can U-Boot be configured such that it can be started in
> RAM?" and was puzzled to learn that u-Boot cannot run from RAM.
This is cl
On 1/31/2012 5:29 PM, Andy Fleming wrote:
On Mon, Jan 30, 2012 at 8:13 PM, Troy Kisky
wrote:
On 1/29/2012 7:04 PM, Andy Fleming wrote:
On Thu, Jan 26, 2012 at 4:21 PM, Troy Kisky
wrote:
Signed-off-by: Troy Kisky
---
drivers/net/fec_mxc.c | 35 ++-
dri
On Mon, Jan 30, 2012 at 8:13 PM, Troy Kisky
wrote:
> On 1/29/2012 7:04 PM, Andy Fleming wrote:
>>
>> On Thu, Jan 26, 2012 at 4:21 PM, Troy Kisky
>> wrote:
>>>
>>> Signed-off-by: Troy Kisky
>>> ---
>>> drivers/net/fec_mxc.c | 35 ++-
>>> drivers/net/fec_mxc.h |
The decompressor expects the L2 cache to be disabled. This fixes booting
some kernels, which have CONFIG_ARM_PATCH_PHYS_VIRT enabled.
Signed-off-by: Michael Walle
Cc: Albert ARIBAUD
Cc: Prafulla Wadaskar
Cc: Wolfgang Denk
---
v3:
remove unused enable function
v2:
replace magic number with
Dear Michael Walle,
In message <201201312349.37621.mich...@walle.cc> you wrote:
>
> > My enable function is just for completeness atm.
>
> Ping.
>
> Is there something still uncertain?
Nothing is uncertain.
But we do not add dead code.
Best regards,
Wolfgang Denk
--
DENX Software Engineeri
Am Freitag 13 Januar 2012, 23:59:08 schrieb Michael Walle:
> [Sorry can't answer to the original message, because it was blocked by spam
> filter]
>
> > Also, I'm missing something: you introduce two functions, for enabling
> > and disabling the cache, yet the code uses only the one for disabling.
The Integrator/CP config file was very outdated and gives a
non functional U-Boot. So:
- Set the CONFIG_ARCH_CINTEGRATOR arch flag correctly
- Add proper core module configuration options
- Skip cluttered command lista and just include
- Kill off #if 0 network section and insert some example
From: Matt Porter
Cc: Chandan Nath
Tested-by: Tom Rini
Signed-off-by: Matt Porter
---
include/configs/am335x_evm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 2cea1f4..23663de 100644
--- a/include/c
From: Matt Porter
Adds support for loading U-Boot from UART using YMODEM protocol.
If YMODEM support is enabled in SPL and the romcode indicates
that SPL loaded via UART then SPL will wait for start of a
YMODEM transfer via the console port.
Signed-off-by: Matt Porter
Signed-off-by: Tom Rini
-
Hi Daniel,
On Tuesday, January 31, 2012, Daniel Nilsson wrote:
> I am bringing up a board that has a Freescale P1020 (PowerPC e500v2)
> and a 16-bit PC28F256J3 NOR-flash on it.
>
> My problem is that both erases and programming takes very long time.
> Reading from the flash on the other hand, is
This adds a SPI flash driver which simulates SPI flash clients.
Currently supports the bare min that U-Boot requires: you can
probe, read, erase, and write. Should be easy to extend to make
it behave more exactly like a real SPI flash, but this is good
enough to merge now.
Signed-off-by: Mike Fry
We want to test SPI flash code in the sandbox, so enable the new drivers.
Acked-by: Simon Glass
Signed-off-by: Mike Frysinger
---
include/configs/sandbox.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index
Should address the feedback posted by Simon.
Mike Frysinger (5):
sandbox: add lseek helper
sandbox: add getopt support
sandbox: SPI emulation bus
sandbox: new SPI flash driver
sandbox: enable new spi/sf layers
arch/sandbox/cpu/os.c | 26 +++
arch/sandbox/cpu/start.c |
Note: just a PoC that the current SPI flash code is based on.
Not meant to reject the getopt code Simon posted.
Signed-off-by: Mike Frysinger
---
arch/sandbox/cpu/os.c| 13 +
arch/sandbox/cpu/start.c | 24
include/os.h |2 ++
3 files c
This adds a SPI framework for people to hook up simulated SPI clients.
Signed-off-by: Mike Frysinger
---
arch/sandbox/include/asm/spi.h | 48 ++
drivers/spi/Makefile |1 +
drivers/spi/sandbox_spi.c | 198
3 files changed, 247
Follow up patches want to be able to seek fd's.
Signed-off-by: Mike Frysinger
---
arch/sandbox/cpu/os.c | 13 +
include/os.h | 15 +++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 093e7dc.
I am bringing up a board that has a Freescale P1020 (PowerPC e500v2)
and a 16-bit PC28F256J3 NOR-flash on it.
My problem is that both erases and programming takes very long time.
Reading from the flash on the other hand, is quite fast (at least a
few MByte/s).
I have set up the BR0, OR0 and other
In an effort to unify the spi flash drivers further, drop all the
unused and/or duplicate command defines.
Signed-off-by: Mike Frysinger
---
drivers/mtd/spi/eon.c|9 -
drivers/mtd/spi/macronix.c | 11 +--
drivers/mtd/spi/ramtron.c| 23
No need for dedicated defines when these really only get used once.
Signed-off-by: Mike Frysinger
---
drivers/mtd/spi/spansion.c | 34 --
1 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
ind
Am Dienstag, den 31.01.2012, 10:01 +0100 schrieb Michal Simek:
> Stephan Linz wrote:
> > Expand the specific configuration for the microblaze-generic
> > board in xparameters.h with a faked setup to enable the
> > LL_TEMAC driver.
> >
> > Note: From now the microblaze-generic board is no longer a
In 8775471bb, the call to timer_init() was removed from common code
and put in OMAP3 s_init() function. As a result the boot was broken
on OMAP4. This patch adds timer_init() in OMAP4 s_init(), that fix
boot on all OMAP4 boards.
Signed-off-by: Nicolas Dechesne
Tested-by: Robert P. J. Day
Cc: San
On 01/31/2012 11:11 AM, Mike Frysinger wrote:
On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote:
Patch 1 modifies the 'sf' command to allow a default bus and chip-select
to be specified by board headers. This allows a bare 'sf' probe command:
U-Boot> sf probe
instead of the more cumb
Am Dienstag, den 31.01.2012, 10:00 +0100 schrieb Michal Simek:
> Stephan Linz wrote:
> > U-Boot's multipple network supports enables to use
> > several ethernet drivers but microblaze-generic
> > platform config file select only one driver.
> >
> > Reported-by: Michal Simek
> > Signed-off-by: St
> > Right, because RAM size is 0. I see, so DRAM init fails somewhere.
>
> That's exactly where and why it hangs, in my case.
>
> > I think
> > though it doesn't hang in the POWER init code anymore.
>
> In my case, I don't think it hung in power_init before your patch. I'm
> pretty sure it hung
On Tuesday 31 January 2012 11:21:29 Dirk Behme wrote:
> On 31.01.2012 16:16, Mike Frysinger wrote:
> > On Monday 30 January 2012 15:02:24 Eric Nelson wrote:
> >> Patch 1 modifies the 'sf' command to allow a default bus and chip-select
> >>
> >> to be specified by board headers. This allows a bare
On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote:
> Patch 1 modifies the 'sf' command to allow a default bus and chip-select
> to be specified by board headers. This allows a bare 'sf' probe command:
> U-Boot> sf probe
> instead of the more cumbersome usage when a GPIO is tacked onto
> t
Signed-off-by: Mike Frysinger
---
drivers/mtd/spi/eeprom_m95xxx.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi/eeprom_m95xxx.c b/drivers/mtd/spi/eeprom_m95xxx.c
index ef8ed6f..bae9445 100644
--- a/drivers/mtd/spi/eeprom_m95xxx.c
Every board currently defines this to the same value, so just default
to that to avoid having to make everyone do the same thing.
Signed-off-by: Mike Frysinger
---
drivers/mtd/spi/eeprom_m95xxx.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/eeprom_m
> > Right, because RAM size is 0. I see, so DRAM init fails somewhere.
>
> That's exactly where and why it hangs, in my case.
>
> > I think
> > though it doesn't hang in the POWER init code anymore.
>
> In my case, I don't think it hung in power_init before your patch. I'm
> pretty sure it hung
hi Christian,
On Tue, Jan 31, 2012 at 7:26 PM, Christian Riesch <
christian.rie...@omicron.at> wrote:
> The V bit of the c1 register of CP15 should not be cleared
> since the SoC has no valid memory at 0x.
>
> Signed-off-by: Christian Riesch
> Reported-by: Sughosh Ganu
> Cc: Albert Arib
Signed-off-by: Eric Nelson
---
README | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 9d713e8..4dbebcb 100644
--- a/README
+++ b/README
@@ -809,6 +809,7 @@ The following options need to be configured:
Signed-off-by: Eric Nelson
Acked-by: Dirk Behme
Acked-by: Stefano Babic
---
board/freescale/mx6qsabrelite/mx6qsabrelite.c |2 +-
include/configs/mx6qsabrelite.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelit
The default settings store the persistent environment on SD card
and not serial flash (SPI NOR).
To use SPI NOR to save the environment instead of SD card, edit
include/configs/mx6qsabrelite.h and
- undefine CONFIG_ENV_IS_IN_MMC
- define CONFIG_ENV_IS_IN_SPI_FLASH
The SPI driver can take as ch
Move (E)CSPI register declarations into the imx-regs.h files for each supported
CPU
Introduce two new macros to control conditional setup
MXC_CSPI - Used for processors with the Configurable Serial Peripheral
Interface (MX3x)
MXC_ECSPI - For processors with Enhanced Configurable... (MX
Signed-off-by: Eric Nelson
Acked-by: Dirk Behme
Acked-by: Stefano Babic
---
arch/arm/include/asm/arch-mx6/imx-regs.h | 44 ++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/i
Signed-off-by: Eric Nelson
Acked-by: Dirk Behme
Acked-by: Stefano Babic
---
board/freescale/mx6qsabrelite/imximage.cfg|2 +-
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 25 +
include/configs/mx6qsabrelite.h |9 +
3 files changed, 3
Patch 1 modifies the 'sf' command to allow a default bus and chip-select
to be specified by board headers. This allows a bare 'sf' probe command:
U-Boot> sf probe
instead of the more cumbersome usage when a GPIO is tacked onto
the chip-select. Otherwise, this command-line would be needed
to s
This patch allows a board configuration file to provide default bus
and chip-selects for SPI flash so that first argument to the 'sf' command
is optional.
On boards that use the mxc_spi driver and a GPIO for chip select, this allows
a much simpler command line:
U-Boot> sf probe
instead of
The interface to the mxc_gpio driver uses integer (ordinal) values to
refer to all GPIOs on the i.MX processors. The registers themselves
and much of the i.MX documentation are banked in groups of 32, and these
macros allow the use of the port:index numbering for clarity.
GPIO_NUMBER() converts to
This patch set refactors mxc_spi as described in
http://lists.denx.de/pipermail/u-boot/2010-March/068791.html
and requested in
http://lists.denx.de/pipermail/u-boot/2012-January/116023.html
in order to add support for the MX6Q in general and the mx6qsabrelite
specifically.
Patch 1 si
I'm about to send an updated set of patches for mxc_spi re-factoring
and the related cleanup stemming from the discussions in
http://lists.denx.de/pipermail/u-boot/2012-January/116816.html
These are split into multiple patch sets as suggested by Dirk:
http://lists.denx.de/pipermai
> Right, because RAM size is 0. I see, so DRAM init fails somewhere.
That's exactly where and why it hangs, in my case.
> I think
> though it doesn't hang in the POWER init code anymore.
In my case, I don't think it hung in power_init before your patch. I'm pretty
sure it
hung at the same place
On Fri, Jan 27, 2012 at 9:38 AM, manishdkanchan
wrote:
>
> Hi,
> I am Manish and i have recently started working on beagleboard xm.
> I am facing certain issues. Need guidance to solve it.
>
> Background:
> I am using beagleboard xm, uboot version 9 of 2011
>
> Intention:
> Current version of uboo
On 31.01.2012 16:16, Mike Frysinger wrote:
On Monday 30 January 2012 15:02:24 Eric Nelson wrote:
Patch 1 modifies the 'sf' command to allow a default bus and chip-select
to be specified by board headers. This allows a bare 'sf' probe command:
U-Boot> sf probe
instead of the more cumberso
Dear Vaibhav Kothari,
please keep the ML on Cc:
In message
you wrote:
>
> Thank you very muchyour answer is really very helpful..
>
>
> Though if i wanted to test flash all sectors but not one which contains
> uboot code ...is it possible to do so??how?
Sure. Try for example:
=
Hi Fabio,
On 31.01.2012 15:53, Fabio Estevam wrote:
> On 1/31/12, Matthias Fuchs wrote:
>
>> The USB boot mechanism is not documented that detailed.
>> Is it possible that the SPL code overwrites the bootroms ivt and
>> in consequence crashes the bootrom's USB code? Any further ideas?
>
> Compl
On 31.01.2012 15:25, Sergey Lapin wrote:
> On Tue, Jan 31, 2012 at 03:03:55PM +0100, Matthias Fuchs wrote:
>> Hi,
>>
>> I have a problem booting the current u-boot-imx version
>> on a MX28EVK via USB. The i.MX28 CPU supports a special boot mode
>> where the image (sb boot stream) is downloaded via
On 01/31/2012 08:16 AM, Mike Frysinger wrote:
On Monday 30 January 2012 15:02:24 Eric Nelson wrote:
Patch 1 modifies the 'sf' command to allow a default bus and chip-select
to be specified by board headers. This allows a bare 'sf' probe command:
U-Boot> sf probe
instead of the more cumbe
On Monday 30 January 2012 15:02:24 Eric Nelson wrote:
> Patch 1 modifies the 'sf' command to allow a default bus and chip-select
> to be specified by board headers. This allows a bare 'sf' probe command:
> U-Boot> sf probe
> instead of the more cumbersome usage when a GPIO is tacked onto
> th
On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
> While getting acquainted with possible u-Boot development issues, I read
> FAQ "14.2.1. Can U-Boot be configured such that it can be started in
> RAM?" and was puzzled to learn that u-Boot cannot run from RAM.
you misread it. the question
Hi,
Same here. I've applied the patch and tried it on my mx28evk and 'reboot' from
the
Kernel prompt results into DRAM: 0 Bytes and a hanging U-Boot.
I didn't try single-stepping with the debugger yet; I'm still messing around
with the PLL bypass bit and PLL configuration.
Cheers,
Robe
On 31/01/2012 15:16, Eric Nelson wrote:
> On 01/31/2012 02:31 AM, Jason Hui wrote:
>> Eric,
>>
Hi Eric,
> Ouch! It's all about the GPIO numbers...
>
> This occurred when I re-based to Stefano's tree and will require
> another patch to keep the BANK:OFFSET numbering scheme. There's a
> patch ling
On 1/31/12, Matthias Fuchs wrote:
> The USB boot mechanism is not documented that detailed.
> Is it possible that the SPL code overwrites the bootroms ivt and
> in consequence crashes the bootrom's USB code? Any further ideas?
Completely untested, but please give it a try:
diff --git a/arch/arm
On Tue, Jan 31, 2012 at 4:25 AM, Stefano Babic wrote:
> On 30/01/2012 19:05, Tom Rini wrote:
>
> Hi Tom,
>
>>> OK, doing a MAKEALL for omap3/4/5/am33xx/davinci shows we've got a few
>>> missing include problems, I'll go fix that up.
>>
>> OK, was it when you took over the series that you moved stu
On Tue, Jan 31, 2012 at 03:03:55PM +0100, Matthias Fuchs wrote:
> Hi,
>
> I have a problem booting the current u-boot-imx version
> on a MX28EVK via USB. The i.MX28 CPU supports a special boot mode
> where the image (sb boot stream) is downloaded via USB device
> (all DIP switches in position 'off
On 01/31/2012 02:31 AM, Jason Hui wrote:
Eric,
On Tue, Jan 31, 2012 at 3:52 AM, Eric Nelson
wrote:
Signed-off-by: Eric Nelson
Acked-by: Dirk Behme
Acked-by: Stefano Babic
---
board/freescale/mx6qsabrelite/imximage.cfg|2 +-
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 25 +
On 01/30/2012 09:07 PM, Bud Miljkovic wrote:
Hi there,
While getting acquainted with possible u-Boot development issues, I read
FAQ "14.2.1. Can U-Boot be configured such that it can be started in
RAM?" and was puzzled to learn that u-Boot cannot run from RAM.
Considering a custom platform
Hi,
I have a problem booting the current u-boot-imx version
on a MX28EVK via USB. The i.MX28 CPU supports a special boot mode
where the image (sb boot stream) is downloaded via USB device
(all DIP switches in position 'off' on the EVK). The
CPU's internal bootrom implements a HID device in this mo
Hi Tom,
On Mon, Jan 30, 2012 at 6:03 PM, Tom Rini wrote:
> On Sun, Jan 29, 2012 at 6:36 AM, Christian Riesch
> wrote:
>
>> 3) As Sughosh pointed out, the current code changes the V bit
>> (location of exceptions). Sughosh's patch removes this code that does
>> this change. I'm not sure if this
From: Sughosh Ganu
This patch moves hawkboard to the new spl infrastructure from the
older nand_spl one.
Removed the hawkboard_nand_config build option -- The spl code now
gets compiled with hawkboard_config, after building the main u-boot
image, using the CONFIG_SPL_TEXT_BASE. Modified the READ
This patch reverts commit ca4b55800ed74207c35271bf7335a092d4955416
"arm, arm926ejs: always do cpu critical inits" since it impacts all
arm926ejs based configurations and caused problems, e.g., with
the hawkboard.
Instead the patch removes the CONFIG_SKIP_LOWLEVEL_INIT defines
from the board config
From: Sughosh Ganu
The current implementation invalidates the data cache before turning it
off and causes problems on the hawkboard. See the discussion in
http://lists.denx.de/pipermail/u-boot/2012-January/115212.html
According to the ARM926EJ-S Technical Reference Manual, the cache should
be fl
This patch adds support for the Calimain board from
OMICRON electronics GmbH. The board features a Texas Instruments AM1808
SoC, 128 MB DDR2 memory, and 64 MB NOR flash memory connected to CS2 and
CS3.
Signed-off-by: Christian Riesch
---
MAINTAINERS |5 +
board/omicron/
The low level initialization code in
arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S was written for
DM644X SoCs only. This patch makes the lowlevel_init function in this
file a dummy function for SoCs other than DM644X.
Signed-off-by: Christian Riesch
Cc: Tom Rini
Cc: Sergey Kubushyn
---
arch/
The V bit of the c1 register of CP15 should not be cleared
since the SoC has no valid memory at 0x.
Signed-off-by: Christian Riesch
Reported-by: Sughosh Ganu
Cc: Albert Aribaud
Cc: Tom Rini
---
arch/arm/cpu/arm926ejs/start.S |5 -
1 files changed, 4 insertions(+), 1 deletions(
Signed-off-by: Christian Riesch
Cc: Albert Aribaud
Cc: Tom Rini
---
arch/arm/cpu/arm926ejs/start.S |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index b350480..829065f 100644
--- a/arch/arm/cpu/arm926
Hi,
In this patchset I tried to put everything from the discussion
in http://lists.denx.de/pipermail/u-boot/2012-January/115212.html
Although this is the first version of this patchset, the version number
is v5 since Sughosh's patches were already v4.
Regards, Christian
Christian Riesch (5):
On 01/30/2012 11:51 PM, Jason Liu wrote:
Eric,
2012/1/31 Eric Nelson:
This patch set refactors mxc_spi as described in
http://lists.denx.de/pipermail/u-boot/2010-March/068791.html
and requested in
http://lists.denx.de/pipermail/u-boot/2012-January/116023.html
in order to add support for
On 31/01/2012 13:07, Jason Liu wrote:
> FEC does not work on the i.mx51/53evk board, it will hangup
> In:serial
> Out: serial
> Err: serial
> Net:
>
> After bisect, it due to the following commit:
> be252b6 net: imx: Add multi-FEC support for imx_get_mac_from_fuse
> has change the imx_get_
On 31.01.2012 12:38, Marek Vasut wrote:
>> I tested both patch on my mx28evk. At least I cannot notice any
>> missbehavior :-) Downloading the patched u-boot via USB recovery
>> download still does not work.
>
> Good, any improvements though?
No. It works as before. Whatever that means :-)
I will
> On 1/30/12, Marek Vasut wrote:
> > Note: Guys, please give this a testrun. I think it might fix the issue
> > Robert
> > was observing. I dug into the imx-bootlets and the bootrom X-Files and
> > found this paranormal piece of code. Adding it fixes the boot issue on
> > my crappy board.
>
> Tri
On 1/30/12, Marek Vasut wrote:
> Note: Guys, please give this a testrun. I think it might fix the issue
> Robert
> was observing. I dug into the imx-bootlets and the bootrom X-Files and found
> this paranormal piece of code. Adding it fixes the boot issue on my crappy
> board.
Tried your patch a
On 1/31/12, Jason Liu wrote:
> FEC does not work on the i.mx51/53evk board, it will hangup
> In:serial
> Out: serial
> Err: serial
> Net:
>
> After bisect, it due to the following commit:
> be252b6 net: imx: Add multi-FEC support for imx_get_mac_from_fuse
> has change the imx_get_mac_from_
FEC does not work on the i.mx51/53evk board, it will hangup
In:serial
Out: serial
Err: serial
Net:
After bisect, it due to the following commit:
be252b6 net: imx: Add multi-FEC support for imx_get_mac_from_fuse
has change the imx_get_mac_from_fuse fucntion prototype, but fail
to update i.m
Dear vk,
In message you wrote:
> Is it safer to test flash during bootup...what if power gets off half a way
> while writing data on address at which uboot source code is located?Then uboot
> will never get started??
Write testing of flash devices on a regular base (like as part of the
POST at e
> I tested both patch on my mx28evk. At least I cannot notice any
> missbehavior :-) Downloading the patched u-boot via USB recovery
> download still does not work.
Good, any improvements though?
>
> Marek, did you find any further mentionable difference between bootlets
> code and current u-boot
On 30/01/2012 19:05, Tom Rini wrote:
Hi Tom,
>> OK, doing a MAKEALL for omap3/4/5/am33xx/davinci shows we've got a few
>> missing include problems, I'll go fix that up.
>
> OK, was it when you took over the series that you moved stuff to
> common/spl.c ? That idea is breaking, badly, non-omap p
Works fine.
Matthias
Tested-by: Matthias Fuchs
On 30.01.2012 21:02, Eric Nelson wrote:
> This patch allows a board configuration file to provide default bus
> and chip-selects for SPI flash so that first argument to the 'sf' command
> is optional.
>
> On boards that use the mxc_spi driver and
I tested both patch on my mx28evk. At least I cannot notice any
missbehavior :-) Downloading the patched u-boot via USB recovery
download still does not work.
Marek, did you find any further mentionable difference between bootlets
code and current u-boot implementation?
Matthias
On 31.01.2012 01
Is it safer to test flash during bootup...what if power gets off half a way
while writing data on address at which uboot source code is located?Then uboot
will never get started??
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/
Hi all,
Currently I am testing the Flash memory by using "Write and Read the
same pattern" method (Protecting the UBoot Flash Sectors).
Is it safer to test flash memory during bootup?what if power gets off during
process?
I want to know whether there is any alternative method to test the
comple
Eric,
On Tue, Jan 31, 2012 at 3:52 AM, Eric Nelson
wrote:
> Signed-off-by: Eric Nelson
> Acked-by: Dirk Behme
> Acked-by: Stefano Babic
> ---
> board/freescale/mx6qsabrelite/imximage.cfg | 2 +-
> board/freescale/mx6qsabrelite/mx6qsabrelite.c | 25
> +
> inclu
On Mon, Jan 30, 2012 at 10:22 PM, Tom Rini wrote:
> Before we can send a command we need both the DATI (command inhibit on
> mmc_dat line) bit and CMDI (command inhibit on mmc_cmd line) are clear.
> The previous behavior of only checking on DATI was insufficient on some
> cards and incorrect behav
On Tue, Jan 31, 2012 at 3:52 AM, Eric Nelson
wrote:
> Signed-off-by: Eric Nelson
> Acked-by: Dirk Behme
> Acked-by: Stefano Babic
> ---
> arch/arm/include/asm/arch-mx6/imx-regs.h | 44
> ++
> 1 files changed, 44 insertions(+), 0 deletions(-)
Acked-by: Jason Liu
Eric
On Tue, Jan 31, 2012 at 3:52 AM, Eric Nelson
wrote:
> Move (E)CSPI register declarations into the imx-regs.h files for each
> supported CPU
>
> Introduce two new macros to control conditional setup
> MXC_CSPI - Used for processors with the Configurable Serial Peripheral
> Interface (MX
Stephan Linz wrote:
Expand the specific configuration for the microblaze-generic
board in xparameters.h with a faked setup to enable the
LL_TEMAC driver.
Note: From now the microblaze-generic board is no longer a
valid board configuration for a real piece of hardware. Rather
than, we use the fil
Stephan Linz wrote:
U-Boot's multipple network supports enables to use
several ethernet drivers but microblaze-generic
platform config file select only one driver.
Reported-by: Michal Simek
Signed-off-by: Stephan Linz
---
include/configs/microblaze-generic.h | 12
1 files chang
90 matches
Mail list logo
