From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC 2/3] tools/env: Support writing to files
Date: Sat, 04 Dec 2010 12:23:20 +0100 [thread overview]
Message-ID: <4CFA24A8.7030709@denx.de> (raw)
In-Reply-To: <1291436933-26861-3-git-send-email-steve@sakoman.com>
On 12/04/2010 05:28 AM, Steve Sakoman wrote:
> -static int flash_bad_block (int fd, uint8_t mtd_type, loff_t *blockstart)
> +static int flash_bad_block (int fd, uint8_t mtd_type, loff_t *blockstart,
> + int is_mtd)
You add an additional parameter to the flash function to check if it is
a real mtd, but we have already a structure to store which type of flash
we have. We could use envdevices[].mtd_type to store that we want to
write into a file and not into a mtd device. There is already a
MTD_ABSENT constant that we could reuse.
> {
> + if (!is_mtd)
> + return 0;
> +
Because this function does nothing with the parameter, it should be
better to check its value in the caller without calling this function.
> /* This only runs once on NOR flash */
> while (processed < count) {
> - rc = flash_bad_block (fd, mtd_type, &blockstart);
> + rc = flash_bad_block (fd, mtd_type, &blockstart, is_mtd);
Ditto.
> rc = flash_read_buf (dev, fd, data, write_total, erase_offset,
> - mtd_type);
> + mtd_type, is_mtd);
See my first comment. mtd_type can already tell us if we want to write
into a file or into a real mtd device, without adding an additional
parameter.
I have an additional question: if we want to add support to prepare the
environment on the host and to transfer later on the target, should we
not to care about the endianess ? I think the crc is written without
checking the endianess of the target. Does it work for powerpc (usually
big endian) when we run on a host PC ?
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
next prev parent reply other threads:[~2010-12-04 11:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-04 4:28 [U-Boot] [RFC 0/3] Enhance env tools Steve Sakoman
2010-12-04 4:28 ` [U-Boot] [RFC 1/3] tools/env: Default to the config specified in FW_CONFIG_FILE Steve Sakoman
2010-12-04 10:34 ` Mike Frysinger
2010-12-04 14:44 ` Steve Sakoman
2010-12-04 10:59 ` Stefano Babic
2010-12-04 14:43 ` Steve Sakoman
2010-12-04 4:28 ` [U-Boot] [RFC 2/3] tools/env: Support writing to files Steve Sakoman
2010-12-04 10:37 ` Mike Frysinger
2010-12-04 14:42 ` Steve Sakoman
2010-12-04 11:23 ` Stefano Babic [this message]
2010-12-04 14:48 ` Steve Sakoman
2010-12-05 0:05 ` Loïc Minier
2010-12-04 4:28 ` [U-Boot] [RFC 3/3] tools/env: Bump devname length to PATH_MAX for filenames Steve Sakoman
2010-12-04 20:35 ` [U-Boot] [RFC 0/3] Enhance env tools Wolfgang Denk
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=4CFA24A8.7030709@denx.de \
--to=sbabic@denx.de \
--cc=u-boot@lists.denx.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