Dear Trent Piepho,
> On Fri, May 3, 2013 at 5:08 PM, Marek Vasut 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
> > > >
On Fri, May 3, 2013 at 5:08 PM, Marek Vasut 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 wh
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 w
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 w
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 from
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 generat
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 fil
On Fri, Apr 19, 2013 at 6:03 PM, Paul B. Henson 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 require more
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 l
Dear Trent Piepho,
> On Sat, Apr 13, 2013 at 7:42 AM, Marek Vasut 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 ;)
On Sat, Apr 13, 2013 at 7:42 AM, Marek Vasut 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 t
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
broke
On Thu, Apr 11, 2013 at 11:33 AM, Paul B. Henson 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 otherwise
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
>> 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
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
hadn
On Apr 5, 2013 9:28 PM, "Paul B. Henson" 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 generated
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 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 thoug
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!
>
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 t
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 bootstr
23 matches
Mail list logo