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
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
.
Anyway, your patch looks even better than my v1 then, so:
Acked-by: Gerlando Falauto gerlando.fala...@keymile.com
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
Hi Jagan,
On 07/04/2013 06:26 PM, Jagan Teki wrote:
On Thu, Jul 4, 2013 at 12:03 AM, Gerlando Falauto
gerlando.fala...@keymile.com 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
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
gerlando.fala...@keymile.com 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
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 gerlando.fala
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 gerlando.fala...@keymile.com
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc: Holger Brunck
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, 13 insertions(+), 2 deletions
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 gerlando.fala...@keymile.com
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc: Holger Brunck
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 gerlando.fala
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
___
U-Boot
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 Grusslingba...@grussling.com 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
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 from
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
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
gerlando.fala...@keymile.com wrote:
Hi all,
we recently to had face some nasty issues, where for some reason two
(functionally identical) versions of some code behave
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
a 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
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 gerlando.fala...@keymile.com
---
arch/powerpc/cpu
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
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
simplify #if defined(CONFIG_MPC8360) || defined(CONFIG_MPC832x)
for qe variables
with #if defined(CONFIG_QE)
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
arch/powerpc/cpu/mpc83xx/speed.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch
Add support for Keymile boards based on mpc8309
(it would be only kmvect1 for now)
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
board/keymile/km83xx/km83xx.c |2 +-
include/configs/km/km8309-common.h | 176
include/configs/km
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 gerlando.fala...@keymile.com
---
boards.cfg
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 gerlando.fala...@keymile.com
---
arch/powerpc/cpu/mpc83xx/cpu.c |1 +
arch
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
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
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
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
On 09/28/2012 01:18 AM, Kim Phillips wrote:
On Thu, 27 Sep 2012 09:21:19 +0200
Gerlando Falautogerlando.fala...@keymile.com 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
On 09/27/2012 03:22 AM, Kim Phillips wrote:
On Wed, 26 Sep 2012 10:28:08 +0200
Gerlando Falautogerlando.fala...@keymile.com 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
a 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
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
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
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 gerlando.fala...@keymile.com
---
boards.cfg
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 Keymile boards based on mpc8309
(it would be only kmvect1 for now)
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
board/keymile/km83xx/km83xx.c |2 +-
include/configs/km/km8309-common.h | 174
include/configs/km
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-bootm=132197537730440w=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 06:13 PM, Marek Vasut wrote:
Dear Wolfgang Denk,
Dear Gerlando Falauto,
In message1345803102-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 handling
On 09/02/2012 02:01 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message50379ad5.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[], int
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 (resetting the whole
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
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 gerlando.fala...@keymile.com
---
Changes from v4:
- renamed
On 08/13/2012 12:11 PM, Wolfgang Denk wrote:
Dear Holger Brunck,
In message5028ab80.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
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 logic to check and apply changes
env
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 gerlando.fala...@keymile.com
---
common/cmd_nvedit.c |5 ++---
1 file changed, 2 insertions(+), 3
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 gerlando.fala...@keymile.com
---
common/cmd_nvedit.c |3 ++-
common/env_common.c
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
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
-by: Gerlando Falauto gerlando.fala...@keymile.com
---
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
, no 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 gerlando.fala...@keymile.com
---
common/cmd_nvedit.c | 141 +--
include/search.h|3
;
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 gerlando.fala...@keymile.com
---
common/cmd_nvedit.c |3 ++-
common
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 gerlando.fala...@keymile.com
---
lib/hashtable.c | 48
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 checking and make
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/09/2012 10:17 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message191204-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 special variables
On 07/30/2012 09:12 PM, Wolfgang Denk wrote:
Dear Gerlando,
In message5016d241.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
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 gerlando.fala...@keymile.com
---
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
Dear Wolgfang Denk,
On 07/27/2012 07:30 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message1343402200-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 files
On 07/30/2012 03:00 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message50164f3a.6050...@keymile.com you wrote:
boards.cfg |4 +-
include/configs/km82xx.h| 149
+++
include/configs/mgcoge.h| 93
On 07/30/2012 06:07 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message5016a093.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-patch
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 gerlando.fala...@keymile.com
---
Changes from v1:
switched to git
On 07/27/2012 07:31 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message1343402200-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
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
From: Holger Brunck holger.bru...@keymile.com
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 holger.bru...@keymile.com
---
board/keymile/common/common.c |3 ---
1 files changed, 0 insertions(+), 3
From: Holger Brunck holger.bru...@keymile.com
Signed-off-by: Holger Brunck holger.bru...@keymile.com
---
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
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
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
include/configs/mgcoge.h| 34 +-
include/configs/mgcoge3ne.h | 34 +-
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/include/configs/mgcoge.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 gerlando.fala...@keymile.com
---
include/configs/km/km82xx-common.h | 317
include/configs/km82xx.h | 290
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 gerlando.fala...@keymile.com
---
boards.cfg |4
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 gerlando.fala...@keymile.com
---
board/keymile/km82xx/km82xx.c | 51
:
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 gerlando.fala...@keymile.com
---
include/configs/km82xx.h | 17 +
1 files changed, 13 insertions
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 gerlando.fala...@keymile.com
Signed-off-by: Holger Brunck holger.bru
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: Gerlando
From: Holger Brunck holger.bru...@keymile.com
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 holger.bru...@keymile.com
Signed-off-by: Gerlando Falauto
kw_sdram_bs_set(), to be called for instance within
board_early_init_f().
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
Reviewed-by: Marek Vasut ma...@denx.de
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Wolfgang Denk w...@denx.de
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc
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
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
gerlando.fala...@keymile.com wrote:
Some boards might be equipped with different SDRAM configurations.
When that is the case, CPU CS Window Size Register (CS[0]n Size
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
kw_sdram_bs_set(), to be called for instance within
board_early_init_f().
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
Cc: Marek Vasut ma...@denx.de
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Wolfgang Denk w...@denx.de
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc: Holger
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
kw_sdram_bs_set(), to be called for instance within
board_early_init_f().
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
Cc: Marek Vasut ma...@denx.de
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Wolfgang Denk w...@denx.de
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc: Holger
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,
On 04/04/2012 06:16 PM, Simon Glass wrote:
Hi Gerlando,
On Wed, Apr 4, 2012 at 3:35 AM, Gerlando Falauto
gerlando.fala...@keymile.com 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
not to overflow past the flash size.
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc: Holger Brunck holger.bru...@keymile.com
---
common/cmd_sf.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git
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.
Thank you,
Gerlando
Gerlando Falauto (2):
cmd_sf: let sf update erase last sector as a whole
cmd_sf
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 gerlando.fala...@keymile.com
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc: Holger Brunck
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 gerlando.fala
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 gerlando.fala...@keymile.com
---
lib/hashtable.c | 48
;
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 gerlando.fala...@keymile.com
---
common/cmd_nvedit.c |3 ++-
common
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
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
, no 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 gerlando.fala...@keymile.com
---
common/cmd_nvedit.c | 170 ---
include/search.h|3
-by: Gerlando Falauto gerlando.fala...@keymile.com
---
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
, 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 here
Gerlando Falauto (6):
env: unify
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
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 function to check
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 03/29/2012 10:19 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
WD prodded me too long to review this patchset ;-D
Well, better late than never! ;-)
[...]
+#if defined(CONFIG_CMD_NET)
+ else if (strcmp(name, bootfile) == 0) {
+ copy_filename(BootFile, newval, sizeof
On 03/29/2012 10:25 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
Changes in the syntax (user API) for env default:
-f: override write-once variables
-a: all (resetting the whole env is NOT the default behavior)
Signed-off-by: Gerlando Falautogerlando.fala...@keymile.com
I have
On 03/30/2012 03:08 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 03/29/2012 10:19 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
WD prodded me too long to review this patchset ;-D
Well, better late than never! ;-)
[...]
+#if defined(CONFIG_CMD_NET)
+ else if (strcmp(name
On 03/30/2012 03:09 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 03/29/2012 10:25 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
Changes in the syntax (user API) for env default:
-f: override write-once variables
-a: all (resetting the whole env is NOT the default behavior
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
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's code I just moved
1 - 100 of 144 matches
Mail list logo
