On Fri, May 3, 2013 at 5:08 PM, Marek Vasut ma...@denx.de wrote:
On 4/25/2013 6:13 PM, Marek Vasut wrote:
I didn't really track the thread and I'm plenty busy, besides I had
quite
a clash with Trent in another thread, sorry about me being plenty
unpleasant. Anyway, can you please sum
Dear Trent Piepho,
On Fri, May 3, 2013 at 5:08 PM, Marek Vasut ma...@denx.de wrote:
On 4/25/2013 6:13 PM, Marek Vasut wrote:
I didn't really track the thread and I'm plenty busy, besides I had
quite
a clash with Trent in another thread, sorry about me being plenty
Dear Paul B. Henson,
On 4/25/2013 6:13 PM, Marek Vasut wrote:
I didn't really track the thread and I'm plenty busy, besides I had quite
a clash with Trent in another thread, sorry about me being plenty
unpleasant. Anyway, can you please sum what is going on and what you
came up with?
On 4/25/2013 6:13 PM, Marek Vasut wrote:
I didn't really track the thread and I'm plenty busy, besides I had quite a
clash with Trent in another thread, sorry about me being plenty unpleasant.
Anyway, can you please sum what is going on and what you came up with?
Most of the analysis came
Dear Paul B. Henson,
On 4/25/2013 6:13 PM, Marek Vasut wrote:
I didn't really track the thread and I'm plenty busy, besides I had quite
a clash with Trent in another thread, sorry about me being plenty
unpleasant. Anyway, can you please sum what is going on and what you
came up with?
Dear Paul B. Henson,
On 4/19/2013 6:22 PM, Trent Piepho wrote:
Hmm, possibly; I guess that would be conceptually simpler but
require more commands to execute to get done.
Don't see why. If mxsboot wrote both files at once, there'd be the
same number of commands to generate them.
On 4/19/2013 6:22 PM, Trent Piepho wrote:
Hmm, possibly; I guess that would be conceptually simpler but
require more commands to execute to get done.
Don't see why. If mxsboot wrote both files at once, there'd be the
same number of commands to generate them.
Well, you'd have to copy two
On 4/11/2013 4:25 PM, Trent Piepho wrote:
Maybe it would make more sense for mxsboot to write two files? One
with the FCBs and one with everything else?
Hmm, possibly; I guess that would be conceptually simpler but require
more commands to execute to get done.
The FCBs are only 1036 byes
On Fri, Apr 19, 2013 at 6:03 PM, Paul B. Henson hen...@acm.org wrote:
On 4/11/2013 4:25 PM, Trent Piepho wrote:
Maybe it would make more sense for mxsboot to write two files? One
with the FCBs and one with everything else?
Hmm, possibly; I guess that would be conceptually simpler but
Dear Paul B. Henson,
Let me just preface this reply with the disclaimer that I'm fairly new
to embedded development, and it sounds like you know a lot more about
what you're talking about than I do ;).
[...]
I'm not reading the thread as it -- again -- contains loads of baseless is
broken
On Sat, Apr 13, 2013 at 7:42 AM, Marek Vasut ma...@denx.de wrote:
Dear Paul B. Henson,
Let me just preface this reply with the disclaimer that I'm fairly new
to embedded development, and it sounds like you know a lot more about
what you're talking about than I do ;).
[...]
I'm not reading
Dear Trent Piepho,
On Sat, Apr 13, 2013 at 7:42 AM, Marek Vasut ma...@denx.de wrote:
Dear Paul B. Henson,
Let me just preface this reply with the disclaimer that I'm fairly new
to embedded development, and it sounds like you know a lot more about
what you're talking about than I do
I don't think the image u-boot mxsboot generates includes any OOB
data. For me, it made an image which is *exactly* 24 blocks of 128
kiB each. If the FCB blocks had OOB data then there would need to
be some multiple of 64 OBB bytes in the image (16 kiB I would think).
I think maybe this is
On 4/11/2013 5:03 AM, Trent Piepho wrote:
I'm talking about the image file as generated by mxsimage. If I hex
dump that, it's clearly written entirely with 2048 byte pages. If
you hexdump your image are the FCB blocks exactly 128k apart?
Hmm, I don't have one in front of me to conveniently
On Thu, Apr 11, 2013 at 11:33 AM, Paul B. Henson hen...@acm.org wrote:
On 4/11/2013 5:03 AM, Trent Piepho wrote:
What one should actually do to flash these blocks is write 2048 bytes
in raw mode.
I guess that would only work if whatever reading the blocks also read them
in raw mode, as
Let me just preface this reply with the disclaimer that I'm fairly new
to embedded development, and it sounds like you know a lot more about
what you're talking about than I do ;).
On 4/6/2013 12:18 AM, Trent Piepho wrote:
Did you already have the bad sectors when you burnt under Linux? I
On Apr 5, 2013 9:28 PM, Paul B. Henson hen...@acm.org wrote:
On 4/4/2013 3:09 AM, Trent Piepho wrote:
It's something to do with the way u-boot writes to nand. If I write
with nandwrite it doesn't happen, nandtest doesn't find any bad
Hmm, I'm pretty sure I tested burning the u-boot
On 4/4/2013 3:09 AM, Trent Piepho wrote:
It's something to do with the way u-boot writes to nand. If I write
with nandwrite it doesn't happen, nandtest doesn't find any bad
Hmm, I'm pretty sure I tested burning the u-boot generated nand image
with nandwrite under Linux with exactly the same
On Mon, Mar 18, 2013 at 5:50 PM, Paul B. Henson hen...@acm.org wrote:
I'm prototyping a project that's going to need to boot linux from NAND on a
mx28evk board.
I was able to successfully use the u-boot mxsboot utility to generate a nand
image and burn it, then boot from it. I noticed one
On Tue, Mar 19, 2013 at 06:23:27PM -0500, Scott Wood wrote:
I don't think this is having any functional impact, as the scrub
component of burning a new nand image wipes out the bad blocks,
You should not be routinely scrubbing NAND!
The manufacturers put bad block information there
On 03/20/2013 04:20:07 PM, Paul B. Henson wrote:
On Tue, Mar 19, 2013 at 06:23:27PM -0500, Scott Wood wrote:
I don't think this is having any functional impact, as the scrub
component of burning a new nand image wipes out the bad blocks,
You should not be routinely scrubbing NAND!
The
On 03/18/2013 07:50:07 PM, Paul B. Henson wrote:
I'm prototyping a project that's going to need to boot linux from
NAND on a mx28evk board.
I was able to successfully use the u-boot mxsboot utility to generate
a nand image and burn it, then boot from it. I noticed one anomaly
though, when
I'm prototyping a project that's going to need to boot linux from NAND
on a mx28evk board.
I was able to successfully use the u-boot mxsboot utility to generate a
nand image and burn it, then boot from it. I noticed one anomaly though,
when using mxsboot/u-boot to generate and burn the
23 matches
Mail list logo
