From: Li Yang <leoli@motorola.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: jffs2+mtd+big endian problem
Date: 20 Jan 2004 12:20:47 +0800 [thread overview]
Message-ID: <1074572447.14559.23.camel@Gundam> (raw)
In-Reply-To: <1074510244.14499.49.camel@imladris.demon.co.uk>
On Mon, 2004-01-19 at 19:04, David Woodhouse wrote:
> On Mon, 2004-01-19 at 18:58 +0800, Li Yang wrote:
> > I have some problem accessing CVS from the damned corporate network.
>
> How strange. I can make the machine available for dialin if you want --
> it's funny how a few international phone calls make managers suddenly
> want to lean on incompetent IS staff to fix broken firewalls :)
Well, I hope i can do so. But I have to get a modem first. =)
>
> If you really can't even use CONNECT through an HTTP proxy, there are
> nightly snapshots at ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/
No, I can't use CONNECT through an HTTP proxy. I think they intend to
do so due to some *security* reason, anyway, the network is absolutely
not secure in my opinion. It's so kind of you to provide the snapshot.
>
> > The image generated by mkfs.jffs2 with -b seems ok, but it's not all
> > right after I done some operations on the target. In the bottom is the
> > log of these operations.
> >
> > Yes, I have examined a section which is formatted by the target board.
> > The first several bytes of the section are:
> >
> > fe3c0000: 03208519 0c000000 98dc60f0 ffffffff . ........`.....
> > fe3c0010: ffffffff ffffffff ffffffff ffffffff ................
> >
> > They are all 32-bit swapped. I traced into the JFFS2 code, and know it
> > use mtd->write to write data into flash. Which function is it turned
> > out to be finally? Is it the write defined in the drivers/mtd/maps/
> > files? I used __raw_write*() at the very beginning, it shouldn't be
> > like this.
>
> This sounds like you're using byte-swapping operations in your map
> driver. You should be using __raw_write*() not write*(). You said you
> were 'at the very beginning'... are you still doing that now?
I have verified my maps/ file. I'm using __raw_write*() now. Here is
part of my maps file, I don't know if the memcpy_toio() matters.
#define WINDOW_ADDR 0xfe000000
#define WINDOW_SIZE 0x800000
static struct mtd_partition physmap_partitions[] = {
/* Put your own partition definitions here */
{
name: "JFFS2",
size: 0x600000,
offset: 0,
}, {
name: "uImage",
size: 0x100000,
offset: 0x600000,
mask_flags: MTD_WRITEABLE, /* force read-only */
}, {
name: "u-boot",
size: 0x40000,
offset: 0x700000,
mask_flags: MTD_WRITEABLE, /* force read-only */
}, {
name: "u-boot env",
size: 0x40000,
offset: 0x740000,
mask_flags: MTD_WRITEABLE, /* force read-only */
}
};
#define NUM_PARTITIONS (sizeof(physmap_partitions)/sizeof(struct
mtd_partition))
static struct mtd_info *mymtd;
__u8 ads_read8(struct map_info *map, unsigned long ofs)
{
return __raw_readb(map->map_priv_1 + ofs);
}
__u16 ads_read16(struct map_info *map, unsigned long ofs)
{
return __raw_readw(map->map_priv_1 + ofs);
}
__u32 ads_read32(struct map_info *map, unsigned long ofs)
{
return __raw_readl(map->map_priv_1 + ofs);
}
void ads_copy_from(struct map_info *map, void *to, unsigned long from,
ssize_t len)
{
memcpy_fromio(to, (void *)(map->map_priv_1 + from), len);
}
void ads_write8(struct map_info *map, __u8 d, unsigned long adr)
{
__raw_writeb(d, map->map_priv_1 + adr);
mb();
}
void ads_write16(struct map_info *map, __u16 d, unsigned long adr)
{
__raw_writew(d, map->map_priv_1 + adr);
mb();
}
void ads_write32(struct map_info *map, __u32 d, unsigned long adr)
{
__raw_writel(d, map->map_priv_1 + adr);
mb();
}
void ads_copy_to(struct map_info *map, unsigned long to, const void
*from, ssize_t len)
{
memcpy_toio((void *)(map->map_priv_1 + to), from, len);
}
struct map_info ads_map = {
name: "Flash SIMM",
size: WINDOW_SIZE,
buswidth: 4,
read8: ads_read8,
read16: ads_read16,
read32: ads_read32,
copy_from: ads_copy_from,
write8: ads_write8,
write16: ads_write16,
write32: ads_write32,
copy_to: ads_copy_to
};
--
Thank you
Leo
next prev parent reply other threads:[~2004-01-20 4:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-19 8:43 jffs2+mtd+big endian problem Li Yang-r58472
2004-01-19 9:17 ` David Woodhouse
2004-01-19 9:48 ` Joakim Tjernlund
2004-01-19 10:58 ` Li Yang
2004-01-19 11:04 ` David Woodhouse
2004-01-20 4:20 ` Li Yang [this message]
2004-01-20 7:32 ` David Woodhouse
2004-02-04 8:11 ` Li Yang
2004-02-05 3:07 ` Li Yang
2004-02-05 7:00 ` David Woodhouse
2004-02-05 9:02 ` Li Yang
2004-02-05 9:27 ` David Woodhouse
2004-02-05 9:59 ` Li Yang
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=1074572447.14559.23.camel@Gundam \
--to=leoli@motorola.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
/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.