>> > > A follow up question. With this method, the total image size
>> > > (uncompressed) is limited to the 4MB (the link address of
>> the boot
>> > > wrapper)?
>> >
>> > No.
>>
>> Yes, unless you change the link address, or provide a
>> vmlinux_alloc callback (which currently only happens on true
The current documentation for the "scrub" option implies it takes no
options at all. This can be annoying when you only want to scrub a
few blocks and not an entire device. Good thing the code already
supports this though since it takes the same arguments as the "erase"
option. Inform people!
S
> -Original Message-
> From:
> linuxppc-dev-bounces+tiejun.chen=windriver@lists.ozlabs.or
> g
> [mailto:linuxppc-dev-bounces+tiejun.chen=windriver@lists.o
zlabs.org] On Behalf Of Scott Wood
> Sent: Wednesday, September 22, 2010 1:53 AM
> To: Chen, Tiejun
> Cc: ppcdev; uboot
> Subj
Signed-off-by: Mike Frysinger
---
arch/blackfin/lib/board.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index 7649f9a..02a5ee9 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -346,7 +346,
Many people like the current nand_init() behavior where it is always
initialized during boot and the flash size shown, but there are cases
where we are willing to forgo this niceness for speed/functionality.
So rather than change the default, introduce a delayed config option
people may enable. Th
Hello My Dear,
How are you? Hope you are fine? Well, I don't know how to start...
well, am Miss Precious Boko, I am single and never been married. i will
like to know you more and we can exchange photo and know each other more
thanks and hoping to hear from you soon___
Anatolij Gustschin wrote:
>> Also, I thought it would be better to provide some sort of completeness for
>> the
>> > bits I am using.
> We do not add unused code.
Well, I don't see how macros are "unused code", but I'll delete those lines.
>>> > > CONFIG_VIDEO definition should depend on CONFIG_
On Tue, 21 Sep 2010 17:00:19 -0500
Timur Tabi wrote:
> Anatolij Gustschin wrote:
>
> >> +#define AD_BYTE_F 0x1000
> >> +#define AD_ALPHA_C_MASK 0x0E00
> >> +#define AD_ALPHA_C_SHIFT 25
> >> +#define AD_BLUE_C_MASK0x0180
> >> +#define AD_BLUE_C_SHIFT
Dear Wolfgang,
The following changes since commit d70d8ccc200db8c16a6654cb726c3d74b6640b32:
Kim Phillips (1):
silence config step commands display during MAKEALL builds
are available in the git repository at:
git://git.denx.de/u-boot-video.git next
Timur Tabi (3):
logos: add F
Dear Wolfgang,
On Sat, 18 Sep 2010 23:26:30 +0200
Wolfgang Denk wrote:
...
> In message <20100916005042.62575...@wker> you wrote:
> > Dear Wolfgang,
> >
> > The following changes since commit a12555c02d716f62aa1ec4764cf1c42bfeecf07d:
> > Wolfgang Denk (1):
> > Merge branch 'master' of
The following changes since commit 800eb09641ae67c707b65acff112684a954b7f44:
POST cleanup. (2010-09-21 21:39:31 +0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git master
Mike Frysinger (2):
Blackfin: update some missed board config.mk files
B
Anatolij Gustschin wrote:
>> +#define AD_BYTE_F 0x1000
>> +#define AD_ALPHA_C_MASK 0x0E00
>> +#define AD_ALPHA_C_SHIFT25
>> +#define AD_BLUE_C_MASK 0x0180
>> +#define AD_BLUE_C_SHIFT 23
>> +#define AD_GREEN_C_MASK 0x006
Hi Timur,
On Thu, 2 Sep 2010 15:35:19 -0500
Timur Tabi wrote:
...
> +#include
> +#include
> +#include
> +
> +#ifdef CONFIG_FSL_DIU_FB
Please drop the #ifdef above. Conditional compilation is
already handled by Makefile.
...
> +#define PX_BRDCFG1_DDCEN 0x10
This one is not used, please d
Hi Timur,
On Tue, 31 Aug 2010 19:56:43 -0500
Timur Tabi wrote:
> The Freescale MPC8610 and MPC5121 DIU code had re-implement two features that
> already
> existed in U-Boot: bitmap drawing and top-of-screen logo (CONFIG_VIDEO_LOGO).
> So delete the 8610-specific code and use the built-in featur
Wolfgang,
to be honest, it`s not my problem that some people on the net seem to
be on a personal crusade to tell other people how to post to mailinglists
or how to write email.
My life does not depend on u-boot. I did not only ask for help, but i also
offered help (giving valuable end-user inpu
Dear Kim Phillips,
In message <20100914144816.177602d5.kim.phill...@freescale.com> you 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
> ---
Dear Matthias Weisser,
In message <1285076264-13219-1-git-send-email-weiss...@arcor.de> you wrote:
> This patch modifies jadecpu board so that it is usable
> with the relocation patches by Heiko Schocher
>
> Signed-off-by: Matthias Weisser
> ---
> board/syteco/jadecpu/config.mk |2 +-
> boa
Dear Michael Zaidman,
In message
you wrote:
> - Revives POST for blackfin arch;
> - Removes redundant code:
> arch/blackfin/lib/post.c
> arch/powerpc/cpu/ppc4xx/commproc.c
> arch/powerpc/cpu/mpc512x/common.c
> - fixes up the post_word_{load|store} usage.
>
> Signed-off-by: Micha
Dear Michael Zaidman,
In message you
wrote:
>
> > check if all your relevant patches have been included.
>
> I rebased against the "master" and resubmitted the POST Cleanup patch
> (http://lists.denx.de/pipermail/u-boot/2010-September/077467.html) as
> was promised in
> http://lists.denx.de/pi
Dear Mike Frysinger,
In message <1280425243-25290-1-git-send-email-vap...@gentoo.org> you wrote:
> Rather than using a custom "Usage:", use the common cmd_usage() function,
> and tail into it now that it returns 1 for us.
>
> Signed-off-by: Mike Frysinger
> ---
> v2
> - tail into cmd_usage
Dear Mike Frysinger,
In message <201009201447.34016.vap...@gentoo.org> you wrote:
>
> > Please help testing
>
> Blackfin looks sane
Thanks.
> > check if all your relevant patches have been included.
>
> could you merge this change:
> 29.07.2010[PATCH v2] cmd_mmc: use common usage function
Signed-off-by: Albert Aribaud
---
board/LaCie/edminiv2/config.mk |4 +++-
include/configs/edminiv2.h |6 ++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/board/LaCie/edminiv2/config.mk b/board/LaCie/edminiv2/config.mk
index 3dec1aa..b4845ad 100644
--- a/board/LaC
Signed-off-by: Albert Aribaud
---
Device address window mapping code would not run from
FLASH due to cutting access to BOOTCS. Fixed by reordering
code.
Timer initialization would write globals, thus would not
run correctly from FLASH. Fixed by moving the writes to a
later phase in RAM.
arch/a
Dear Mike Frysinger,
In message <1285007778-22418-1-git-send-email-vap...@gentoo.org> you wrote:
> If working out of a custom git tree that lacks annotated tags, the
> 'git describe' operation spews "fatal: cannot describe" errors all
> over the place. So add some fallback code in case the best n
On Tue, 21 Sep 2010 03:03:22 +0200
"Chen, Tiejun" wrote:
> > -Original Message-
> > From: Shawn Jin [mailto:shawnx...@gmail.com]
> > Sent: Tuesday, September 21, 2010 1:53 AM
> > To: Chen, Tiejun
> > Cc: ppcdev; uboot
> > Subject: Re: cuImage and multi image?
> >
> > >> I have a cuImage
This patch removes the completely unused CONFIG_SERIAL_SOFTWARE_FIFO
feature from U-Boot. It has only been implemented for PPC4xx and was not
used at all. So let's remove it and make the code smaller and cleaner.
Signed-off-by: Stefan Roese
Acked-by: Detlev Zundel
---
v2: Rebased with patches to
Dear Reinhard Meyer,
In message <4c98a78d.7070...@emk-elektronik.de> you wrote:
>
> What bothers me really here is the huge increase in code size.
As has been pointed out by others, there are several factors that
contribute to that code.
> And, on almost all AT91 systems booting will be through
Dear Albert ARIBAUD,
In message <4c98ba84.9040...@free.fr> you wrote:
>
> > It should be always possible to #define relocation off!
>
> On arm926ejs this is controlled by CONFIG_SKIP_LOWLEVEL_INIT and
> CONFIG_SKIP_RELOCATE_UBOOT. For instance, openrd_base, a kirkwood board,
> always skips lowleve
Dear Reinhard Meyer,
In message <4c98bec7.9090...@emk-elektronik.de> you wrote:
>
> should be switchable OFF by a configuration option. Who does need that
> relocation in the first place? For years ARM did work without it; why now
> blowing up the code?
Maintenancewise, the relocation is needed t
This patch changes the behaviour of the fdt_fixup_nor_flash_node()
function. Now it doesn't patch the size of the "reg" property with the
chip-select size, but with the size returned from the new function
flash_get_bank_size(). This function will return per weak default the
flash size of the bank (
Some news to my problem.
I found the source of the problem :
The flags as explicited in uBoot 1.3.4 induces some problem. I had to undef the
HW_ECC_4BIT flag since when using it the oob is overwritten.
Since it looks at the oob to determine if a block is bad there was a problem.
The unknown here
Stefan Roese schrieb:
> Please note that this increase is not only because of the new ARM relocation
> support, but the environment rework done by Wolfgang:
Yes, that, too. About 5.5k
next w/o relocation (#define CONFIG_SYS_ARM_WITHOUT_RELOC)
and w/o cache (#define CONFIG_SYS_NO_[DI]CACHE): 2294
On Sat, Sep 18, 2010 at 3:49 PM, Wolfgang Denk wrote:
> Dear Lei Wen,
>
> In message you
> wrote:
>>
>> How about merge this patch? :-)
>
> I will wait for a pull request from the responsible custodian.
>
> Maybe you should have put him on cc: ... (done now).
>
I pinged Andy about some mmc pat
Hi Reinhard,
On Tuesday 21 September 2010 14:39:41 Reinhard Meyer wrote:
> Rebasing my current TOP9000 port on u-boot/next compiles
> after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR.
> Code size increased heavyly from 223592 to 245544.
Please note that this increase is not only b
Reinhard Meyer schrieb:
> Therefore I strongly suggest that all extras (PIC) needed solely for
> relocation
> should be switchable OFF by a configuration option. Who does need that
> relocation in the first place? For years ARM did work without it; why now
> blowing up the code?
Sorry, to be prec
Dear Albert ARIBAUD,
> Le 21/09/2010 14:39, Reinhard Meyer a écrit :
>> Rebasing my current TOP9000 port on u-boot/next compiles
>> after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR.
>> Code size increased heavyly from 223592 to 245544.
>>
>> And U-Boot crashes instantly (I know ther
Le 21/09/2010 14:39, Reinhard Meyer a écrit :
> Just to report on preliminary findings I had:
>
> Rebasing my current TOP9000 port on u-boot/master compiles
> and works fine.
> Code size increased moderately from 223592 to 223976.
>
> Rebasing my current TOP9000 port on u-boot/next compiles
> after
Hi Mike,
On Mon, Sep 20, 2010 at 10:52 PM, Mike Frysinger wrote:
> On Tuesday, September 21, 2010 01:21:46 Reinhard Meyer wrote:
> > > On Monday, September 20, 2010 17:44:38 Mike Frysinger wrote:
> > >> finally got around to testing this. seems like the init needs some
> > >> work. if i power o
This patch modifies jadecpu board so that it is usable
with the relocation patches by Heiko Schocher
Signed-off-by: Matthias Weisser
---
board/syteco/jadecpu/config.mk |2 +-
board/syteco/jadecpu/jadecpu.c | 11 +--
include/configs/jadecpu.h |3 +++
3 files changed, 13 ins
Just to report on preliminary findings I had:
Rebasing my current TOP9000 port on u-boot/master compiles
and works fine.
Code size increased moderately from 223592 to 223976.
Rebasing my current TOP9000 port on u-boot/next compiles
after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR.
Dear Wolfgang Denk,
> In message <4c98536c.6010...@emk-elektronik.de> you wrote:
>> For me it seems useful to keep both functions and have ticks
>> increment at a hardware-convenient rate.
>> If the hardware timer can be prescaled to increment at 1000 Hz that
>> is fine, but I see no immediate need
On Tuesday, September 21, 2010, Mike Frysinger wrote:
> On Tuesday, September 21, 2010 04:37:40 Wolfgang Denk wrote:
>> Mike Frysinger wrote:
>> > so if the imported GRUB code stays at GPLv3, and is only for x86, and all
>> > of the code Graeme is using from u-boot is GPLv2+, then the final result
On Tuesday, September 21, 2010, Mike Frysinger wrote:
> On Tuesday, September 21, 2010 04:37:40 Wolfgang Denk wrote:
>> Mike Frysinger wrote:
>> > so if the imported GRUB code stays at GPLv3, and is only for x86, and all
>> > of the code Graeme is using from u-boot is GPLv2+, then the final result
CONFIG_UART1_CONSOLE was a PPC4xx specific implementation and is now
removed since the move from the 4xx UART driver to the common NS16550
UART driver. Let's remove all references to this define now.
Signed-off-by: Stefan Roese
---
README |7 ---
common/serial.c
On Tuesday, September 21, 2010 04:37:40 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > so if the imported GRUB code stays at GPLv3, and is only for x86, and all
> > of the code Graeme is using from u-boot is GPLv2+, then the final result
> > there is under GPLv3 only. but all his GPLv3 code, ass
Dear Mehmet Salih YILDIRIM,
In message <4c98640a.1060...@protel.tv> you wrote:
>
> I am using TI's davinci board (microprocessor is dm6446) and I both
> tried community u-boot build and I compiled myself. I try to boot kernel
> from tftp and fs from nfs but I cannot mount fs. Here is errors:
>
Dear Mike Frysinger,
In message <201009210351.16288.vap...@gentoo.org> you wrote:
>
> > It is my understanding that you cannot "downgrade" GPLv3 code, i. e.
> > you cannot link it into a GPLv2 project. But then, I'm not a license
> > expert, and IANAL.
>
> in-my-not-a-lawyer-opinion, i think intr
I am using TI's davinci board (microprocessor is dm6446) and I both
tried community u-boot build and I compiled myself. I try to boot kernel
from tftp and fs from nfs but I cannot mount fs. Here is errors:
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.50
IP-Config: Com
On Tuesday, September 21, 2010 03:33:37 Wolfgang Denk wrote:
> Graeme Russ wrote:
> > I know you are favouring a migration of U-Boot to GPLv3, but currently it
> > is still licensed under v2 (although most code is v2 'or later')
> >
> > I have some v3 code I would like to bring in (from GRUB). Wil
Remove some unused functionality to make U-Boot build again.
Especially PCI is not used on the board.
Signed-off-by: Matthias Fuchs
---
include/configs/DU405.h | 31 +--
1 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/include/configs/DU405.h b/includ
Dear Remy Bohmer,
In message you
wrote:
> The following changes since commit ff377b1c0e891569b6da13629090aad7c38175e0:
> Wolfgang Denk (1):
> canmb board: Fix compiler warnings
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-usb.git next
>
> Mike Frysinger
Dear Graeme Russ,
In message <4c8a1f2a.8020...@gmail.com> you wrote:
>
> I know you are favouring a migration of U-Boot to GPLv3, but currently it
> is still licensed under v2 (although most code is v2 'or later')
>
> I have some v3 code I would like to bring in (from GRUB). Will that cause
> an
Dear Stefan Roese,
In message <201009201612.14857...@denx.de> you wrote:
> The following changes since commit ff377b1c0e891569b6da13629090aad7c38175e0:
>
> canmb board: Fix compiler warnings (2010-09-19 19:29:57 +0200)
>
> are available in the git repository at:
> git://www.denx.de/git/u-boo
Dear Reinhard Meyer,
In message <4c98536c.6010...@emk-elektronik.de> you wrote:
>
> For me it seems useful to keep both functions and have ticks
> increment at a hardware-convenient rate.
> If the hardware timer can be prescaled to increment at 1000 Hz that
> is fine, but I see no immediate need f
54 matches
Mail list logo
