From: "Kjell Ove Røte" <kjellove.rote@zenitel.com>
To: Robert Schwebel <robert@schwebel.de>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: RE: FW: Handling boot on NAND Bad Blocks
Date: Mon, 4 Dec 2017 08:49:56 +0000 [thread overview]
Message-ID: <4b948dadc18b48ff822f24f7e1fac737@nooslMX1.zenitelcss.com> (raw)
In-Reply-To: <20171130214354.dyuew52qyyio2j4l@pengutronix.de>
Hi Robert
Did lookup the Boot ROM error codes:
0x8050100B Load command payload CRC failed.
0x8050800F ECC failed - data is not valid.
So, I assume in our case that it is stored a CRC of bootstream in the BCB image (with command bcb nand0.bootstream)
The MXS Bootrom code CRC check fails since image is written over a bad block. We do write bootstream image with Barebox doing a copy to a badblock aware device (nand0.bootstream.bb), so I guess the problem is that the ROM boot code is not skipping bad block on read.
Partitioning with two bootstreams, and using command "bcb nand0.bootstream nand0.bootstream2", we do handle bad block on one of the bootstream partitions, but if one bad block in each we are stuck.
On my other questions on the other boot images like kernel and environment I do now see how it works with the bad block devices, and handling of skipping bad blocks. Adjusting some on the partition sizes allocating enough free erase blocks, we get good robustness on bad blocks in the rest of the NAND.
Best re
KJELL OVE RØTE
SENIOR SOFTWARE ENGINEER
ZENITEL NORWAY AS
Tel: +47 400 02 573
kjellove.rote@zenitel.com
Sandakerveien 24C, 0473 Oslo, Norway
P.O.Box 1068 Bekkajordet, NO-3194 Horten, Norway
Switchboard: +47 4000 2500
www.zenitel.com
-----Original Message-----
From: Robert Schwebel [mailto:robert@schwebel.de]
Sent: torsdag 30. november 2017 22.44
To: Kjell Ove Røte <kjellove.rote@zenitel.com>
Cc: barebox@lists.infradead.org
Subject: Re: FW: Handling boot on NAND Bad Blocks
On Fri, Nov 24, 2017 at 08:49:22AM +0000, Kjell Ove Røte wrote:
> In the original case the board just reboots when the Barebox is to be loaded from the bootstream image.
> In log below you see that the power_prep and boot_prep is run but the Barebox is not started at all.
> So, in this case there is no Barebox issue, but I was looking for if there are some mechanism for handling boot environment, kernel load etc with Bad block management.
> For example something like writing and loading a kernel image, using skip block method, from a partition with bad blocks and image cannot be stored over linear addresses.
>
> Booting an image where Barebox is stored in a NAND Bad Block:
>
> PowerPrep start initialize power...
>
> Configured for 5v only power source. Battery powered operation disabled.
>
> Turbine PowerPrep POWER RESET, EMC hardness Disable the chip shutting
> down by a fast falling edge of PSWITCH Nov 24 201608:57:28 FRAC
> 0x92925552 Wait for ddr ready 1power 0x00820616 Frac 0x92925552 start
> change cpu freq hbus 0x00000003 cpu 0x00010001 start test memory
> accress
> ddr2 0x40000000
> finish simple test
> 0x8050100b
> 0x8050800f
Hmm, that doesn't look familiar to me (we had other NAND issues recently).
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
DISCLAIMER:
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2017-12-04 8:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 13:45 Kjell Ove Røte
2017-11-23 17:12 ` Robert Schwebel
2017-11-24 8:49 ` Kjell Ove Røte
2017-11-30 21:43 ` Robert Schwebel
2017-12-04 8:49 ` Kjell Ove Røte [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b948dadc18b48ff822f24f7e1fac737@nooslMX1.zenitelcss.com \
--to=kjellove.rote@zenitel.com \
--cc=barebox@lists.infradead.org \
--cc=robert@schwebel.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox