Thread: blob release?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Is there a schedule for the next blob release?  Just asking out of =
curiosity.  The current cvs tree looks quite solid to me -- except for =
serial-typeahead-hang bug.

-ch

Hi Christopher!

> Is there a schedule for the next blob release?  Just asking out of
> curiosity.  The current cvs tree looks quite solid to me -- except for
> serial-typeahead-hang bug. =20

It still doesn't boot on my board though :P

--=20

Regards
 Abraham

Adopted kids are such a pain -- you have to teach them how to look like you=
 ...
		-- Gilda Radner

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: ab...@2d...         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

On Tue, Mar 12, 2002 at 05:03:47PM -0800, Christopher Hoover wrote:
> Is there a schedule for the next blob release?  Just asking out of
> curiosity.  The current cvs tree looks quite solid to me -- except
> for serial-typeahead-hang bug.

I usually release a new version when there are no knowm major bugs.
Right now we have the following issues still open:
- serial-typeahead bug fixed
- flash partitioning
- parameter block support

The development snapshots turn out to be very popular[1], and I think
we should release a new snapshot Real Soon Now[tm]. Objections?

Erik

[1] https://sourceforge.net/project/showfiles.php?group_id=30155

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/

- Unexplained occasional slow erases for AMD flash - Russ?
- occasional erases of the wrong partition!

once in a while when I flash a root image and a kernel image on a
shannon the blob partition is erased. I don't know why this happens. It
does not seem to happen nearly as often if I soft reboot between each
flash.

- strange flash error messages.

lock a block, write to it, you get errors. Unlock it, still error
messages. flash to it, still error messages. check it, it all worked.
The first write fails, the unlock and the second write succeed, but give
error messages.

- xmodem padding.

jffs2 uploads appear to be padded with 0x1a and so mess up jffs2 when it
tries to mark the rest of the upload block. Don't know if 0x1a can be
relied on. Perhaps we can search for 8 or more of the same byte at the
end of the last block and change them all to 0xff if found? then set the
length to this guess value and perhaps md5sums would work again? Perhaps
an upgraded protocol with length info should be implemented instead?

I'd like to see a faster boot unless keypress option (if not the
default)

Erik Mouw wrote:
> I usually release a new version when there are no knowm major bugs.
> Right now we have the following issues still open:
> - serial-typeahead bug fixed

fixed? or needs to be?

> - flash partitioning
> - parameter block support

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

On Fri, Apr 12, 2002 at 04:13:32AM -0600, Tim Riker wrote:
> - Unexplained occasional slow erases for AMD flash - Russ?

Haven't seen it happening on my Tux.

> - occasional erases of the wrong partition!
> 
> once in a while when I flash a root image and a kernel image on a
> shannon the blob partition is erased. I don't know why this happens. It
> does not seem to happen nearly as often if I soft reboot between each
> flash.

Never seen it, but it shouldn't happen. I think it can be because we
left the flash not in read array mode. Might be related to the previour
problem.

> - strange flash error messages.
> 
> lock a block, write to it, you get errors. Unlock it, still error
> messages. flash to it, still error messages. check it, it all worked.
> The first write fails, the unlock and the second write succeed, but give
> error messages.

With what kind of flash? Intel or AMD?

> - xmodem padding.
> 
> jffs2 uploads appear to be padded with 0x1a and so mess up jffs2 when it
> tries to mark the rest of the upload block. Don't know if 0x1a can be
> relied on. Perhaps we can search for 8 or more of the same byte at the
> end of the last block and change them all to 0xff if found? then set the
> length to this guess value and perhaps md5sums would work again? Perhaps
> an upgraded protocol with length info should be implemented instead?

That's because xmodem has no way to tell the receiver the exact
filesize. It only sends complete blocks, and pads them with whatever it
likes. Either we have to implement ymodem (which is basically xmodem
with 1k blocks, multiple files, and file attributes like name and
length), or you have to pad the file you want to upload with dd (dd
if=orig of=new bs=1k conv=sync).

> I'd like to see a faster boot unless keypress option (if not the
> default)

That's easy to change in the param block.

> Erik Mouw wrote:
> > I usually release a new version when there are no knowm major bugs.
> > Right now we have the following issues still open:
> > - serial-typeahead bug fixed
> 
> fixed? or needs to be?

Needs to be.

Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/

> - strange flash error messages.
>
> lock a block, write to it, you get errors. Unlock it, still error
> messages. flash to it, still error messages. check it, it all worked.
> The first write fails, the unlock and the second write succeed, but give
> error messages.

(I think) I fixed this for intel16 and intel32 a few weeks ago.  AFAIK the
intel16 and intel32 flash support is bug free.  If you are having trouble
with the code on the CVS trunk, please send details.

I don't have any devices with amd flash, otherwise I'd tackle that.

-ch
mailto:ch...@hp...
mailto:ch...@mu...

http://www.murgatroid.com/

Thread: blob release?

blob-cvs-commit