On Thu, 7 Aug 2008, Andreas Engel wrote:
> > diff --git a/cpu/arm1176/s3c64xx/interrupts.c
> > b/cpu/arm1176/s3c64xx/interrupts.c
> > new file mode 100644
> > index 000..4233e8c
> > --- /dev/null
> > +++ b/cpu/arm1176/s3c64xx/interrupts.c
>
> You can remove anything from enable_interrupts()
Hi Peter,
> I've included my kernel_fdt.its below as well as 2 boot attempts with
> some debug enabled - the 1st on without the patch, the 2nd with the
> patch. I'm using the mainline master (based on
> 1953d128fd07f07d1c3810a28c0863ea64dae1b6), not the 85xx repo, but I
> believe the problem exi
Magnus Lilja schrieb:
> Perhaps a 'imx' or 'imx31' directory would be
> better with all i.MX{31} boards in that directory.
Hmm... I propose to keep it consistent: either the boards should be
sorted by board vendor, or there could be a new directory between
"board" and "board/" emphasizing the C
In message <[EMAIL PROTECTED]> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
> ---
> remove imx31_phycore which is from phytec
> Makefile |4 ++--
> board/{ => freescale}/imx31_litekit/Makefile |0
> board/
In message <[EMAIL PROTECTED]> you wrote:
>
> Same goes for the Litekit board, the board is from LogicPD but the SoC
Arg. What a mess :-(
> is from Freescale. Perhaps a 'imx' or 'imx31' directory would be
> better with all i.MX{31} boards in that directory.
No, we will not do that.
We have ven
In message <[EMAIL PROTECTED]> you wrote:
>
> > board/{ => freescale}/imx31_phycore/Makefile |0
> > board/{ => freescale}/imx31_phycore/config.mk |0
> > .../{ => freescale}/imx31_phycore/imx31_phycore.c |0
> > .../{ => freescale}/imx31_phycore/lowlevel_init.S |0
On Wed, 6 Aug 2008, Scott Wood wrote:
> On Wed, Aug 06, 2008 at 09:42:07PM +0200, Guennadi Liakhovetski wrote:
> > block = offs / CFG_NAND_BLOCK_SIZE;
> > + blocks = (uboot_size + offs - ((block - 1) * CFG_NAND_BLOCK_SIZE) - 1) /
> > + CFG_NAND_BLOCK_SIZE;
> > blockcopy_count =
> diff --git a/cpu/arm1176/s3c64xx/interrupts.c
> b/cpu/arm1176/s3c64xx/interrupts.c
> new file mode 100644
> index 000..4233e8c
> --- /dev/null
> +++ b/cpu/arm1176/s3c64xx/interrupts.c
You can remove anything from enable_interrupts() to do_irq() here. It's
already in lib_arm/interrupts.c.
A
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
---
remove imx31_phycore which is from phytec
Makefile |4 ++--
board/{ => freescale}/imx31_litekit/Makefile |0
board/{ => freescale}/imx31_litekit/config.mk |0
Hi
On Thu, Aug 7, 2008 at 8:07 AM, Jens Gehrlein <[EMAIL PROTECTED]> wrote:
> Jean-Christophe PLAGNIOL-VILLARD schrieb:
>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
>> ---
>> Makefile |6 +++---
>> board/{ => freescale}/imx31
Jean-Christophe PLAGNIOL-VILLARD schrieb:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
> ---
> Makefile |6 +++---
> board/{ => freescale}/imx31_litekit/Makefile |0
> board/{ => freescale}/imx31_litekit/config.mk
In message <[EMAIL PROTECTED]> you wrote:
>
> I noticed that you are now maintaining a custodian tree which is
> focused on NAND support in u-boot. Could you please tell me is there
> any schedule or plan to publish your "testing" tree?
What do you mean by "publish"? The branch is public all the
Fully exportable and can be used for any purpose:
-> 164,939 Dentists
-> 158,143 Mailing Addresses
-> 163,012 Contact Phone #
-> 77,308 Fax Nos.
-> 45,497 Email Addresses
for this week cost is $293 (regular price $696)
For details please send an email to [EMAIL PROTECTED]
to get off p
Dear Mr.Scott Wood,
I noticed that you are now maintaining a custodian tree which is
focused on NAND support in u-boot. Could you please tell me is there
any schedule or plan to publish your "testing" tree?
Thanks.
BR,
Eric
On Wed, Aug 06, 2008 at 09:42:07PM +0200, Guennadi Liakhovetski wrote:
> block = offs / CFG_NAND_BLOCK_SIZE;
> + blocks = (uboot_size + offs - ((block - 1) * CFG_NAND_BLOCK_SIZE) - 1) /
> + CFG_NAND_BLOCK_SIZE;
> blockcopy_count = 0;
>
> - while (blockcopy_count <
Set PL44 Arbiter Read pipeline depth to 4
Optimize Memory Queue Configuration registers for PPC460EX/GT
Signed-off-by: Prodyut Hazarika <[EMAIL PROTECTED]>
---
board/amcc/canyonlands/canyonlands.c |9 +++
cpu/ppc4xx/44x_spd_ddr2.c|4 +
include/ppc440.h |
So I proposed something like:
bootm load_os
bootm load_fdt
so I figured trying to expand on what load_os does might be useful.
input:
ENV:bootm_low
ENV:bootm_size
BOOTMAP_SZ
image specifier (a standalone uImage, a multi-uImage, a FIT specifier)
output:
ERROR: if image doesn't pass validity chec
In message <[EMAIL PROTECTED]> you wrote:
> Add support for NAND and ethernet on the Freescale i.MX31 PDK (a.k.a.
> 3DS) board.
>
> Booting from NAND is not supported yet so U-boot relies on some other
> initial boot loader to set up SDRAM and clocks and copying U-boot to SDRAM.
>
> Signed-off-by
In message <[EMAIL PROTECTED]> you wrote:
>
> > Well, at the moment we don't do any such clever stuff eihter. We load
> > the kernel low and the ramdisk high. That's all.
> >
> > Do we need more?
>
> Yes. bd_t for old style boot... no idea on non-ppc.
bd_t is already handled as described.
> dtb
On 14:19 Wed 06 Aug , Magnus Lilja wrote:
> Add support for NAND and ethernet on the Freescale i.MX31 PDK (a.k.a.
> 3DS) board.
>
> Booting from NAND is not supported yet so U-boot relies on some other
> initial boot loader to set up SDRAM and clocks and copying U-boot to SDRAM.
>
> Signed-of
Currently, they use CONFIG_NUM_CPUS, which is different than
85xx for no good reason.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
Note: This is a resend; the first version accidentally changed the NR_CPUs
on 8610 to 2.
cpu/mpc86xx/start.S |4 ++--
include/configs/MPC8610HPCD
So far I have found a hardware problem with two of my boards. I will
update as to whether the hardware problem was the only problem or if I
needed to make changes to u-boot to work around the problem
temporarily...
-
This SF.N
>>> Stop, this is not correct. "filesize" gets set when loading the
>>> (compressed) image. It contains the _file_ size, i. e. the sum of
>>> all
>>> included images plus headers etc.
>>>
>>> bootm does not touch filesize.
>>
>> in the method you guys seem to be arguing for we have to return the
In message <[EMAIL PROTECTED]> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
> ---
> Makefile |6 +++---
> board/{ => freescale}/imx31_litekit/Makefile |0
> board/{ => freescale}/imx31_litekit/config.mk
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
---
Makefile |6 +++---
board/{ => freescale}/imx31_litekit/Makefile |0
board/{ => freescale}/imx31_litekit/config.mk |0
.../{ => freescale}/imx31_litekit/imx31_
In message <[EMAIL PROTECTED]> you wrote:
>
> > I think the average user does not need to now this. He can just run
> the systemn-provided "bootm" command without caring if this is a
> > monolithic pile of unreeadable code, or a wrapper function that
> > sequentially calls out for a l
On Wed, 2008-08-06 at 22:26 +0200, Michal Simek wrote:
> I tested current head on my boards and I have no problem with it.
> Can you post your config part where you have problem?
> And I look at 85xx repo and I haven't found this fix there. The last patch on
> master branch in mine.
>
Hi Michal,
On Aug 6, 2008, at 3:41 PM, Wolfgang Denk wrote:
> In message [EMAIL PROTECTED]> you wrote:
>>
Book-E will need different code for handing IVPR/IVORs than
classic.
>>>
>>> Umm... the exception code itself may be different, but does this
>>> imply
>>> that the code used to copy / re
On Aug 6, 2008, at 3:36 PM, Wolfgang Denk wrote:
> In message <6130E31C-5845-4DCF-
> [EMAIL PROTECTED]> you wrote:
>>
>>> Ooo, that sounds hard. If we are only re-enabling interrupts/usb/
>>> caches it probably is manageable, but my hackles.
>>
>> This is a buyer-beware kinda of situation. Thi
In message <[EMAIL PROTECTED]> you wrote:
>
> >> Book-E will need different code for handing IVPR/IVORs than classic.
> >
> > Umm... the exception code itself may be different, but does this imply
> > that the code used to copy / relocate the exception handlers to low
> > mem must be different, to
Kumar Gala wrote:
>
> On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:
[snip]
>> Having said that, I was thinking and would advocate pushing
>> functionality out of bootm and into other commands, as appropriate.
>> As an example, bootm doesn't need to do *any* fdt stuff, the "fdt"
>> built
In message <[EMAIL PROTECTED]> you wrote:
>
> > Ooo, that sounds hard. If we are only re-enabling interrupts/usb/
> > caches it probably is manageable, but my hackles.
>
> This is a buyer-beware kinda of situation. Think about a case that we
> are booting a kernel at a location of memory tha
On Aug 6, 2008, at 3:17 PM, Wolfgang Denk wrote:
> In message <9D199630-11FA-4028-8EE6-
> [EMAIL PROTECTED]> you wrote:
>>
>>> Good point. Why don't we factor this out and make it common code for
>>> all PPC?
>>
>> Because the relocation is specific to the various interrupt types.
>> Book-E will
On Aug 6, 2008, at 3:26 PM, Wolfgang Denk wrote:
> In message
> <[EMAIL PROTECTED]> you wrote:
>>
>>> Note that you cannot recover / restore after starting to uncompress
>>> the image, because usually you will overwrite the exception vectors.
>>
>> Normally that is true.. however there are some
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
[snip]
>> Aside: verify should be an image verify command, not a env variable flag
>> (see below). This is probably true of most of the current env
>
> We alreay have a verify command. It's called "imls".
>> variables: the re
Hi Peter,
I tested current head on my boards and I have no problem with it.
Can you post your config part where you have problem?
And I look at 85xx repo and I haven't found this fix there. The last patch on
master branch in mine.
Regards,
Michal Simek
> boot_get_ramdisk() should not treat the
In message <[EMAIL PROTECTED]> you wrote:
>
> > Note that you cannot recover / restore after starting to uncompress
> > the image, because usually you will overwrite the exception vectors.
>
> Normally that is true.. however there are some situations that its
> feasible. For example if you are
In message <[EMAIL PROTECTED]> you wrote:
>
> > bootm restore (undo anything prep did, reset state tracking)
>
> Ooo, that sounds hard. If we are only re-enabling interrupts/usb/caches
> it probably is manageable, but my hackles.
ACK. And if we really restore anything, than just interrupts and
On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
>>> Kumar Gala wrote:
here's a rough start at an outline for the bootm script based on
the code (I've only outlined the Linux/PPC boot case its seems
t
In message <[EMAIL PROTECTED]> you wrote:
>
> > Good point. Why don't we factor this out and make it common code for
> > all PPC?
>
> Because the relocation is specific to the various interrupt types.
> Book-E will need different code for handing IVPR/IVORs than classic.
Umm... the exception
On Aug 6, 2008, at 2:41 PM, Wolfgang Denk wrote:
> In message <5E53E387-237D-480E-
> [EMAIL PROTECTED]> you wrote:
>>
>> one idea is having "stages" of bootm handled as sub commands:
>>
>> bootm start
>> bootm prep(disable interrupts, stop usb, disable caches)
> --- Point of no return here
Kumar Gala wrote:
> On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
>
>> Kumar Gala wrote:
>>> here's a rough start at an outline for the bootm script based on
>>> the code (I've only outlined the Linux/PPC boot case its seems the
>>> most complicated). One of the first things we clearly
On Aug 6, 2008, at 2:46 PM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you
> wrote:
>>
>> It's hit me before when I foolishly try to load something at address
>> zero -- why do we put u-boot at the end of RAM, and put up with the
>> relocation weirdness, if not to allow loading thing
In message <[EMAIL PROTECTED]> you wrote:
>
> It's hit me before when I foolishly try to load something at address
> zero -- why do we put u-boot at the end of RAM, and put up with the
> relocation weirdness, if not to allow loading things at zero?
We want to free as much memory as possible. But l
The Sequoia board has two UARTs in "4-pin" mode. This patch modifies the GPIO
configuration to match the schematic, and also sets the sdr0_pfc1 register to
select the corresponding mode for the UARTs.
board/amcc/sequoia/sequoia.c |5 +
include/configs/sequoia.h| 12 ++--
2
SMDK6400 can only boot U-Boot from NAND-flash. This patch adds a nand_spl
driver for it too. The board can also boot from the NOR flash, but due to
hardware limitations it can only address 64KiB on it, which is not enough
for U-Boot. Based on the original sources by Samsung for U-Boot 1.1.6.
Signe
Based on the original S3C64XX NAND driver by Samsung for U-Boot 1.1.6.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
Changes since v5: now it actually works with nand-testing
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c64xx.c | 309 ++
Based on the original S3C64XX UART driver by Samsung for U-Boot 1.1.6.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
drivers/serial/Makefile |1 +
drivers/serial/s3c64xx.c | 197 ++
2 files changed, 198 insertions(+), 0 deletions(-)
Notice: USB on S3C6400 currently works _only_ with switched off MMU. One could
try to enable the MMU, but map addresses 1-to-1, and disable data cache, then
it should work too and we could still profit from instruction cache.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
cpu/arm117
Supporting page-aligned reads doesn't incure any sinificant overhead, just
a small change in the algorithm. Also replace in_8 with readb, since there
is no in_8 on ARM.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
nand_spl/nand_boot.c | 22 +-
1 files chang
Version 6: this time, based on the updated nand-testing branch with the
latest patch from Scott Wood - thanks again, run-tested. Updates since
version 5: restored original bad-block detection in nand_spl/nand_boot.c
with only necessary changes to support non block-aligned images, use the
chipse
Scott Wood wrote:
> On Wed, Aug 06, 2008 at 04:42:51PM +0200, Wolfgang Denk wrote:
>> In message <[EMAIL PROTECTED]> you wrote:
Oops? This is expected and normal behaviour. Did anybody complain
about this?
>
> It's hit me before when I foolishly try to load something at address
> zero --
In message <[EMAIL PROTECTED]> you wrote:
>
> one idea is having "stages" of bootm handled as sub commands:
>
> bootm start
> bootm prep(disable interrupts, stop usb, disable caches)
--- Point of no return here ---
> bootm load_os (decompress OS image)
> bootm load_fdt(relocates fdt to prope
On Wed, Aug 06, 2008 at 04:42:51PM +0200, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > > Oops? This is expected and normal behaviour. Did anybody complain
> > > about this?
It's hit me before when I foolishly try to load something at address
zero -- why do we put u-boo
On Aug 6, 2008, at 1:16 PM, Gerry Emon wrote:
> Can anyone out there help me. I am doing some new development using
> a MPC8349E (Hardware rev 3.1) and using an older version of u-boot
> (1.1.3). I require hooks to the get_timer() API to allow me to
> place timeout restrictions on areas o
On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> here's a rough start at an outline for the bootm script based on
>> the code (I've only outlined the Linux/PPC boot case its seems the
>> most complicated). One of the first things we clearly need is a
>> imload c
> > Wolfgang Denk wrote:
> > > Well, the "version 2" prefix is kind of already taken by
> > > Sascha Hauers alternative implementation.
> > >
> > > Should we go for 2.x.x anyway?
> On Wed, Aug 06, 2008 at 11:47:22AM -0500, Ken Fuchs wrote:
> > May I suggest CC.YY.MM?
> >
> > VERSION =
> > PA
the ePAPR spec has some subtle differences from the current device tree
based boot interface to the powerpc linux kernel. The powerpc linux kernel
currently ignores the differences that ePAPR specifies.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
lib_ppc/bootm.c | 33
if the environment variable 'no_ft_board_setup' is set we skip
doing the ft_board_setup().
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
lib_ppc/bootm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index d141fae..1fce037 100644
-
Can anyone out there help me. I am doing some new development using a MPC8349E
(Hardware rev 3.1) and using an older version of u-boot (1.1.3). I require
hooks to the get_timer() API to allow me to place timeout restrictions on areas
of my code. I have worked my way through the code on to det
On Wed, Aug 06, 2008 at 11:47:22AM -0500, [EMAIL PROTECTED] wrote:
> Wolfgang Denk wrote:
>
> > Well, the "version 2" prefix is kind of already taken by Sascha Hauers
> > alternative implementation.
> >
> > Should we go for 2.x.x anyway?
>
> May I suggest CC.YY.MM?
>
> VERSION =
> PATCHLEVEL =
Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
README |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 0cd01bc..d4456e5 100644
--- a/README
+++ b/README
@@ -98,7 +98,7 @@ Where we come from:
- create ARMBoot project (http://sourceforge.net/pro
Wolfgang Denk wrote:
> Well, the "version 2" prefix is kind of already taken by Sascha Hauers
> alternative implementation.
>
> Should we go for 2.x.x anyway?
May I suggest CC.YY.MM?
VERSION =
PATCHLEVEL =
SUBLEVEL =
EXTRAVERSION = or
So this month's release number would become 20.08.08.
Fathi BOUDRA wrote:
>> Why not just declare a static array?
>
> I tried with a static array but it doesn't give the expected result (a quick
> test with onenand info command returns an empty mtd name), so I used a
> pointer.
Odd... Maybe a relocation issue?
>> It'd be better to use snprintf, e
> Don't cast the return of malloc.
ok.
> Why not just declare a static array?
I tried with a static array but it doesn't give the expected result (a quick
test with onenand info command returns an empty mtd name), so I used a
pointer.
> It'd be better to use snprintf, even if you're pretty su
Jatin Sharma wrote:
> I am running U-Boot version U-Boot 1.3.1-rc1 on my board that has a
> Broadcom network switch. My goal is to initialize this switch at the
> bootloader level and be able to tftpboot a Linux kernel from one of
> the ethernet ports of this switch.
>
> As _I_ understand, there ar
In message <[EMAIL PROTECTED]> you wrote:
>
> > - printk(KERN_INFO "%sOneNAND%s %dMB %sV 16-bit (0x%02x)\n",
> > + sprintf(dev_info, "%sOneNAND%s %dMB %sV 16-bit (0x%02x)",
> >demuxed ? "" : "Muxed ",
> >ddp ? "(DDP)" : "",
> >(16 << density), vcc ? "2.65/3.
In message <[EMAIL PROTECTED]> you wrote:
>
> Theory: Link the switch driver software with the u-boot.bin and flash
> it on the board. Switch driver's entry point would be called somewhere
> in u-boot to initialize it. Size of the u-boot.bin will increase and
> the u-boot partition on the NOR flas
On Wed, Aug 06, 2008 at 10:06:20AM +0200, Fathi BOUDRA wrote:
> -void onenand_print_device_info(int device, int verbose)
> +char * onenand_print_device_info(int device)
No space after unary '*' (here and elsewhere).
> {
> int vcc, demuxed, ddp, density;
> -
> - if (!verbose)
> -
I am running U-Boot version U-Boot 1.3.1-rc1 on my board that has a
Broadcom network switch. My goal is to initialize this switch at the
bootloader level and be able to tftpboot a Linux kernel from one of
the ethernet ports of this switch.
As _I_ understand, there are two ways to initialize the sw
I have been trying to recover from ignorance on my part when I used
Atmel's SAM-BA 2.8 utility to scrub the NAND on my board. Scrubbing
should be more thorough than erasing, right??? Oops. So, I thought that
maybe I could use u-boot (pulled from DataFlash via AT91SAM9G20) to
recover my NAND, but I
On Wednesday 06 August 2008, Steven A. Falco wrote:
> > Ack, we don't want hardware handshake enabled in U-Boot. But if I
> > understand this correctly, then this patch from Steven configures the
> > RTS/CTS lines correctly (they are multiplexed with other signals), so
> > that they *can* be used b
In message <[EMAIL PROTECTED]> you wrote:
>
> There is intent and what the old code did. My feeling is that
> 'autostart = no' means to load the images but not actually jump to the
> new image.
Correct. To be a bit more specific, "load" here means to load the
kernel image to RAM (ove
In message <[EMAIL PROTECTED]> you wrote:
>
> > Oops? This is expected and normal behaviour. Did anybody complain
> > about this?
>
> Real, any reason why? I understand on classic PPC this might be the
> case but I see no reason for it to be so on book-e parts.
Well, one reason might be to ha
In message <[EMAIL PROTECTED]> you wrote:
>
> I've been using as follows:
>
> setenv autostart no
> bootm
>
> bootepapr 0 $bootm_fdtaddr
Now I see where your intentions with the autostart are coming from.
Sorry, this is not the way it is supposed to work, and not the way it
is documented.
> A
Hi Ben,
On Wed, Aug 6, 2008 at 3:22 PM, Ben Warren <[EMAIL PROTECTED]> wrote:
> Hi Magnus,
>
> On Wed, Aug 6, 2008 at 5:19 AM, Magnus Lilja <[EMAIL PROTECTED]> wrote:
>> Add support for NAND and ethernet on the Freescale i.MX31 PDK (a.k.a.
>> 3DS) board.
>>
>> Booting from NAND is not supported ye
On Aug 6, 2008, at 8:52 AM, pugazh mahalingam wrote:
> Hi,
> I'm using MPC8548PC Type N card.
> where can I get the U-Boot code for this board. ?
> i cannot run the other configuration in this board.
> so can you please give the source code to MPC8548PC board.
you should talk to the vendor of th
Hello,
tomydevasia wrote:
>I am currently working u-boot for AT91SAM9260 based board. In this board
> we are using LXT971A as phy rather than davicom dm9161a as in
> AT91SAM9260-EK. We have u-boot-1.1.5 version with AT91SAM9260 support, but
> it is having phy support only for Davicom dm9161a
Hi,
I'm using MPC8548PC Type N card.
where can I get the U-Boot code for this board. ?
i cannot run the other configuration in this board.
so can you please give the source code to MPC8548PC board.
Thanks in advance ..
Regards
Prathap
--
On Tue, 5 Aug 2008, Scott Wood wrote:
> Also, remove the ctrl variable in favor of passing the constants
> directly, and remove redundant (u8) casts.
>
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Tested-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
It works.
Thanks
Guennadi
> ---
> This p
Hi Magnus,
On Wed, Aug 6, 2008 at 5:19 AM, Magnus Lilja <[EMAIL PROTECTED]> wrote:
> Add support for NAND and ethernet on the Freescale i.MX31 PDK (a.k.a.
> 3DS) board.
>
> Booting from NAND is not supported yet so U-boot relies on some other
> initial boot loader to set up SDRAM and clocks and co
On Aug 6, 2008, at 3:33 AM, Wolfgang Denk wrote:
> Dear Bartek,
>
> in message <[EMAIL PROTECTED]> you wrote:
>>
>> The test you're referring to was introduced by commit
>> 75fa002c47171b73fb4c1f2c2fe4d6391c136276 "[new uImage] Respect
>> autostart
>> setting in linux bootm" by Kumar -- he shou
Hans-Christian Egtvedt <[EMAIL PROTECTED]> wrote:
> This patch adds support for the Favr-32 board made by EarthLCD.
>
> This kit, which is also called ezLCD-101 when running with EarthLCD firmware,
> has a 10.4" touch screen LCD panel, 16 MB 32-bit SDRAM, 8 MB parallel flash,
> Ethernet, audio out
Stefan Roese wrote:
> On Friday 01 August 2008, Wolfgang Denk wrote:
>
>> In message <[EMAIL PROTECTED]> you wrote:
>>
>>> I have verified that the Sequoia (440EPx) does not have its UARTs
>>> properly configured. The attached patch corrects this by setting three
>>> bits in SDR0_PFC1 to e
On Aug 6, 2008, at 3:21 AM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]
> > you wrote:
>> Add a boot command that supports the ePAPR client interface on
>> powerpc.
>
> What is the intended use of such a command?
>
> How does it intergrate with with image formats supported by U-Boot
On Wed, Aug 6, 2008 at 7:19 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> A: Because it messes up the order in which people normally read text.
>
> Q: Why is it such a bad thing?
>
> A: Top-posting.
>
> Q: What is the most annoying thing on usenet and in e-mail?
>
>
> Please do NOT top-post/full-
On Aug 6, 2008, at 1:50 AM, Wolfgang Denk wrote:
> In message [EMAIL PROTECTED]> you wrote:
>> Moving the interrupt vectors to low memory can cause issues if the
>> code
>> gets overwritten via some image loading command (tftp, boot*, etc.)
>> and
>> interrupts (like the decrementer are enab
This patch adds support for the Favr-32 board made by EarthLCD.
This kit, which is also called ezLCD-101 when running with EarthLCD firmware,
has a 10.4" touch screen LCD panel, 16 MB 32-bit SDRAM, 8 MB parallel flash,
Ethernet, audio out, USB device, SD-card slot, USART and various other
connecto
On Tuesday 05 August 2008, Guennadi Liakhovetski wrote:
> Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
Applied to next brach of u-boot-cfi-flash repository.
Thanks.
Best regards,
Stefan
=
DENX Software Engineering G
On Thursday 31 July 2008, Rafael Campos wrote:
> Some of the flash memories produced by ATMEL start in read-only mode. We
> need to unprotect it.
> This patch allows the AT49BV6416 to work with cfi_flash memories. Tested
> in the at91rm9200ek board.
>
> Style modifications suggested by Stefan R
Imported from Freescale's Linux NFC driver from the i.MX31 BSP
release 5 (Linux 2.6.22.5) and the i.MX31 PDK BSP (Linux 2.6.24).
The code has been changed to conform (better) with the coding style
in Linux/U-boot. Sections not used by U-boot have been removed.
The driver has been tested on i.MX31
Add support for NAND and ethernet on the Freescale i.MX31 PDK (a.k.a.
3DS) board.
Booting from NAND is not supported yet so U-boot relies on some other
initial boot loader to set up SDRAM and clocks and copying U-boot to SDRAM.
Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
MAKEALL
Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
include/asm-arm/arch-mx31/mx31-regs.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h
b/include/asm-arm/arch-mx31/mx31-regs.h
index 02b7dcb..6fc7606 100644
--- a/include/a
Hi all
This series of patches adds support for the NAND flash controller in the
i.MX31 device and also introduces the Freescale i.MX31 PDK board.
The patches are based on Scott Wood's testing branch of the NAND git tree.
At the moment, the patch series does not add support for booting from
NAND.
This patch adds the reset_timer() function (needed by nand_base.c) and
modifies the get_timer_masked() to work in the same way as the omap24xx
function.
Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
cpu/arm1136/mx31/interrupts.c | 22 ++
1 files changed, 18 insertions(
Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
include/configs/imx31_litekit.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index ec4ed1e..a402007 100644
--- a/include/configs/imx31_litek
Hi,
I am currently working u-boot for AT91SAM9260 based board. In this board
we are using LXT971A as phy rather than davicom dm9161a as in
AT91SAM9260-EK. We have u-boot-1.1.5 version with AT91SAM9260 support, but
it is having phy support only for Davicom dm9161a . So we have changed the
phy
cjjoy1980 wrote:
> I have enabled nfs booting on ppc based embedded board. I had placed my
> kernel and rootfs in tftp directory, and had set the u-boot enivironment
> varialbes as:
>setenv bootfile /image/kernel
>setenv root_path /tftpboot/image
>
> The board was booting with this con
Hello,
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Please do NOT top-post/full-quote. Please read
http://www.netmeister.org/news/learn2quote.html
In message
Hi guys,
I read u-boot 1.3.3 README and searched code generally, I guess the answer
might be sad for me. Anyway, Could anyone double-check this thing?
README mentions that uboot uses some gcc feature, depends on some gcc
implementation. There are many 'inline' found in uboot code, but no
1 - 100 of 110 matches
Mail list logo