From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/4] OneNAND: Add simple OneNAND SPL
Date: Mon, 31 Oct 2011 18:15:20 -0500 [thread overview]
Message-ID: <4EAF2C08.7060901@freescale.com> (raw)
In-Reply-To: <1320067393-18822-4-git-send-email-marek.vasut@gmail.com>
On 10/31/2011 08:23 AM, Marek Vasut wrote:
> +inline uint16_t onenand_readw(uint32_t addr)
> +{
> + return readw(CONFIG_SYS_ONENAND_BASE + addr);
> +}
> +
> +inline void onenand_writew(uint16_t value, uint32_t addr)
> +{
> + writew(value, CONFIG_SYS_ONENAND_BASE + addr);
> +}
static
> +#define onenand_block_address(block) (block)
> +#define onenand_sector_address(page) (page << 2)
> +#define onenand_buffer_address() ((1 << 3) << 8)
> +#define onenand_bufferram_address(block) (0)
Space rather than tab after #define
> +void spl_onenand_get_geometry(struct spl_onenand_data *data)
> +{
> + uint32_t tmp;
> + uint32_t dev_id, density;
> +
> + /* Default geometry -- 2048b page, 128k erase block. */
> + data->pagesize = 2048;
> + data->erasesize = 0x20000;
> +
> + tmp = onenand_readw(ONENAND_REG_TECHNOLOGY);
> + if (tmp)
> + goto dev_4k;
> +
> + dev_id = onenand_readw(ONENAND_REG_DEVICE_ID);
> + density = dev_id >> ONENAND_DEVICE_DENSITY_SHIFT;
> + density &= ONENAND_DEVICE_DENSITY_MASK;
> +
> + if (density < ONENAND_DEVICE_DENSITY_4Gb)
> + return;
> +
> + if (dev_id & ONENAND_DEVICE_IS_DDP)
> + return;
> +
> + /* 4k device geometry -- 4096b page, 256k erase block. */
> +dev_4k:
> + data->pagesize = 4096;
> + data->erasesize = 0x40000;
> +}
This seems like a gratuitous use of goto...
> +int spl_onenand_read_block(uint32_t block, uint8_t *buf, uint32_t *read)
> +{
> + struct spl_onenand_data data;
> + uint32_t page;
> + int ret;
> +
> + spl_onenand_get_geometry(&data);
> +
> + for (page = 0; page < ONENAND_PAGES_PER_BLOCK; page++) {
> + ret = spl_onenand_read_page(block, page, buf, data.pagesize);
> + if (ret)
> + return ret;
> + buf += data.pagesize;
> + }
Shouldn't this do bad block skipping rather than error on the first bad
block it sees? The current onenand IPL does this.
> + *read = ((block * ONENAND_PAGES_PER_BLOCK) + page) * data.pagesize;
We only read one block here, but we return the byte address of the next
block? A little odd, and if it's really what's intended, needs to be
documented.
> diff --git a/include/onenand_uboot.h b/include/onenand_uboot.h
> index 92279d5..66828ce 100644
> --- a/include/onenand_uboot.h
> +++ b/include/onenand_uboot.h
> @@ -16,6 +16,8 @@
>
> #include <linux/types.h>
>
> +#ifndef CONFIG_SPL_BUILD
> +
> /* Forward declarations */
> struct mtd_info;
> struct mtd_oob_ops;
> @@ -52,4 +54,20 @@ extern int flexonenand_set_boundary(struct mtd_info *mtd, int die,
> extern void s3c64xx_onenand_init(struct mtd_info *);
> extern void s3c64xx_set_width_regs(struct onenand_chip *);
>
> +#else
> +
> +#define ONENAND_PAGES_PER_BLOCK 64
> +
> +struct spl_onenand_data {
> + uint32_t pagesize;
> + uint32_t erasesize;
> +};
> +
> +void spl_onenand_get_geometry(struct spl_onenand_data *data);
> +int spl_onenand_read_page(uint32_t block, uint32_t page,
> + uint8_t *buf, int pagesize);
> +int spl_onenand_read_block(uint32_t block, uint8_t *buf, uint32_t *read);
> +
> +#endif
Do these really need to be #ifdeffed?
-Scott
next prev parent reply other threads:[~2011-10-31 23:15 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-31 13:23 [U-Boot] [PATCH 0/4] Voipac PXA270 OneNAND SPL Marek Vasut
2011-10-31 13:23 ` [U-Boot] [PATCH 1/4] PXA: Drop Voipac PXA270 OneNAND IPL Marek Vasut
2011-10-31 13:23 ` [U-Boot] [PATCH 2/4] PXA: Rework start.S to be closer to other ARMs Marek Vasut
2011-11-01 22:53 ` [U-Boot] [PATCH 2/4 V2] " Marek Vasut
2011-11-02 9:01 ` [U-Boot] [PATCH 2/4] " Stefan Herbrechtsmeier
2011-11-02 10:25 ` Marek Vasut
2011-11-02 10:53 ` Stefan Herbrechtsmeier
2011-10-31 13:23 ` [U-Boot] [PATCH 3/4] OneNAND: Add simple OneNAND SPL Marek Vasut
2011-10-31 23:15 ` Scott Wood [this message]
2011-11-01 22:54 ` [U-Boot] [PATCH 3/4 V2] " Marek Vasut
2011-11-02 22:41 ` Scott Wood
2011-11-03 0:15 ` Marek Vasut
2011-11-03 0:36 ` Kyungmin Park
2011-11-03 0:59 ` Marek Vasut
2011-11-03 16:19 ` Scott Wood
2011-11-03 16:56 ` Marek Vasut
2011-11-03 17:06 ` Scott Wood
2011-11-03 17:25 ` Marek Vasut
2011-11-03 1:55 ` [U-Boot] [PATCH 3/4 V3] " Marek Vasut
2011-11-03 21:59 ` [U-Boot] [PATCH 3/4 V4] " Marek Vasut
2011-10-31 13:23 ` [U-Boot] [PATCH 4/4] PXA: Adapt Voipac PXA270 to " Marek Vasut
2011-10-31 23:03 ` Scott Wood
2011-11-01 22:12 ` Marek Vasut
2011-11-01 22:34 ` Scott Wood
2011-11-01 22:44 ` Marek Vasut
2011-11-02 22:18 ` Scott Wood
2011-11-01 22:54 ` [U-Boot] [PATCH 4/4 V2] " Marek Vasut
2011-11-02 22:23 ` Scott Wood
2011-11-03 1:56 ` [U-Boot] [PATCH 4/4 V3] " Marek Vasut
2011-11-03 18:09 ` Scott Wood
2011-11-03 21:52 ` Marek Vasut
2011-11-03 22:20 ` Scott Wood
2011-11-04 0:55 ` Marek Vasut
2011-11-04 16:37 ` Scott Wood
2011-11-04 20:07 ` Marek Vasut
2011-11-04 20:13 ` Scott Wood
2011-11-04 20:31 ` Marek Vasut
2011-11-05 22:40 ` Marek Vasut
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=4EAF2C08.7060901@freescale.com \
--to=scottwood@freescale.com \
--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