Dear Ulf Samuelsson,
In message <4a864121@atmel.com> you wrote:
>
> I think the open source community has converged on the
> "make DESTDIR= install" method
$ cd linux
$ make at91rm9200dk_defconfig
$ make uImage
$ mkdir /tmp/foo
$ mkdir DESTDIR=/tmp/foo install
...
CHK include/linux/comp
Wolfgang Denk skrev:
> Dear Ulf Samuelsson,
>
> In message <4a84779f.7010...@atmel.com> you wrote:
>> This still means that the external buildsystem need to
>> know the internals of u-boot.
>
> You always have to know the interface to the U-Boot build framework,
> there is no way around that.
Ye
This fixes an issue that cropped in v2009.08-rc testing.
The following changes since commit 7dedefdf749ff02c1086f7ddb8cb83a77b00d030:
John Schmoller (1):
flash: Fix CFI buffer size bug
are available in the git repository at:
git://git.denx.de/u-boot-mpc85xx.git master
Kumar Gala (1)
When we init the addrmap based on the TLB we will not end up getting
the TLB that covers memory if we are using SPD. The reason is we
haven't relocated at the point that we setup the memory TLB and thus it
will not get setup in the addrmap.
Instead we can just walk over the TLB array after we've
On Aug 14, 2009, at 3:13 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:00 Fri 14 Aug , Kumar Gala wrote:
>> Added a arch_preboot() function that cpu specific code can
>> implement to
>> allow for various modifications to the state of the machine right
>> before
>> we boot. This can
On 14:00 Fri 14 Aug , Kumar Gala wrote:
> Added a arch_preboot() function that cpu specific code can implement to
> allow for various modifications to the state of the machine right before
> we boot. This can be useful to setup register state to a specific
> configuration.
>
> Signed-off-by:
On Aug 14, 2009, at 2:00 PM, Kumar Gala wrote:
> Added a arch_preboot() function that cpu specific code can implement
> to
> allow for various modifications to the state of the machine right
> before
> we boot. This can be useful to setup register state to a specific
> configuration.
>
> Sig
In future Book-E implementations IVORs will most likely go away and be
replaced with fixed offsets. The IVPR will continue to exist to allow
for relocation of the interrupt vectors.
This code adds support to setup the IVORs as their fixed offset values
per the ISA 2.06 spec when we transition fro
Added a arch_preboot() function that cpu specific code can implement to
allow for various modifications to the state of the machine right before
we boot. This can be useful to setup register state to a specific
configuration.
Signed-off-by: Kumar Gala
---
common/cmd_bootm.c | 10 ++
1
Signed-off-by: Kumar Gala
---
* Make it build by include netdev.h
board/freescale/mpc8572ds/mpc8572ds.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mpc8572ds/mpc8572ds.c
b/board/freescale/mpc8572ds/mpc8572ds.c
index 59d7519..7da70fe 100644
--- a/bo
Ok. Thanks for your input.
wd wrote:
>
> Dear dbrazeau,
>
> In message <24975016.p...@talk.nabble.com> you wrote:
>>
>> I actually tried used ace as well, since I saw it being used in some of
>> the
>> environment variables. Unfortunately that didn't work either, but had a
>> different error.
Dear dbrazeau,
In message <24975016.p...@talk.nabble.com> you wrote:
>
> I actually tried used ace as well, since I saw it being used in some of the
> environment variables. Unfortunately that didn't work either, but had a
> different error.
>
> fatload ace 0 0x100 /mnt-xsa/kdiags.katmai.im
Ben Goska wrote:
> In commit 187af954cf7958c24efcf0fd62289bbdb4f1f24e there was a typo that
> offset all the ecc registers by 4 bytes, fixed that.
>
> Signed-off-by: Ben Goska
Acked-by: Dirk Behme
Should be applied as bugfix to -rc.
Thanks
Dirk
> ---
> include/asm-arm/arch-omap3/cpu.h |
Frederik Kriewitz wrote:
> I'm a bit confused about the u-boot code which reads the OMAP die id.
>
>>From the OMAP TRM:
> CONTROL.CONTROL_DIE_ID[127:0]
> Address: 0x4830A218
> Size: 128
>
> u-boot code:
> http://gitorious.org/u-boot-omap3/mainline/blobs/master/cpu/arm_cortexa8/omap3/sys_info.c#l
In commit 187af954cf7958c24efcf0fd62289bbdb4f1f24e there was a typo that offset
all the ecc registers by 4 bytes, fixed that.
Signed-off-by: Ben Goska
---
include/asm-arm/arch-omap3/cpu.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-arm/arch-omap3/cpu.
I actually tried used ace as well, since I saw it being used in some of the
environment variables. Unfortunately that didn't work either, but had a
different error.
fatload ace 0 0x100 /mnt-xsa/kdiags.katmai.img
reading /mnt-xsa/kdiags.katmai.img
** Unable to read "/mnt-xsa/kdiags.katmai.im
On Friday 14 August 2009 17:56:07 dbrazeau wrote:
> I working on the Katmai board. I'm trying to run a program in the 16MB
> boot flash. The user manual states the U-boot command to load Kozio
> diagnostics program is:
> => fatload xsa 0x100 /mnt-xsa/kdiags.katmai.img
That's not boot flash b
Hi,
This afternoon I spent some time trying to get a CompactFlash card to work on
ARM (AT91). While looking at the code, I noticed several things in the I/O code
that I think are wrong or could be improved, so I figured I'd ask here before
writing a patch., as I might be overlooking some things.
I working on the Katmai board. I'm trying to run a program in the 16MB boot
flash. The user manual states the U-boot command to load Kozio diagnostics
program is:
=> fatload xsa 0x100 /mnt-xsa/kdiags.katmai.img
=> bootm 0x100
This doesn't work as it does not define a device number, so I
In commit 187af954cf7958c24efcf0fd62289bbdb4f1f24e there was a typo that offset
all the ecc registers by 4 bytes, fixed that.
Signed-off-by Dirk Behme
---
include/asm-arm/arch-omap3/cpu.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-arm/arch-omap3/cpu.h
On Thu, Aug 13, 2009 at 05:58:57PM -0500, alfred steele wrote:
> > That controls whether the "jffs2" command supports NAND.
> Iis it a MUST HAVE if you are using a jffs2 root filesystem? I mean do
> i have to turn on "CONFIG_JFFS2_NAND" if i have a jff2 rootfs.
> Are there any other configuration f
Hi dbrazeau,
> This is the command I try to execute in the U-boot console:
> fatload xsa 0 0x100 /mnt-xsa/someprogram.img
>
> output:
> ** Invalid boot device **
Do you pay for every character you send, or why are you so very
restrictive in providing more information to your problem?
Albin Tonnerre writes:
> In the process, also remove backward-compatiblity macros BIN_TO_BCD and
> BCD_TO_BIN and update the sole board using them to use the new bin2bcd
> and bcd2bin instead
>
> Signed-off-by: Albin Tonnerre
Being (somewhat) responsible for one of the rtc drivers, all I can sa
I'm a bit confused about the u-boot code which reads the OMAP die id.
>From the OMAP TRM:
CONTROL.CONTROL_DIE_ID[127:0]
Address: 0x4830A218
Size: 128
u-boot code:
http://gitorious.org/u-boot-omap3/mainline/blobs/master/cpu/arm_cortexa8/omap3/sys_info.c#line44
result: Die ID #: 04ba0054 0020
>
> There are always other issues. :-)
>
> Unless the issues show up on hardware I'm working with, there's not much
> I can do other than apply patches from others.
>
> > Shrinking the footprint will first need to be done in the MTD GIT and
> > then the changes should trickle down to other tree
Ben Goska wrote:
> After commit [1] I noticed a problem with the HW ECC no longer
> working. After looking into it I found that there was a typo that
> caused the ecc registers to be shifted by 4 bytes. The patch attached
Thanks for finding this!
Something seems to be strange with the mails, thou
Dear Peter Chen,
In message <1250231900.7144.40.ca...@nchen-desktop> you wrote:
>
> 1. Does jump table means the function lists which the standalone
> applications uses?
The "jump table provided by U-Boot exactly for this purpose" is the
list of functions exported through the "include/_exports.h
The name of the atmel nand driver in the kernel changed from at91_nand
to atmel_nand back in June 2008, but the at91-based boards config files
still refer to at91_nand. This patch updates them with the new name
Signed-off-by: Albin Tonnerre
---
Changes:
- Don't change the driver name for the pm9
Hi,
we are using U-Boot on PPC405 and PPC440EPx CPU in systems that have a lot
of PCIe switches and PCIe/PCI bridges. Even multiple cascaded switches and
bridges :-)
U-Boot has no problems with these architecture.
But of course nobody really knows if there are issue that you might run into.
Mat
On 02:32 Tue 11 Aug , Ilya Yanok wrote:
> This patch adds support for i.MX27-LITEKIT development board from
> LogicPD. This board uses i.MX27 SoC and has 2MB NOR flash, 64MB NAND
> flash, FEC ethernet controller integrated into i.MX27.
>
> Signed-off-by: Ilya Yanok
> ---
> MAINTAINERS
On 13:00 Thu 13 Aug , Albin Tonnerre wrote:
> On Sat, Aug 01, 2009 at 10:59:00PM +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote :
> > On 17:40 Fri 31 Jul , Albin Tonnerre wrote:
> > > Hi Wolfgang and Jean-Christophe,
> > >
> > > Is this patch being left aside on purpose, or did it get un
31 matches
Mail list logo
