Re: NOR Flash Support (U-Boot env)

Andy Green wrote:
> They can DFU-update to a contemporary GTA-01 U-Boot and
they're away
> again, if I understood you.

Not quite. They mainly have to edit and update their
environment.
If Linux user space references any partitions, that would
have to
be edited as well.

So this would be the type of change that causes all sorts of
upset.

> My point is that the even more ultimate goal is to get
a production
> version out.

Sure, but if you create weeks of extra work to save a couple
of
hours, that's not good either.

> For example I don't have a GTA-01 and I can't test what
I
> am putting out for GTA-01...

Well, just don't actively break anything. It's easy to fix
things
that might slip through. It's hard to fix things if the
breakage
has become a design goal.

> If the future is kind that can work fine.  Or it can
turn into an
> impenetrable #ifdef forest 

I'm looking forward to the day when the devirginator has to
support
a dozen different product lines )

The enhanced envedit.pl is in SVN revision 3729. I've also
added
macro expansion, just in case.

- Werner

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> Andy Green wrote:
>> They can DFU-update to a contemporary GTA-01 U-Boot
and they're away
>> again, if I understood you.
> 
> Not quite. They mainly have to edit and update their
environment.

They are in a position to do this with minicom.  In short
they need to
read a wiki page about it, but it doesn't brick them.

> If Linux user space references any partitions, that
would have to
> be edited as well.

On the userspace that I inherited from Willie, which I think
is pretty
common, only /dev/root -> / is used, ie, no changes to
/etc/fstab are
required once the U-Boot -> kernel commandline magic is
done, userspace
just comes up fine.  BTW the U-Boot envs I see on the boards
I got bear
zero relationship to your environment.in, so environment.in
is not
getting tested in my (limited) experience.

>> My point is that the even more ultimate goal is to
get a production
>> version out.
> 
> Sure, but if you create weeks of extra work to save a
couple of
> hours, that's not good either.

Inbetween our causing some poor guy "weeks" of
work while we eat grapes
peeled for us by beautiful maidens; and our trying to
shoulder the
weight of multiple worlds while staggering forwards: there
is a sweet
spot where we can stride briskly on and the load on the
GTA-01
backporter is light.

>> For example I don't have a GTA-01 and I can't test
what I
>> am putting out for GTA-01...
> 
> Well, just don't actively break anything. It's easy to
fix things
> that might slip through. It's hard to fix things if the
breakage
> has become a design goal.

Breaking GTA-01 per se doesn't buy me anything, my point is
rather that
ignoring it might, when an able GTA-01 person has our
continuous working
GTA-02 patches to start from.

>> If the future is kind that can work fine.  Or it
can turn into an
>> impenetrable #ifdef forest 
> 
> I'm looking forward to the day when the devirginator
has to support
> a dozen different product lines )

I would get a case of brandy just in case, either way it is
going to
help 

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


iD8DBQFHb8q3OjLpvpq7dMoRAoIlAJ9r1M596iKBlLAoCUo+Dz+N7qs9PACf
WPWC
qOPsT2+fSOjw7+MSCmN0OAk=
=p5UL
-----END PGP SIGNATURE-----