All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Lavnikevich <d.lavnikevich@sam-solutions.net>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Grigory Milev <G.Milev@sam-solutions.com>,
	"barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [PATCH] i.MX6: bbu: Barebox update support for NAND.
Date: Thu, 20 Mar 2014 13:28:59 +0300	[thread overview]
Message-ID: <532AC2EB.2040302@sam-solutions.net> (raw)
In-Reply-To: <20140313065458.GQ17250@pengutronix.de>

Hello Sascha,

have you tried my patch on your board yet?
I will correct mentioned points and resent it to mail list later.
I'm also interested to see your implementation of this functionality.
Particulary regarding the

> This doesn't seem to take bad blocks into account. What happens when the
> first firmware image gets bigger due to bad blocks? It will be
> overwritten by the 2nd image.

part.

Best regards,
Lavnikevich Dmitry

On 03/13/14 09:54, Sascha Hauer wrote:
> Hi Dmitry,
>
> On Wed, Mar 12, 2014 at 10:54:11AM +0300, Dmitry Lavnikevich wrote:
>> This patch implements updating barebox on i.MX6 NAND. In userspace
>> similar task is performed by freescale kobs-ng utility.
>> To use this bbu profile nand handler should be registered in board
>> code with 'imx6_bbu_internal_nand_register_handler' function.
> I have the very same patch in the queue, it seems we have duplicated
> some work. As this version has some shortcomings I'll post my version as
> an alternative implementation. Also I'll try your version on a board I
> have here on which my version doesn't work (which is the reason I
> haven't posted my patch yet)
>
>> +static int erase_part(struct mtd_info *mtd)
>> +{
>> +	loff_t ofs;
>> +	int ret = 0;
>> +	struct erase_info erase_opts = {
>> +		.mtd = mtd,
>> +		.addr = 0,
>> +		.len = mtd->erasesize,
>> +		.callback = NULL,
>> +	};
>> +
>> +	for (ofs = 0; ofs < mtd->size; ofs += mtd->erasesize) {
>> +		ret = mtd_block_isbad(mtd, ofs);
>> +		if (ret > 0) {
>> +			printf("Warning: bad block at 0x%08llx. Skipping\n",
>> +				   ofs);
>> +			continue;
> This is not worth issueing a warning. Bad blocks just happen.
>
>> +		} else if (ret < 0) {
>> +			printf("Error: checking bad block at 0x%llx failed\n",
>> +				   ofs);
>> +			ret = 1;
>> +			goto err;
>> +		}
>> +
>> +		erase_opts.addr = ofs;
>> +		ret = mtd->erase(mtd, &erase_opts);
> You should use mtd_erase and friends rather than dereferencing struct
> mtd_info.
>
>> +	buf = malloc(mtd->erasesize);
>> +	if (!buf) {
>> +		ret = -ENOMEM;
>> +		goto err_out;
>> +	}
>> +
>> +	image = read_imagefile(mtd, data->imagefile, &fw_size);
>> +	if (!image) {
>> +		ret = -errno;
>> +		goto err_out1;
>> +	}
> No Need to read the image, data->image contains a pointer to it.
>
>> +
>> +	search_area_size_in_bytes =
>> +		(1 << SEARCH_EXPONENT) * PAGES_PER_STRIDE * mtd->writesize;
>> +	max_boot_stream_in_bytes =
>> +		(mtd->size - search_area_size_in_bytes * 2) / 2;
>> +
>> +	fw1_offset = 2 * search_area_size_in_bytes;
>> +	fw2_offset = fw1_offset + max_boot_stream_in_bytes;
>> +
>> +	fcb = create_fcb(mtd, buf, fw1_offset, fw_size, fw2_offset);
>> +	if (IS_ERR(fcb)) {
>> +		printf("Failed to initialize FCB: %ld\n", PTR_ERR(fcb));
>> +		ret = PTR_ERR(fcb);
>> +		goto err_out2;
>> +	}
>> +	encode_hamming_13_8(fcb, (void *)fcb + 512, 512);
>> +
>> +	dbbt = create_dbbt(mtd, &bbtn);
>> +	if (!dbbt)
>> +		goto err_out2;
>> +
>> +	erase_part(mtd);
> Error checking?
>
>> +
>> +	block = bcb_cdev->offset;
>> +	for (fcb_written = 0; fcb_written < 4; fcb_written++) {
>> +
>> +		if (nand_isbad_bbt(mtd, block, false))
>> +			continue;
>> +
>> +		ret = write_fcb(mtd, buf, block);
>> +		if (ret) {
>> +			printf("Failed to write FCB to block %u\n", block);
>> +			goto err_out2;
>> +		}
>> +		block += mtd->erasesize;
>> +	}
>> +	ret = fcb_written ? 0 : -ENOSPC;
>> +	if (ret)
>> +		goto err_out2;
>> +
>> +	stride_size_in_bytes = PAGES_PER_STRIDE * mtd->writesize;
>> +	block = SEARCH_AREA_SIZE_IN_PAGES * mtd->writesize;
>> +	i = 0;
>> +	while (i < SEARCH_AREA_SIZE_IN_STRIDES) {
>> +		ret = write_dbbt(mtd, dbbt, buf, block, sizeof(*dbbt));
>> +		if (ret)
>> +			goto err_out2;
>> +
>> +		block += stride_size_in_bytes;
>> +		i++;
>> +	}
>> +
>> +	block = SEARCH_AREA_SIZE_IN_PAGES * mtd->writesize + 4 * mtd->writesize;
>> +	i = 0;
>> +	while (i < SEARCH_AREA_SIZE_IN_STRIDES) {
>> +		ret = write_bbtn(mtd, bbtn, buf, block, sizeof(*bbtn));
>> +		if (ret)
>> +			goto err_out2;
>> +
>> +		block += stride_size_in_bytes;
>> +		i++;
>> +	}
>> +
>> +	ret = write_image(mtd, image, fw1_offset, fw_size);
>> +	if (ret)
>> +		goto err_out2;
>> +	ret = write_image(mtd, image, fw2_offset, fw_size);
>> +	if (ret)
>> +		goto err_out2;
> This doesn't seem to take bad blocks into account. What happens when the
> first firmware image gets bigger due to bad blocks? It will be
> overwritten by the 2nd image.
>
> Sascha
>


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  parent reply	other threads:[~2014-03-20 10:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12  7:54 [PATCH] i.MX6: bbu: Barebox update support for NAND Dmitry Lavnikevich
2014-03-13  6:54 ` Sascha Hauer
2014-03-13  7:50   ` Dmitry Lavnikevich
2014-03-20 10:28   ` Dmitry Lavnikevich [this message]
2014-03-22  7:06     ` Sascha Hauer
2014-03-31  8:42   ` Sascha Hauer
2014-04-01  7:36     ` Christian Hemp

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=532AC2EB.2040302@sam-solutions.net \
    --to=d.lavnikevich@sam-solutions.net \
    --cc=G.Milev@sam-solutions.com \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.