Re: FW: Handling boot on NAND Bad Blocks

2017-11-23 Thread Robert Schwebel
Hi Kjell, On Thu, Nov 23, 2017 at 01:45:22PM +, Kjell Ove Røte wrote: > We have a product on the Freescale imx28 booting from a NAND Flash. > Lately we have seen high numbers of boards failing, and find we have > received batches with marked bad blocks in lower boot addresses of > Flash. Is i

FW: Handling boot on NAND Bad Blocks

2017-11-23 Thread Kjell Ove Røte
Hi We have a product on the Freescale imx28 booting from a NAND Flash. Lately we have seen high numbers of boards failing, and find we have received batches with marked bad blocks in lower boot addresses of Flash. Typically we see bad blocks in partition where Barebox are located. We do also us

[PATCH 11/6] net/e1000: expand timeout for flash erasure

2017-11-23 Thread Uwe Kleine-König
Erasing the whole flash takes approximately 7s on one of my test machines. Expand the timeout accordingly. Note however that it is in general not allowed to hold the flash semaphore for so long and "firmware might implement a timeout mechanism and take ownership of the relevant [lock]" after one s

[PATCH 9/6] net/e1000: don't access the (simulated) eeprom when it is invalid

2017-11-23 Thread Uwe Kleine-König
The shadow RAM that is used to serve read requests from the eeprom interface isn't valid in all cases. Catch these by returning an error in the eeprom read function and make eeprom validation dependant on working access. Signed-off-by: Uwe Kleine-König --- drivers/net/e1000/e1000.h | 3 +++ dr

[PATCH 8/6] net/e1000: log flash/invm status at probe time

2017-11-23 Thread Uwe Kleine-König
Provide some info about flash/eeprom state at boot up Signed-off-by: Uwe Kleine-König --- drivers/net/e1000/eeprom.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/net/e1000/eeprom.c b/drivers/net/e1000/eeprom.c index e5f8c9e271e0..cb92deee3b44 100644 --- a/drive

[PATCH 10/6] net/e1000: indicate in error messages where the failure occured

2017-11-23 Thread Uwe Kleine-König
There used to be four places that all emit the same error message. Even if in a given context not all four of them can be relevant, there are always two possible locations where the message can origin from. So make the output slightly different in all places to ease future debugging. Signed-off-b

[PATCH 7/6] net/e1000: don't fail to bind on uninitialized flash

2017-11-23 Thread Uwe Kleine-König
When the flash doesn't hold a valid firmware image there are still some things (like accessing the flash) possible. Don't return an error code in this case but return 0 instead. This way the driver is regularily bound and just doesn't provide a network interface. Signed-off-by: Uwe Kleine-König -

[PATCH] globalvar: When a globalvar is created with a NULL value, use empty string

2017-11-23 Thread Sascha Hauer
As a convenience for users of globalvar_add_simple_string() create an empty value for the variable when passed a NULL pointer as value. Signed-off-by: Sascha Hauer --- common/globalvar.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/globalvar.c b/common/globalvar.c index ee756e51

[PATCH] nv: add device parameter overwrites to completion list

2017-11-23 Thread Sascha Hauer
nv variables in the form dev..* can be used to make device parameters persistent. Add these to the completion list to make setting these variables more convenient. Signed-off-by: Sascha Hauer --- commands/global.c | 2 +- commands/nv.c | 2 +- common/globalvar.c | 33 +