Hi,
Has anyone worked with MSystems (SanDisk) mDoc H3 in u-boot as a boot
device?
Will appreciate any kind of help in that matter.
Micha
-
This SF.net email is sponsored by: Microsoft
Defy all challenge
On 20:49 Tue 29 Jan , Stelian Pop wrote:
> +
> + /* Unlock EMAC, 3 0 2 1 sequence */
> +#define MP_BLOCK_3_BASE 0xFDF0
> +#define MP_MAC_KEY0 0x5969cb2a
> +#define MP_MAC_KEY1 0xb4a1872e
> +#define MP_MAC_KEY2 0x05683fbc
> +#define MP_MAC_KEY3 0x3634fba4
> +#define UNLOCK_MAC
On 20:49 Tue 29 Jan , Stelian Pop wrote:
> +#define AT91C_SMC_PS (0x3 << 28) /* Page Size */
> +#define AT91C_SMC_PS_SIZE_FOUR_BYTES(0x0 << 28)
> +#define AT91C_SMC_PS_SIZE_EIGHT_BYTES (0x1 << 28)
^
Not needed space
Please Remove it
Hi,
Sorry for the late reply. was out of connection from the e-world for
some time.
At present, in the file u-boot-1.3.1/common/cmd_bdinfo.c,
(CONFIG_NIOS2) /* Nios-II */
at line 170
(CONFIG_MICROBLAZE) /* ! PPC, which leaves Microblaze */
at line 197
(CONFIG_M68K) /* M68K */
at line 239
for
Hi all,
I am having problem running the "hello_world" examples that comes with
u-boot on ARM926 board.
Board: ARM926 (AB) application baseboard
Tools: CodeSourcery (arm-none-linux-gnueabi-)
I manage to build u-boot successfully as follow
1. make versatileab_config CROSS_COMPILE=arm-none
On Wednesday 30 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > if you look at any of the forked repos of the main u-boot repo, the URL
> > is> incorrect ... for example, this page:
> > http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-blackfin.git;a=su>
> > m
In message <[EMAIL PROTECTED]> you wrote:
>
> I've already read the documents that you have referenced before posting my
> first message. I had already gotten hello_world to run in u-boot without
> problems (by using the go command), so that is not an issue.
Well, that's the documented way to sta
In message <[EMAIL PROTECTED]> you wrote:
>
> > I proposed this patch for a long time, but it was rejected by Wolfgang.
>
> One solution to that problem is to have someone who maintains a separate
> tree for uboot which does have the feature in. Then it becomes a matter
> of community choice whet
In message <[EMAIL PROTECTED]> you wrote:
>
> Regardless of previous experiences, just remember to give "git-am -3" a
> try once git-am without it fails.
Actually I think you should *always* use
git-am -3 -i -u --whitespace=strip
[OK, the "-u" is default today, but who knows which versi
In message <[EMAIL PROTECTED]> you wrote:
>
> I proposed this patch for a long time, but it was rejected by Wolfgang.
Either you did it differently, or I changed my mind.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Of
In message <[EMAIL PROTECTED]> you wrote:
>
> > You mean the current dataflash implementation uses DMA? Which part of
> > the code is this?
...
>
> Not sure as I do not have a source tree in front of me,
> but if I remember correctly, it was in the board specific
> "at45.c" which then was split i
In message <[EMAIL PROTECTED]> you wrote:
>
> From: Uwe Kleine-K=F6nig <[EMAIL PROTECTED]>
>
> make the machid configurable via the environment
>
> If the variable "machid" exists, let do_bootm_linux use that instead of
> bd->bi_arch_number.
>
> Signed-off-by: Uwe Kleine-K=F6nig <[EMAIL PROTECTE
Dear Hiroshi Ito,
in message <[EMAIL PROTECTED]> you wrote:
>
> U-boot NFS command do not retry to send a command again.
> so, when the packet is lost, It will cause timeout.
>
> with this patch, it should fix.
> but this is very old code. so, I don't know, it can applys to current one.
We'll m
In message <[EMAIL PROTECTED]> you wrote:
>
> if you look at any of the forked repos of the main u-boot repo, the URL is>
> incorrect ... for example, this page:
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-blackfin.git;a=su> mmary
> says that the URL to clone is:
> git://www.denx.de/g
Detlev Zundel wrote:
> Hi Stefan,
>
>> Hi Matthias,
>>
>> On Friday 28 December 2007, Matthias Fuchs wrote:
>>> This patch adds the first files for the new esd PMC440 boards.
>>> The next two patches will complete the PMC440 board support.
>>>
>>> Signed-off-by: Matthias Fuchs <[EMAIL PROTECTED]>
On Jan 30, 2008 4:30 PM, Shinya Kuribayashi <[EMAIL PROTECTED]> wrote:
> Current DMA or SPI driver breaks MIPS builds.
>
> example:
> $ make gth2_config
> $ make CROSS_COMPILE=mips-linux-
>
> leads to ...
>
> make[1]: Entering directory `/home/skuribay/devel/u-boot.git/drivers/dma'
> mips-linux-gcc
From: TsiChungLiew <[EMAIL PROTECTED]>
Signed-off-by: James Mahan <[EMAIL PROTECTED]>
Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]>
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 0f6cc59..30fda62 100644
--- a/Makefile
+++ b/Make
When we go to 36-bit physical addresses we need to keep the concept of
the physical CCSRBAR address seperate from the virtual one.
For the majority of boards CFG_CCSBAR_PHYS == CFG_CCSRBAR
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
This is in the mpc85xx branch of my git tree.
- k
boar
Current DMA or SPI driver breaks MIPS builds.
example:
$ make gth2_config
$ make CROSS_COMPILE=mips-linux-
leads to ...
make[1]: Entering directory `/home/skuribay/devel/u-boot.git/drivers/dma'
mips-linux-gcc -g -Os -D__KERNEL__ -DTEXT_BASE=0x9000
-I/home/skuribay/devel/u-boot.git/inclu
On Tue, Jan 29, 2008 at 08:22:20AM +, Peter Pearse wrote:
> I get one warning:-
>
> cmd_jffs2.c:144:2: warning: #warning "MTDPARTS_DEFAULT not defined!"
>
> Your patch removed
>
> #define MTDPARTS_DEFAULT
> "mtdparts=omapflash.0:128k(uboot),64k(env),64k(r_env),16256k(data1),-(data2)
>
Vlad,
Thanks. I will apply the patch.
Regards,
TsiChung
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
__
From: TsiChungLiew <[EMAIL PROTECTED]>
Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]>
---
cpu/mcf52x2/interrupts.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu/mcf52x2/interrupts.c b/cpu/mcf52x2/interrupts.c
index 2ccbde5..9167cec 100644
--- a/cpu/mcf52x2/interr
Changes to match 5121 device tree going mainline in 2.6.25.
Change OF_SOC from "soc5121" to plain "soc".
Remove unneeded "ref-frequency" fixups.
Remove "address" enetaddr fixup.
Add bus-frequency fixup for old OF_SOC so old
kernels with old device trees will work with new
u-boot with 66MHz IPS cl
Recommended frequency is 66MHz
Change divider from 4 to 3.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
include/mpc512x.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/mpc512x.h b/include/mpc512x.h
index d1c6fb2..b51cf78 100644
--- a/include/mpc512x.h
+++
Wolfgang,
Thank you for your reply.
I've already read the documents that you have referenced before posting my
first message. I had already gotten hello_world to run in u-boot without
problems (by using the go command), so that is not an issue.
My original question was - is it possible to boot
Hi,
I'm trying to rationalize some very common I2C code and came across the
following:
Every controller except cpu/mpc8xx implements functions like this:
---
uchar i2c_reg_read(uchar i2c_addr, uchar reg)
{
uchar buf;
i2c_read(i2c_addr, reg, 1, &buf, 1);
return buf;
}
On Wed, Jan 30, 2008 at 10:33:46AM +0100, Ulf Samuelsson wrote:
> Nicolas Pitre wrote:
> > > But does U-Boot properly provide machine information to the kernel these
> > > days? I have been and still being burned by U-Boot hardcoding the
> > > _wrong_ machine ID, and therefore custom built kernels
On Tue, Jan 29, 2008 at 07:12:10PM -0500, Mike Frysinger wrote:
> On Tuesday 29 January 2008, Wolfgang Denk wrote:
> > In message <[EMAIL PROTECTED]> you wrote:
> > > unfortunately, using weak symbols and overriding elsewhere doesnt look
> > > like it's possible currently due to the way ld searches
Hi,
[EMAIL PROTECTED] wrote on Wednesday, January
30, 2008 2:56 PM:
> Hi!
> Having problem with the sprintf function, I did the exporting and
> updating
> of the files accordantly to the README.standalone. The standalone
> application seems to compile without error. But once I do the go
> 40004
[EMAIL PROTECTED] wrote:
> hello,
>
> the I2C interface is on hostbridge(Tsi109).
>
> thank you.
>
I assume you're using the tsi108 driver. Please try applying the
following untested patch:
diff --git a/drivers/i2c/tsi108_i2c.c b/drivers/i2c/tsi108_i2c.c
index d6736b0..d337c1f 100644
--- a/drive
Hi Detlev,
On Wednesday 30 January 2008, Detlev Zundel wrote:
> > IIRC, I didn't even try to apply this version of the patch. I tried to
> > review it and failed because the patch was "unreadable" for me.
>
> Hm, then I am not sure what you meant by this passage from your mail:
> > > This option y
hello,
the I2C interface is on hostbridge(Tsi109).
thank you.
- Original Message -
From: "Ben Warren" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, January 30, 2008 10:48 PM
Subject: Re: [U-Boot-Users] errors in using DS1337
> [EMAIL PROTECTED] wrote:
>> hello,
>>
>>
Harald
Your patch
ARM: arm920t: Allow use of 'gd' pointer from IRQ
is available for test from
git://linux-arm.org/u-boot-armdev.git#071219_s3c24_gd
Please confirm that the code builds, and runs on the target board(s)
Just in case you weren't aware, the gd pointer will not be available in FIQ
Harald
Your patch
ARM: s3c24xx: Multiple serial port support
is available for test from
git://linux-arm.org/u-boot-armdev.git#071219_s3c24_serial
Please confirm that the code builds, and runs on the target board(s)
Regards
Peter
---
On Wed, 30 Jan 2008, Ulf Samuelsson wrote:
> Nicolas Pitre wrote:
> > > But does U-Boot properly provide machine information to the kernel these
> > > days? I have been and still being burned by U-Boot hardcoding the
> > > _wrong_ machine ID, and therefore custom built kernels from k.o simply
> >
[EMAIL PROTECTED] wrote:
> hello,
>
> I am porting on a PowerPC (MPC7448) platform.
>
OK, what type of southbridge are you using (and ultimately which I2C
controller)?
regards,
Ben
-
This SF.net email is sponsored by: Micros
hello,
I am porting on a PowerPC (MPC7448) platform.
thank you.
>>
> It would help to know what platform you're building for. The functions
> mentioned are prototyped in 'i2c.h', but don't appear in all I2C
> drivers (I'm thinking of the ARM ones that are in drivers/i2c). If
> you're usin
Hi Stefan,
> IIRC, I didn't even try to apply this version of the patch. I tried to review
> it and failed because the patch was "unreadable" for me.
Hm, then I am not sure what you meant by this passage from your mail:
> > This option you used to make the patches smaller (find-copies or
> > so
Hi lxg,
[EMAIL PROTECTED] wrote:
> hello,
>
> when I choose to use DS1337, I add definitions in header file:
>
> #define CONFIG_RTC_DS1337
> #define CFG_I2C_RTC_ADDR0x68
> but, during making process, error appears:
>
> rtc/librtc.a(ds1337.o): in function 'rtc_read':
> .../rtc/ds1337.c: 172: un
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> >> ==> This is not how the dataflash support is implemented in U-Boot today.
>> >> Current implementation is using DMA.
>> >
>> > Note that you are referring to code that is not part of the public
>> > U-Boot tree, and that (as is) will
Nicolas Pitre wrote:
> > But does U-Boot properly provide machine information to the kernel these
> > days? I have been and still being burned by U-Boot hardcoding the
> > _wrong_ machine ID, and therefore custom built kernels from k.o simply
> > won't boot on those boards without hacking the kern
Hi!
Having problem with the sprintf function, I did the exporting and updating
of the files accordantly to the README.standalone. The standalone
application seems to compile without error. But once I do the go 40004 I get
Alignment Exception and the board resets. If I remove the sprintf line
every
Hi Detlev,
On Wednesday 30 January 2008, Detlev Zundel wrote:
> > This option you used to make the patches smaller (find-copies or
> > something like this) really makes reviewing not easy. And additionally
> > the patch doesn't apply anymore, since the reference (sequoia) has
> > changed in my non
Hi Stefan,
> Hi Matthias,
>
> On Friday 28 December 2007, Matthias Fuchs wrote:
>> This patch adds the first files for the new esd PMC440 boards.
>> The next two patches will complete the PMC440 board support.
>>
>> Signed-off-by: Matthias Fuchs <[EMAIL PROTECTED]>
>> ---
>> board/{amcc/sequoia =
On Tuesday 29 January 2008, Mike Frysinger wrote:
> On Tuesday 29 January 2008, Ulf Samuelsson wrote:
> > ==> And this is not a good approach, you want the S/W to use the
> > first 256 kB to store initial boot, U-boot and environment.
> > The AT91SAM9 chips will use the first 8 kB s
On Wednesday 30 January 2008, Rafal Jaworowski wrote:
> Hi Mike,
>
> > It isn't generally save to execute applications outside of U-Boot with
> > caches enabled due to the way the Blackfin processor handles caches
> > (requires software assistance). This patch disables caches before
> > booting an
hello,
when I choose to use DS1337, I add definitions in header file:
#define CONFIG_RTC_DS1337
#define CFG_I2C_RTC_ADDR0x68
but, during making process, error appears:
rtc/librtc.a(ds1337.o): in function 'rtc_read':
.../rtc/ds1337.c: 172: undefined reference to 'i2c_reg_read'
rtc/librtc.
In message <[EMAIL PROTECTED]> you wrote:
>
> >> ==> This is not how the dataflash support is implemented in U-Boot today.
> >> Current implementation is using DMA.
> >
> > Note that you are referring to code that is not part of the public
> > U-Boot tree, and that (as is) will never be
Hi Mike,
> It isn't generally save to execute applications outside of U-Boot with caches
> enabled due to the way the Blackfin processor handles caches (requires
> software assistance). This patch disables caches before booting an ELF or
> just booting raw code. The previous discussion on the pa
In message <[EMAIL PROTECTED]> you wrote:
>
> So what are the steps to get u-boot to boot the hello_world example? I'm
> evaluating the PowerPC 440-based AMCC Yosemite board. This is what I have
> done:
Please RTFM.
> I'm a complete newbie to u-boot and I've tried to find discussions online
> an
Hello Nicolas,
Nicolas Pitre wrote:
> > But does U-Boot properly provide machine information to the kernel these
> > days? I have been and still being burned by U-Boot hardcoding the
> > _wrong_ machine ID, and therefore custom built kernels from k.o simply
> > won't boot on those boards without
> -Original Message-
> From: Stelian Pop [mailto:[EMAIL PROTECTED]
> Sent: 29 January 2008 19:57
> To: Peter Pearse
> Subject: Re: [U-Boot-Users] [PATCH ARM 0/5] AT91CAP9 support
>
> Hi Peter,
>
> > This series of patches adds support for Atmel's AT91CAP9
> Customizable
> > Microcont
52 matches
Mail list logo