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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox