On Tuesday, September 14, 2010 01:22:10 Vipin Kumar wrote:
> I wanted to know if there is a generic way to create two
> binaries from the u-boot source both compiled for different
> address ranges. The first initializes the RAM (may be
> something else as well) and the second is the u-boot binary
>
Hi Vipin,
On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote:
> This is about a generic problem which may also be faced
> by other developers. Our SoC has a masked bootrom area
> which copies an image from NOR/NAND memories to an internal
> embedded SRAM. The size of this SRAM is only 8K. Thi
This patch adds basic support for spi mode 0~3 by control gpio bitbang in S5P.
Original name of this patch was "support spi gpio driver by control gpio
bitbang".
But, it had arch-specific features, S5P, so changed to this name.
It uses several gpio pin and emulates spi chipselect signal, clock si
On Tue, Sep 14, 2010 at 4:16 PM, Stefan Roese wrote:
> Hi Vipin,
>
> On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote:
>> This is about a generic problem which may also be faced
>> by other developers. Our SoC has a masked bootrom area
>> which copies an image from NOR/NAND memories to an i
This patch can support s6e63m0 amoled panel. It uses
s5p-spi interface using spi bitbang emulation.
please refer to patch, "S5P: new spi gpio bitbang driver".
Signed-off-by: Donghwa Lee
---
drivers/video/Makefile |1 +
drivers/video/s6e63m0.c | 384 +
This patch fixes a problem in the PPC4xx POST UART driver. This driver
incorrectly used the in/out8() io-accessor functions. This could lead to
problems since these functions don't guarantee execution ordering. This
patch now replaces these functions with the correct ones.
Additionally the driver
This patch changes the PPC4xx UART driver to use the NS16550 struct
instead of macros for the register offsets.
Signed-off-by: Stefan Roese
---
arch/powerpc/cpu/ppc4xx/4xx_uart.c | 170 ++--
1 files changed, 66 insertions(+), 104 deletions(-)
diff --git a/arch/
On 13/09/10 22:04, Ben Gardiner wrote:
> This patch proposes to migrate the davinci_emac driver to using the
> eth_device->write_hwaddr function pointer as suggested by Ben Warren.
>
> All the davinci boards had the behaviour, prior to this patch, of
> sync'ing the environment variable enetaddr wi
Hi Kumar Gala
Thanks for ur kind reply.
Till, I am not clear why the resect vector points different
address(0xefff_fffc).
>From your reply, I understood Text_Base address is 0xeff8_, so the
resetvec address points to 0xefff_fffc.
For all 85xx processor except(MPC8572) the resetvec = 0xff
Hi,
upon revisiting the PPC4xx UART driver, I stumbled (again) over the
CONFIG_SERIAL_SOFTWARE_FIFO feature. As it seems this feature is only
implemented for PPC4xx and is not used in any mainline board ports. Frankly I
never really understood why such a "feature" should be used. So I'm asking
Dear Reinhard,
On Tue, 14 Sep 2010 03:11:50 +0200
Reinhard Meyer wrote:
...
> > This patch consolidates bootcount_{store|load} for ARM by
> > implementing a common version in arch/arm/lib/bootcount.c. This
> > code is now used by all ARM variants that currently have these
> > functions implemente
On 9/14/2010 12:46 PM, Stefan Roese wrote:
Hello Stefan,
> On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote:
>> This is about a generic problem which may also be faced
>> by other developers. Our SoC has a masked bootrom area
>> which copies an image from NOR/NAND memories to an internal
>>
LinkedIn
Simon Polette requested to add you as a connection on LinkedIn:
--
Srinath,
I'd like to add you to my professional network on LinkedIn.
- Simon
Accept invitation from Simon Polette
http://www.linkedin.com/e/-lxcrbf-ge2l6s62-4v/2Xzs6B7
On Tuesday, September 14, 2010 03:38:11 Donghwa Lee wrote:
> This patch adds basic support for spi mode 0~3 by control gpio bitbang in
> S5P. Original name of this patch was "support spi gpio driver by control
> gpio bitbang". But, it had arch-specific features, S5P, so changed to this
> name.
so
Hi Vipin,
On Tuesday 14 September 2010 12:21:41 Vipin Kumar wrote:
> > Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created
> > for platforms booting from NAND with tight restrictions (e.g. 4k image
> > size for inital setup, mostly DDR). General idea here is that 2 images
> > a
On Monday, September 13, 2010 08:55:47 Ben Gardiner wrote:
> On Sat, Sep 11, 2010 at 12:01 AM, Mike Frysinger wrote:
> > On Friday, September 10, 2010 16:10:16 Ben Gardiner wrote:
> >> The current da850evm support in u-boot/master [1] omits any use of
> >> the davinci EMAC. This patch adds basic su
On Tuesday, September 14, 2010 08:40:55 Stefan Roese wrote:
> On Tuesday 14 September 2010 12:21:41 Vipin Kumar wrote:
> > > Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created
> > > for platforms booting from NAND with tight restrictions (e.g. 4k image
> > > size for inital set
Hi Mike,
Thanks for following-up.
On Tue, Sep 14, 2010 at 9:00 AM, Mike Frysinger wrote:
>
> it depends on the URLs. i dont think referring to the mainline git tree is
> useful at all considering that's what they're using if they have this patch in
Yes, I see your point: the mainline tree's UR
Only for Atmel ARM at91 family:
when returnvalue of get_ticks() > 2^32 udelay() never returns
Signed-off-by: Peter Gsellmann
---
arch/arm/cpu/arm926ejs/at91/timer.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/timer.c
b/arch/arm/cpu/
Signed-off-by: Reinhard Meyer
---
arch/arm/cpu/arm926ejs/at91/cpu.c | 32
1 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/cpu.c
b/arch/arm/cpu/arm926ejs/at91/cpu.c
index 141a7d1..087fe95 100644
--- a/arch/arm/cpu/arm
Hi,
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> boun...@lists.denx.de] On Behalf Of Vipin Kumar
> Sent: Tuesday, September 14, 2010 3:52 PM
> To: Stefan Roese
> Cc: u-boot@lists.denx.de; Shiraz HASHIM
> Subject: Re: [U-Boot] Multiple binaries built through u
Patch 1 adds generalisation to spi_flash.c to allow for table driven
probing of JEDEC and NON-JEDEC conformant devices
Patch 2 adds the actual Ramtron support
Patch 2 requires Patch 1 to be applied first.
Signed-off-by: Reinhard Meyer
___
U-Boot maili
JEDEC types
non JEDEC types
Signed-off-by: Reinhard Meyer
---
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/ramtron.c| 321 ++
drivers/mtd/spi/spi_flash.c |8 +
drivers/mtd/spi/spi_flash_internal.h |1 +
4 files chang
for JEDEC devices without and with extension bytes
for non JEDEC devices
Signed-off-by: Reinhard Meyer
---
drivers/mtd/spi/spi_flash.c | 137 +--
1 files changed, 93 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi
Hi Aneesh,
On Tuesday 14 September 2010 15:33:53 V, Aneesh wrote:
> > >> I wanted to know if there is a generic way to create two
> > >> binaries from the u-boot source both compiled for different
> > >> address ranges. The first initializes the RAM (may be
> > >> something else as well) and the s
On Tue, Sep 14, 2010 at 10:51 PM, Stefan Roese wrote:
> Hi Aneesh,
>
> On Tuesday 14 September 2010 15:33:53 V, Aneesh wrote:
>> > >> I wanted to know if there is a generic way to create two
>> > >> binaries from the u-boot source both compiled for different
>> > >> address ranges. The first initi
On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh wrote:
> Hi,
>
> > -Original Message-
> > From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> > boun...@lists.denx.de] On Behalf Of Vipin Kumar
> > Sent: Tuesday, September 14, 2010 3:52 PM
> > To: Stefan Roese
> > Cc: u-boot@lists.denx.de; Shir
Hi Kyungmin,
On Tuesday 14 September 2010 16:18:00 Kyungmin Park wrote:
> >> This looks promising. However, our SPL has to load u-boot from MMC. Is
> >> it OK to keep it under nand_spl directory or should we create
> >> something like 'mmc_spl'?
>
> Good question, It created the mmc_ipl and use i
On Tue, Sep 14, 2010 at 11:22 PM, Vaibhav Bedia wrote:
> On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh wrote:
>
>> Hi,
>>
>> > -Original Message-
>> > From: u-boot-boun...@lists.denx.de [mailto:u-boot-
>> > boun...@lists.denx.de] On Behalf Of Vipin Kumar
>> > Sent: Tuesday, September 14, 201
On Tue, Sep 14, 2010 at 11:26 PM, Stefan Roese wrote:
> Hi Kyungmin,
>
> On Tuesday 14 September 2010 16:18:00 Kyungmin Park wrote:
>> >> This looks promising. However, our SPL has to load u-boot from MMC. Is
>> >> it OK to keep it under nand_spl directory or should we create
>> >> something like
This patch updates the mach-types.h based on the latest linux kernel
Signed-off-by: Thomas Weber
---
arch/arm/include/asm/mach-types.h | 1230 -
1 files changed, 1226 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/inc
On Tuesday, September 14, 2010 10:50:08 Reinhard Meyer wrote:
> for JEDEC devices without and with extension bytes
> for non JEDEC devices
> Signed-off-by: Reinhard Meyer
needs to be a blank line before s-o-b tags and friends
> - * Licensed under the GPL-2 or later.
this is unnecessary noise.
On Tuesday, September 14, 2010 10:50:09 Reinhard Meyer wrote:
> JEDEC types
> non JEDEC types
this changelog is useless ... either make it say something, or just leave it
empty
> +static int ramtron_common(struct spi_flash *flash,
> + u32 offset, size_t len, void *buf, u8 command)
>
On Tuesday, September 14, 2010 10:32:21 Kyungmin Park wrote:
> BootROM code -> Initial Program Loader (runs on OneNAND 1KiB or
> internal RAM) -> u-boot (secondary bootloader).
> IPL configure the DRAM and loads the secondary bootloader, u-boot and jump
> it.
the IPL may or may not handle loading
Dear Stefan Roese,
In message <201009141057.22887...@denx.de> you wrote:
>
> upon revisiting the PPC4xx UART driver, I stumbled (again) over the
> CONFIG_SERIAL_SOFTWARE_FIFO feature. As it seems this feature is only
> implemented for PPC4xx and is not used in any mainline board ports. Frankly
Dear "V, Aneesh",
In message you
wrote:
>
> Presently, we are maintaining a mini bootloader(called x-loader, based
> on u-boot)separately. We want to integrate x-loader with u-boot and
> up-stream the source code.
That would be greatly appreciated.
> This looks promising. However, our SPL ha
Many arm926ejs-based SoCs boot at 0x.
Currently these last 64 KB of flash are wasted just
for a jump to the location where u-boot was flashed.
This commit provides split relocation where the first
part of u-boot is stored from the reset address to the
end of the flash, and the second part i
On 14.09.2010 16:53, Mike Frysinger wrote:
> On Tuesday, September 14, 2010 10:50:08 Reinhard Meyer wrote:
>> for JEDEC devices without and with extension bytes
>> for non JEDEC devices
>> Signed-off-by: Reinhard Meyer
>
> needs to be a blank line before s-o-b tags and friends
>
>> - * Licensed und
On Mon, 13 Sep 2010 21:59:21 -0400
Mike Frysinger wrote:
> On Monday, September 13, 2010 21:17:30 Kim Phillips wrote:
> > [u-boot next]$ ./MAKEALL 83xx
> > awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg
> > > .boards.depend Configuring for ve8313 board...
>
> how abo
Le 14/09/2010 20:25, Albert Aribaud a écrit :
>
Sorry, the patch posted is against master, not next, and thus does not
take Heiko's relocation work. I'm rebasing / updating the patch and will
provide a V2 of it that will.
Amicalement,
--
Albert.
___
On Tuesday, September 14, 2010 14:29:30 Reinhard Meyer wrote:
> On 14.09.2010 16:53, Mike Frysinger wrote:
> > On Tuesday, September 14, 2010 10:50:08 Reinhard Meyer wrote:
> >> for JEDEC devices without and with extension bytes
> >> for non JEDEC devices
> >> Signed-off-by: Reinhard Meyer
> >
> >
On Tue, 14 Sep 2010 01:43:40 -0700
MArunKumar wrote:
>
> Hi Kumar Gala
>
> Thanks for ur kind reply.
>
> Till, I am not clear why the resect vector points different
> address(0xefff_fffc).
>
> From your reply, I understood Text_Base address is 0xeff8_, so the
> resetvec address points to
On Tuesday, September 14, 2010 14:41:16 Kim Phillips wrote:
> On Mon, 13 Sep 2010 21:59:21 -0400 Mike Frysinger wrote:
> > On Monday, September 13, 2010 21:17:30 Kim Phillips wrote:
> > > [u-boot next]$ ./MAKEALL 83xx
> > > awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }'
> > > boar
[u-boot next]$ ./MAKEALL 83xx
awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg >
.boards.depend
Configuring for ve8313 board...
Signed-off-by: Kim Phillips
---
applies to u-boot.git's next branch.
MAKEALL |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d
On Tuesday, September 14, 2010 15:48:16 Kim Phillips wrote:
> [u-boot next]$ ./MAKEALL 83xx
> awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg
> > .boards.depend Configuring for ve8313 board...
>
> Signed-off-by: Kim Phillips
Acked-by: Mike Frysinger
-mike
signature
On 2010/09/14 8:47 PM, Albert ARIBAUD wrote:
> Le 14/09/2010 20:25, Albert Aribaud a écrit :
>>
>
> Sorry, the patch posted is against master, not next, and thus does not
> take Heiko's relocation work. I'm rebasing / updating the patch and will
> provide a V2 of it that will.
>
> Amicalement,
This patch adds support for setting PCIE clocks in cpu_init.c by
providing CONFIG_SYS_SCCR_PCIEXP{1,2} in configuration.
Signed-off-by: Ilya Yanok
---
arch/powerpc/cpu/mpc83xx/cpu_init.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx
This patch adds defines to set supported fields in System I/O
Configuration Registers High and Low on Freescale MPC8308 CPU.
Signed-off-by: Ilya Yanok
---
include/mpc83xx.h | 48
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/in
MPC8308 has only one PCIE host controller so we want it to compile
without CONFIG_SYS_PCIE2_CFG_{BASE,SIZE} defined.
Signed-off-by: Ilya Yanok
---
arch/powerpc/cpu/mpc83xx/pcie.c | 47 --
1 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/arch/
This patch cleans up the Freescale MPC8308RDB Development board support.
Things fixed:
- Removed unused PCIE2 definitions from configuration
- SICR{L,H} defines used for System I/O Configuration Registers values
instead of hardcoding
- CONFIG_SYS_SCCR_PCIEXP1CM used to enable PCIE clock inste
This patch provides support for MPC8308 P1M board with the following
set of features:
Dual UART is supported
NOR flash is supported
Both TSEC Ethernet controllers are supported
PCI Express initialization is supported
Both I2C controllers are supported
Signed-off-by: Ilya Yanok
---
Kim's com
Dear Mike Frysinger,
In message <201009141525.05345.vap...@gentoo.org> you wrote:
>
> instead of silencing a somewhat complicated command that could break the
> build
> system if it goes wrong, use the mechanisms already in place if you want nice
> & concise output -- the --silent option to mak
This change lays the groundwork for the BOOTFLAG_* flags being removed.
This change has the small affect of delaying 100ms on PCI initialization
after a warm boot as opposed to the optimal 1ms on some boards.
Signed-off-by: Peter Tyser
CC: kim.phill...@freescale.com
---
arch/powerpc/cpu/mpc83xx
Previously the _warm_start label was used as an entry point. These 2
entry points should be functionally identical after the removal of the
BOOTFLAG_WARM define.
Signed-off-by: Peter Tyser
---
board/ppmc7xx/ppmc7xx.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a
This puts the board info struct in a known state and allows the removal
of other code which initialized board info fields to 0.
Signed-off-by: Peter Tyser
---
arch/powerpc/lib/board.c | 17 +
1 files changed, 1 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/lib/board
No boards utilize the warm reset entry point, so remove it.
Signed-off-by: Peter Tyser
---
arch/powerpc/cpu/74xx_7xx/start.S | 16 +---
arch/powerpc/cpu/mpc512x/start.S |3 ---
arch/powerpc/cpu/mpc5xx/start.S | 16 ++--
arch/powerpc/cpu/mpc5xxx/start.S | 17
On Tuesday, September 14, 2010 18:04:29 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > instead of silencing a somewhat complicated command that could break the
> > build system if it goes wrong, use the mechanisms already in place if
> > you want nice & concise output -- the --silent option to ma
Hi, all
I'm a newbie to u-boot.
I have one question:
I saw "Loading init Ramdisk from Legacy Image at 8200..." in the boot log.
So, what and why is "Legacy Image"? and what is not a legacy image?
Regards,
huahua
___
U-Boot mailing list
U-Bo
help subscribe ___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Tuesday, September 14, 2010 20:48:11 Mike Frysinger wrote:
> On Tuesday, September 14, 2010 03:38:11 Donghwa Lee wrote:
>> This patch adds basic support for spi mode 0~3 by control gpio bitbang in
>> S5P. Original name of this patch was "support spi gpio driver by control
>> gpio bitbang". But,
Le 14/09/2010 22:28, Rogan Dawes a écrit :
> On 2010/09/14 8:47 PM, Albert ARIBAUD wrote:
>> Le 14/09/2010 20:25, Albert Aribaud a écrit :
>>>
>>
>> Sorry, the patch posted is against master, not next, and thus does not
>> take Heiko's relocation work. I'm rebasing / updating the patch and will
>>
Dear =?gbk?B?IkJhaSxjaHVuIiA=?=,
In message <391830493.89.1284520552700.javamail.r...@bj-mail08.pku.edu.cn> you
wrote:
>
> I saw "Loading init Ramdisk from Legacy Image at 8200..." in the boot
> log.
> So, what and why is "Legacy Image"? and what is not a legacy image?
A "legacy image" is
Dear Albert ARIBAUD,
In message <4c905f6d.7010...@free.fr> you wrote:
>
> Both encodings are present in u-boot. I figure UTF-8 seems a better
> choice, but if there is a coding rule about encodings, I'll happily
> follow it, of course.
So far we've been using ISO8859-1
Best regards,
Wolfgang De
63 matches
Mail list logo
