Hi Stefan,
On 01/12/2015 08:56 AM, Stefan Roese wrote:
Hi Gerlando,
On 12.01.2015 08:51, Gerlando Falauto wrote:
thanks for the patch.
Please compare it with my v1 revision of the patch:
http://patchwork.ozlabs.org/patch/150468/
Back then, Simon suggested to use two separate SPI flash
Hi Wolfgang,
On 01/12/2015 08:27 AM, Stefan Roese wrote:
Hi Wolfgang,
On 12.01.2015 08:17, Wolfgang Denk wrote:
The new code is even simpler and copies the source data into the temp
buffer and now uses the temp buffer to write the complete sector. So
only one SPI sector write is used now inste
.
Anyway, your patch looks even better than my v1 then, so:
Acked-by: Gerlando Falauto
Thank you,
Gerlando
On 01/09/2015 02:39 PM, Stefan Roese wrote:
On SoCFPGA, using "sf update" with an non-4byte aligned length leads
to a hangup (and reboot via watchdog). This is because of the
Hi Jagan,
On 07/04/2013 06:26 PM, Jagan Teki wrote:
On Thu, Jul 4, 2013 at 12:03 AM, Gerlando Falauto
wrote:
Since "sf update" erases the last block as a whole, but only rewrites
the meaningful initial part of it, the rest would be left erased,
potentially erasing meaningful infor
de
Changes from v1 [April, 03, 2012 (!)]:
- Rebased on top of u-boot-spi/master
Gerlando Falauto (2):
cmd_sf: let "sf update" erase last sector as a whole
cmd_sf: "sf update" preserve the final part of the last sector
common/cmd_sf.c | 15 +--
1 file changed,
make "sf update" work with unaligned `len' parameter, by deleting the
whole last sector before writing, so to allow for:
sf update ${load_addr_r} 0 ${filesize}
Signed-off-by: Gerlando Falauto
Cc: Valentin Longchamp
Cc: Holger Brunck
Acked-by: Simon Glass
---
common/cmd_sf.c
Since "sf update" erases the last block as a whole, but only rewrites
the meaningful initial part of it, the rest would be left erased,
potentially erasing meaningful information.
So, as a safety measure, have it rewrite the original content.
Signed-off-by: Gerlando Falauto
Cc
Hi,
On 07/03/2013 05:04 PM, Jagan Teki wrote:
Hi,
Thanks for the v2.
On Fri, Jun 28, 2013 at 1:13 PM, Gerlando Falauto
wrote:
Since "sf update" erases the last block as a whole, but only rewrites
the meaningful initial part of it, the rest would be left erased,
potential
Since "sf update" erases the last block as a whole, but only rewrites
the meaningful initial part of it, the rest would be left erased,
potentially erasing meaningful information.
So, as a safety measure, have it rewrite the original content.
Signed-off-by: Gerlando Falauto
Cc
spi/master
Gerlando Falauto (2):
cmd_sf: let "sf update" erase last sector as a whole
cmd_sf: "sf update" preserve the final part of the last sector
common/cmd_sf.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
--
1.7.10.1
___
make "sf update" work with unaligned `len' parameter, by deleting the
whole last sector before writing, so to allow for:
sf update ${load_addr_r} 0 ${filesize}
Signed-off-by: Gerlando Falauto
Cc: Valentin Longchamp
Cc: Holger Brunck
Acked-by: Simon Glass
---
common/cmd_sf.
Wadaskar wrote:
-Original Message-
From: Holger Brunck [mailto:holger.bru...@keymile.com]
Sent: 16 January 2013 14:04
To: u-boot@lists.denx.de
Cc: Gerlando Falauto; Holger Brunck; Valentin Longchamp; Prafulla
Wadaskar
Subject: [PATCH] kirkwood_nand: allow usage of NAND_ECC_SOFT_BCH
From
On 01/15/2013 01:59 AM, Kim Phillips wrote:
On Tue, 8 Jan 2013 18:25:11 -0800
Barry Grussling wrote:
---
can I get an ack from someone else with an 8308 here please? This
custom board fix has the possibility of bricking all existing
8308 based mainline boards.
Sorry, we only have an 8309 b
On 11/20/2012 02:26 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 11/20/2012 09:54 AM, Marek Vasut wrote:
Dear Gerlando Falauto,
Hi all,
we recently to had face some nasty issues, where for some reason two
(functionally identical) versions of some code behave very differently.
Namely
On 11/20/2012 09:54 AM, Marek Vasut wrote:
Dear Gerlando Falauto,
Hi all,
we recently to had face some nasty issues, where for some reason two
(functionally identical) versions of some code behave very differently.
Namely, one version works and the other doesn't always work.
It was clear
Hi Albert,
On 11/10/2012 12:25 PM, Albert ARIBAUD wrote:
Hi Gerlando,
On Tue, 30 Oct 2012 12:08:01 +0100, Gerlando Falauto
wrote:
Hi all,
we recently to had face some nasty issues, where for some reason two
(functionally identical) versions of some code behave very differently.
Namely
Hi all,
we recently to had face some nasty issues, where for some reason two
(functionally identical) versions of some code behave very differently.
Namely, one version works and the other doesn't always work.
It was clear from the beginning this was because of HW- (or compiler-)
related issue
This processor, though very similar to other members of the
PowerQUICC II Pro family (namely 8308, 8360 and 832x), provides
yet another feature set than any supported sibling.
Signed-off-by: Gerlando Falauto
---
arch/powerpc/cpu/mpc83xx/cpu.c |1 +
arch/powerpc/cpu/mpc83xx
Add support for the new kmvect1 board powered by the mpc8309 processor.
As this board is very similar to the existing suvd3, instead of adding a
new config header file, just add a new config option to suvd3.h
Signed-off-by: Gerlando Falauto
---
boards.cfg |3 ++-
include
Add support for Keymile boards based on mpc8309
(it would be only kmvect1 for now)
Signed-off-by: Gerlando Falauto
---
board/keymile/km83xx/km83xx.c |2 +-
include/configs/km/km8309-common.h | 176
include/configs/km/km83xx-common.h |6 ++
3
simplify #if defined(CONFIG_MPC8360) || defined(CONFIG_MPC832x)
for qe variables
with #if defined(CONFIG_QE)
Signed-off-by: Gerlando Falauto
---
arch/powerpc/cpu/mpc83xx/speed.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx/speed.c b
Signed-off-by: Gerlando Falauto
---
include/configs/km/km8321-common.h |2 +-
include/configs/suvd3.h|4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/configs/km/km8321-common.h
b/include/configs/km/km8321-common.h
index 580b72f..8ad6fc3 100644
Introduce a new configuration token CONFIG_MPC830x to be shared among
mpc8308 and mpc8309. Define it for existing 8308 boards, and refactor
existing common code so to make future introduction of 8309 simpler.
Signed-off-by: Gerlando Falauto
---
arch/powerpc/cpu/mpc83xx/speed.c |3
new one.
Difference from v1:
- added preliminary cleanup patches #2/3 to simplify #if conditions in speed.c
- fixed #ifdef so to restore code block assigning to usbdr_clk
- removed checkpatch errors
Gerlando Falauto (6):
cosmetic: suvd3: align #defines
cleanup: use CONFIG_QE instead of
Hi Stefano,
On 10/05/2012 12:41 PM, Stefano Babic wrote:
On 05/10/2012 12:29, Gerlando Falauto wrote:
Hi Stefano,
Hi Gerlando,
thanks for reporting and providing a fix for this.
I'm very sorry for introducing this problem and for the late response.
Please see my comments below.
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 3474bc6..c38b475 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -213,6 +213,9 @@ int env_check_apply(const char *name,
Hi Stefano,
thanks for reporting and providing a fix for this.
I'm very sorry for introducing this problem and for the late response.
Please see my comments below.
[As a side node, I couldn't really reproduce the issue neither on
PowerPC nor on ARM (though simple_strtoul should legitimately cr
On 09/28/2012 01:18 AM, Kim Phillips wrote:
On Thu, 27 Sep 2012 09:21:19 +0200
Gerlando Falauto wrote:
On 09/27/2012 03:22 AM, Kim Phillips wrote:
[...]
so far the 8308 and the 8360 are the only SoCs that don't have a
'tens'/MPC83Xx defines. The 8360 can get away with it,
On 09/27/2012 03:22 AM, Kim Phillips wrote:
On Wed, 26 Sep 2012 10:28:08 +0200
Gerlando Falauto wrote:
This processor, though very similar to other members of the
PowerQUICC II Pro family (namely 8308, 8360 and 832x), provides
yet another feature set than any supported sibling.
So we add a
Add support for Keymile boards based on mpc8309
(it would be only kmvect1 for now)
Signed-off-by: Gerlando Falauto
---
board/keymile/km83xx/km83xx.c |2 +-
include/configs/km/km8309-common.h | 174
include/configs/km/km83xx-common.h |6 ++
3
be worth to refactor the whole file so to first
identify the featureset of the given CPU, and enclose each block within
#ifdef CONFIG_MPC83XX_FEAT_
for instance:
- CONFIG_MPC83XX_FEAT_USBDR
- CONFIG_MPC83XX_FEAT_QE
- CONFIG_MPC83XX_FEAT_DDRSEC
...etc...
Signed-off-by: Gerlando Falauto
Add support for the new kmvect1 board powered by the mpc8309 processor.
As this board is very similar to the existing suvd3, instead of adding a
new config header file, just add a new config option to suvd3.h
Signed-off-by: Gerlando Falauto
---
boards.cfg |3 ++-
include
Signed-off-by: Gerlando Falauto
---
include/configs/km/km8321-common.h |2 +-
include/configs/suvd3.h|4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/configs/km/km8321-common.h
b/include/configs/km/km8321-common.h
index 580b72f..8ad6fc3 100644
new one.
NOTE: speed.c is getting more and more complicated by long #ifdef conditions
affecting even single lines. Perhaps a whole feature-set partitioning could
lead to much cleaner code.
Gerlando Falauto (4):
cosmetic: suvd3: align #defines
mpc83xx: add support for mpc8309
km83xx: add
Hi,
this patch actually breaks the mpc83xx board I am currently working on,
leading to a detected size of 2 GiB (as opposed to the actual size of
128 MiB).
I tried reviewing it and couldn't really figure out why, as it seems
legitimate, and I currently don't have a chance to check it on other
Hi everyone,
following up Timur's patch on QE microcode:
http://marc.info/?l=u-boot&m=132197537730440&w=2
I was wondering, would it make any sense to *embed* QE's firmware within
u-boot image itself?
After all, it should be some ~64KB worth of data, right?
Not quite sure whether this has ever
On 09/02/2012 02:01 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message<50379ad5.6030...@keymile.com> you wrote:
int himport_r(struct hsearch_data *htab,
const char *env, size_t size, const char sep, int flag,
- int nvars, char * const vars[
On 09/02/2012 06:13 PM, Marek Vasut wrote:
Dear Wolfgang Denk,
Dear Gerlando Falauto,
In message<1345803102-21110-1-git-send-email-gerlando.fala...@keymile.com>
you wrote:
This patchset modifies the handling of all the operations on the
environment (set/import/default) so to unify ha
When variables explicitly specified on the command line are not present
in the imported env, delete them from the running env.
If the variable is also missing from the running env, issue a warning.
Signed-off-by: Gerlando Falauto
---
Changes from v4:
- renamed is_var_in_set to drop_var_from_set
On 08/24/2012 11:12 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 08/24/2012 04:58 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
When variables explicitly specified on the command line are not present
in the imported env, delete them from the running env.
If the variable is also missing
On 08/24/2012 11:10 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 08/24/2012 04:56 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
Change the syntax (user API) for "env default":
-f: override write-once variables
var... : accept individual variable(s)
-a: all (res
On 08/24/2012 04:58 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
When variables explicitly specified on the command line are not present
in the imported env, delete them from the running env.
If the variable is also missing from the running env, issue a warning.
Signed-off-by: Gerlando
On 08/24/2012 04:56 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
Change the syntax (user API) for "env default":
-f: override write-once variables
var... : accept individual variable(s)
-a: all (resetting the whole env is NOT the default behavior)
Enable variable checkin
When variables explicitly specified on the command line are not present
in the imported env, delete them from the running env.
If the variable is also missing from the running env, issue a warning.
Signed-off-by: Gerlando Falauto
---
lib/hashtable.c | 48
he changes;
when NULL, no check is performed.
And a new argument to himport_r():
o "do_apply": whether to call the apply callback function
NOTE: This patch does not change the current behavior.
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c |3 ++-
common/e
matter if by set, default or import.
With this patch env_check_apply() is only called by "env set",
retaining previous behavior.
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c | 141 +--
include/search.h|3 +-
2 files c
).
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c | 40 ++--
common/env_common.c | 28 +++-
include/environment.h |3 +++
3 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cm
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c |2 +-
include/search.h|5 +++--
lib/hashtable.c | 16 ++--
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 983e747..b0860f3 100644
--- a/common
Add 2 new arguments to himport_r():
o "nvars", "vars": number and list of variables to take into account
(0 means ALL)
NOTE: This patch does not change the current behaviour.
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c |3 ++-
common/env_common.c |
iomux_doenv() can only return 0 or 1.
So there is no need to save its return value in variable i, as checking
its truth value within an if statement is enough.
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a
nged env_check_apply so not to display warnings
in case of H_FORCE flag being set
Changes from v0
- checkpatch cleanup
- removed himport_ex()
- removed warning for serial_assign()
- env import NOT implemented here
Gerlando Falauto (7):
env: cosmetic: drop assignment i = iomux_doenv()
env: unify lo
On 08/13/2012 12:11 PM, Wolfgang Denk wrote:
Dear Holger Brunck,
In message<5028ab80.5030...@keymile.com> you wrote:
time to do updates here I propose the following. I could prepare a branch as you
suggested based on current denx master with this changeset. But where and how
should I push it
On 08/09/2012 10:17 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message<191204-16318-1-git-send-email-gerlando.fala...@keymile.com> you
wrote:
This patchset modifies the handling of all the operations on the environment
(set/import/default) so to unify handling of s
The only file including km82xx-common.h is km82xx.h.
So there is no need to have it as a separate file.
Signed-off-by: Gerlando Falauto
---
Changes from v1:
switched to git v1.7.10.4, used git format-patch -M -C -B
---
include/configs/{km/km82xx-common.h => km82xx.h} |
On 07/30/2012 09:12 PM, Wolfgang Denk wrote:
Dear Gerlando,
In message<5016d241.4030...@keymile.com> you wrote:
Please also try with -M -C and see if this changes anything.
For this one patch I can't get git to detect renames.
Neither can I. Thanks for trying, though.
It turns out you
On 07/27/2012 07:31 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message<1343402200-32020-5-git-send-email-gerlando.fala...@keymile.com> you
wrote:
The only file including km82xx-common.h is km82xx.h.
So there is no need to have it as a separate file.
Signed-off-by: Gerlando F
Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need
to keep them as separate .h config files.
Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km82xx.h
file.
Signed-off-by: Gerlando Falauto
---
Changes from v1:
switched to git v1.7.11.3, used git format-patch
On 07/30/2012 06:07 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message<5016a093.6040...@keymile.com> you wrote:
The way I understand it, such renaming information is built on the fly
while building the patch (like you're suggesting, it's a parameter to
git format-p
On 07/30/2012 03:00 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message<50164f3a.6050...@keymile.com> you wrote:
boards.cfg |4 +-
include/configs/km82xx.h| 149
+++
include/configs/mgcoge.h
Dear Wolgfang Denk,
On 07/27/2012 07:30 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message<1343402200-32020-4-git-send-email-gerlando.fala...@keymile.com> you
wrote:
Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need
to keep them as separate .h config
The HW guys suggested to change these two values. And these values are
now identical to the values we use on mgcoge.
PSDMR_WRC was set to 1C as it should lead to better performance.
Signed-off-by: Gerlando Falauto
Signed-off-by: Holger Brunck
---
include/configs/km82xx.h |6 --
1
:
4 chips x 8M (13 rows, 10 cols) x 16 bit x 4 banks
we can now also have 128MB geometry:
4 chips x 4M (13 rows, 9 cols) x 16 bit x 4 banks
Signed-off-by: Gerlando Falauto
---
include/configs/km82xx.h | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git
bitfields will be
defined, as usual, within CONFIG_SYS_PSDMR and CONFIG_SYS_OR1.
If CONFIG_SYS_SDRAM_LIST is not defined, then the usual behavior is retained.
Signed-off-by: Gerlando Falauto
---
board/keymile/km82xx/km82xx.c | 51 +++-
1 files changed, 49
Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need
to keep them as separate .h config files.
Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km82xx.h
file.
Signed-off-by: Gerlando Falauto
---
boards.cfg |4 +-
include/configs/km82xx.h
The only file including km82xx-common.h is km82xx.h.
So there is no need to have it as a separate file.
Signed-off-by: Gerlando Falauto
---
include/configs/km/km82xx-common.h | 317
include/configs/km82xx.h | 290
Signed-off-by: Gerlando Falauto
---
include/configs/mgcoge.h| 34 +-
include/configs/mgcoge3ne.h | 34 +-
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h
Hello,
this patch series does a bit of housekeeping on our mgcogeXxx boards.
First we do some due code cleanups which just move code around,
then we introduce dynamic SDRAM detection so the same u-boot binary
can be used on different boards.
Gerlando Falauto (6):
powerpc/82xx: move mgcoge
From: Holger Brunck
Signed-off-by: Holger Brunck
---
include/configs/mgcoge3ne.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/configs/mgcoge3ne.h b/include/configs/mgcoge3ne.h
index 6fa1584..43d14ba 100644
--- a/include/configs/mgcoge3ne.h
+++ b/include/con
From: Holger Brunck
This code will also be used before reallocation and during this time we
are not allowed to do these printings.
Signed-off-by: Holger Brunck
---
board/keymile/common/common.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/board/keymile/common/comm
Hi all,
On 03/09/2011 02:21 PM, Detlev Zundel wrote:
Hi Heiko,
Maybe a way to go ... more comments?
Below a patch, which introduces a function, which checks for
"protection bugfixes", and if no bugfix is found the old code is
executed. Just a fast RFC patch.
bye,
Heiko
[...]
Can't we int
From: Holger Brunck
Some boards may differ only in the SDRAM size. This function allows to
fix the size accordingly and we can use the same u-boot binary for both
boards.
Signed-off-by: Holger Brunck
Signed-off-by: Gerlando Falauto
cc: Prafulla Wadaskar
cc: Valentin Longchamp
---
changes
Size of the SDRAM chips might differ between any two (otherwise
identical) instances of the same board.
So add a function kw_sdram_size_adjust() which reads out the current
ram size for a given bank, and adjusts the Kirkwood's SDRAM window size
register accordingly.
Signed-off-by: Ger
Size of the SDRAM chips might differ between any two (otherwise
identical) instances of the same board.
So change board_early_init_f() to use km_sdram_bs_set(), in order to
fixup the window size register at runtime, according to the detected
SDRAM size.
Signed-off-by: Gerlando Falauto
Cc
kw_sdram_bs_set(), to be called for instance within
board_early_init_f().
Signed-off-by: Gerlando Falauto
Reviewed-by: Marek Vasut
Cc: Prafulla Wadaskar
Cc: Wolfgang Denk
Cc: Valentin Longchamp
Cc: Holger Brunck
---
changes for v2:
added Reviewed-by: Marek Vasut
arch/arm/cpu/arm926ejs/kirkwood
On 07/05/2012 05:38 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
Some boards might be equipped with different SDRAM configurations.
When that is the case, CPU CS Window Size Register (CS[0]n Size) should
be set to the biggest value through board.cfg file; then its value
can be fixed at
kw_sdram_bs_set(), to be called for instance within
board_early_init_f().
Signed-off-by: Gerlando Falauto
Cc: Marek Vasut
Cc: Prafulla Wadaskar
Cc: Wolfgang Denk
Cc: Valentin Longchamp
Cc: Holger Brunck
---
arch/arm/cpu/arm926ejs/kirkwood/dram.c | 23 +++
arch/arm/include/asm
Size of the SDRAM chips might differ between any two (otherwise
identical) instances of the same board.
So change board_early_init_f() to use km_sdram_bs_set(), in order to
fixup the window size register at runtime, according to the detected
SDRAM size.
Signed-off-by: Gerlando Falauto
Cc
Hi Albert,
On 07/05/2012 12:39 PM, Albert ARIBAUD wrote:
Hi Gerlando,
On Fri, 29 Jun 2012 13:37:54 +0200, Gerlando Falauto
wrote:
Some boards might be equipped with different SDRAM configurations.
When that is the case, CPU CS Window Size Register (CS[0]n Size)
should be set to the biggest
kw_sdram_bs_set(), to be called for instance within
board_early_init_f().
Signed-off-by: Gerlando Falauto
Cc: Marek Vasut
Cc: Prafulla Wadaskar
Cc: Wolfgang Denk
Cc: Valentin Longchamp
Cc: Holger Brunck
---
arch/arm/cpu/arm926ejs/kirkwood/dram.c | 28 ++--
arch/arm
Dear Marek Vasut,
On 06/29/2012 12:08 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
Dear Maruk,
sorry about my misspelling!
I am currently trying to address the exact same issue (SDRAM size
detection and fixup).
My idea was however (as opposed to moving register definition as you
did
Dear Maruk,
I am currently trying to address the exact same issue (SDRAM size
detection and fixup).
My idea was however (as opposed to moving register definition as you
did), to add a fixup function to dram.c, say:
/*
* kw_sdram_bs - writes SDRAM Bank size
*/
void kw_sdram_bs_set(enum memor
On 04/04/2012 06:16 PM, Simon Glass wrote:
Hi Gerlando,
On Wed, Apr 4, 2012 at 3:35 AM, Gerlando Falauto
wrote:
Hi Simon,
OK I haven't tried it yet, but this sounds awesome.
I wonder how people manage to send and rework their patches without such
tool. Even one single patchset has
Hi Simon,
OK I haven't tried it yet, but this sounds awesome.
I wonder how people manage to send and rework their patches without such
tool. Even one single patchset has been giving me strong enough
headaches so far, not to mention the massive waste of time.
I pretty much agree with Albert, t
Since "sf update" erases the last block as a whole, but only rewrites
the meaningful initial part of it, the rest would be left erased,
potentially erasing meaningful information.
So, as a safety measure, have it rewrite the original content.
Signed-off-by: Gerlando Falauto
Cc
make "sf update" work with unaligned `len' parameter, by deleting the
whole last sector before writing, so to allow for:
sf update ${load_addr_r} 0 ${filesize}
Signed-off-by: Gerlando Falauto
Cc: Valentin Longchamp
Cc: Holger Brunck
---
common/cmd_sf.c |3 ++-
1 f
of
optimizing the process by removing unneeded erase/write operations. So it
might as well deserve to be "special", in my opinion. Plus, it makes the
command for updating u-boot as easy as
sf update ${load_addr_r} 0 ${filesize}
Feedback and criticism more than welcome, of course.
to overflow past the flash size.
Signed-off-by: Gerlando Falauto
Cc: Valentin Longchamp
Cc: Holger Brunck
---
common/cmd_sf.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 9c76464..3cfedde 100644
--- a/common
On 04/02/2012 09:06 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
When variables explicitly specified on the command line are not present
in the imported env, delete them from the running env.
If the variable is also missing from the running env, issue a warning.
Signed-off-by: Gerlando
On 04/02/2012 09:01 PM, Marek Vasut wrote:
Dear Marek Vasut,
Dear Gerlando Falauto,
Change hashtable so that a callback function will decide whether a
variable can be overwritten, and possibly apply the changes.
So add a new field to struct hsearch_data:
o "apply" callback f
On 04/02/2012 08:57 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
Add 2 new arguments to himport_r():
o "nvars", "vars": number and list of variables to take into account
(0 means ALL)
Looks nice and clean. But man, these patches are tough to review (not beca
On 04/02/2012 08:56 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
The logic of checking special parameters (e.g. baudrate, stdin, stdout,
for a valid value and/or whether can be overwritten) and applying the
new value to the running system is now all within a single function
env_check_apply
k_apply
(comparing {loadaddr, bootfile} to values instead
of variable names)
- changed env_check_apply so not to display warnings
in case of H_FORCE flag being set
Changes from v0
- checkpatch cleanup
- removed himport_ex()
- removed warning for serial_assign()
- env import NOT implemented her
).
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c | 40 ++--
common/env_common.c | 28 +++-
include/environment.h |3 +++
3 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cm
matter if by set, default or import.
With this patch env_check_apply() is only called by "env set",
retaining previous behavior.
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c | 170 ---
include/search.h|3 +-
2 files ch
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c |2 +-
include/search.h|5 +++--
lib/hashtable.c | 16 ++--
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index fc6165f..091cd46 100644
--- a/common
he changes;
when NULL, no check is performed.
And a new argument to himport_r():
o "do_apply": whether to call the apply callback function
NOTE: This patch does not change the current behavior.
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c |3 ++-
common/e
When variables explicitly specified on the command line are not present
in the imported env, delete them from the running env.
If the variable is also missing from the running env, issue a warning.
Signed-off-by: Gerlando Falauto
---
lib/hashtable.c | 48
Add 2 new arguments to himport_r():
o "nvars", "vars": number and list of variables to take into account
(0 means ALL)
NOTE: This patch does not change the current behaviour.
Signed-off-by: Gerlando Falauto
---
common/cmd_nvedit.c |3 ++-
common/env_common.c |
On 03/30/2012 03:00 PM, Gerlando Falauto wrote:
On 03/29/2012 10:19 PM, Marek Vasut wrote:
[...]
+#if defined(CONFIG_CMD_NET)
+ else if (strcmp(name, "bootfile") == 0) {
+ copy_filename(BootFile, newval, sizeof(BootFile));
Can you remove the camel-case here please?
That
On 03/30/2012 03:55 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 03/30/2012 03:08 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 03/29/2012 10:19 PM, Marek Vasut wrote:
[...]
+ return 0;
+ }
+#endif
+ return 0;
+}
+
[...]
--- a/include/search.h
+++ b
1 - 100 of 149 matches
Mail list logo
