Brian Rose | 1 Feb 18:28 2005
Picon

Open Source USB code


Does anyone know where to find some generic code for driving USB lines? 
Several of the bridge chips we are using now appear to be 8051 controllers 
with some built in firmware. If I could roll my own USB controller, I could 
  consoldate several parts into one.

I know this is not on topic for this list, but this list is pretty active 
with embedded developers.

--

-- 

Brian

Werner Backes | 1 Feb 19:10 2005
Picon

Re: Open Source USB code


Brian Rose wrote:
> Does anyone know where to find some generic code for driving USB lines? 

I don't know if it's possible to do this entirely in software.
Apart from that, there are controllers out there with integrated
USB functions which make things a lot easier. Cypress (www.cypress.com)
for example has some nice chips but there should be other companies
with similiar products.

Werner

Alexander Yurchenko | 1 Feb 22:41 2005
Picon
Picon

Re: Open Source USB code

On Tue, Feb 01, 2005 at 12:28:54PM -0500, Brian Rose wrote:
> 
> Does anyone know where to find some generic code for driving USB lines? 
> Several of the bridge chips we are using now appear to be 8051 controllers 
> with some built in firmware. If I could roll my own USB controller, I could 

seen this?
http://www.opencores.org/browse.cgi/filter/category_commctrl

>  consoldate several parts into one.
> 
> I know this is not on topic for this list, but this list is pretty active 
> with embedded developers.
> 
> 
> -- 
> 
> Brian

--

-- 
   Alexander Yurchenko (aka grange)

Jesse Off | 4 Feb 17:37 2005

wscons on a HD44780

I just committed support for wsdisplay(4) attachments to Hitachi HD44780
text mode LCD controllers.  Any doubts as to whether the wscons framework
would scale down to embedded consoles can now be put to rest.  Seeing
wscons working on a 200Mhz ARM TS-7200 embedded board w/24x2 LCD with a
16-button matrix keypad using the generic matrix keypad wskbd(4) driver
(committed earlier this week) is a tribute to NetBSD's clean design and
viability in the embedded space.

Having wscons working for this provides embedded application developers
the ability to rapidly prototype and simulate embedded applications that
will use a matrix keypad and HD44780 display in the field on a regular
serial/telnet console and keyboard.  It also becomes possible, for
instance, to run a getty and shell on an additional virtual LCD wsdisplay
that can be accessed by plugging in a USB ukbd(4) and hitting Ctrl-F2 to
switch consoles just like on NetBSD's other ports.  The only quirks the
above login-session/shell would have are those that one would expect with
only 24x2 characters instead of the traditional 80x25, but would be
perfect for enabling out-of-band features for system integrators for
(e.g.) field updates or initial system configuration.

About the HD44780 display:
HD44780's are ubiquitous in the embedded world and are found in
backlit/non-backlit configurations from 16x1 characters (around $7) to
40x4 characters (around $24).  These displays are very commonly attached
to microcontrollers such as PIC's or Atmel AVR's.  The typical NetBSD user
probably knows of them through the server-monitoring style applications
catered to by such open-source projects as LCDproc.

About the matrix keypad:
Matrix keypads are small and rugged input devices resembling a keyboard
(Continue reading)

Hubert Feyrer | 4 Feb 18:06 2005
Picon

Re: wscons on a HD44780

On Fri, 4 Feb 2005, Jesse Off wrote:
> I just committed support for wsdisplay(4) attachments to Hitachi HD44780
> text mode LCD controllers.  Any doubts as to whether the wscons framework
> would scale down to embedded consoles can now be put to rest.  Seeing
> wscons working on a 200Mhz ARM TS-7200 embedded board w/24x2 LCD with a
> 16-button matrix keypad using the generic matrix keypad wskbd(4) driver
> (committed earlier this week) is a tribute to NetBSD's clean design and
> viability in the embedded space.

Way cool. Do you have some pix?

Would be nice to show a getty session or similar on our galery/screenshot 
section!

  - Hubert (typing over slow modem line)

>
> Having wscons working for this provides embedded application developers
> the ability to rapidly prototype and simulate embedded applications that
> will use a matrix keypad and HD44780 display in the field on a regular
> serial/telnet console and keyboard.  It also becomes possible, for
> instance, to run a getty and shell on an additional virtual LCD wsdisplay
> that can be accessed by plugging in a USB ukbd(4) and hitting Ctrl-F2 to
> switch consoles just like on NetBSD's other ports.  The only quirks the
> above login-session/shell would have are those that one would expect with
> only 24x2 characters instead of the traditional 80x25, but would be
> perfect for enabling out-of-band features for system integrators for
> (e.g.) field updates or initial system configuration.
>
> About the HD44780 display:
(Continue reading)

Jesse Off | 5 Feb 00:41 2005

Re: TS-72xxx flash and NetBSD

I'm Cc'ing this to the tech-kern <at> netbsd.org mailing list in order to 
hopefully solicit a few other expert opinions on the subject.

I haven't implemented anything for the onboard TS72xx flash support because 
the best course of action isn't yet perfectly clear (to me anyway).  I know 
what I'd like to see avoided in an implementation, but don't yet have a good 
plan of action to offer that would avoid all the chaos thats currently in 
Linux in the form of "MTD" drivers and special filesystems unique to each 
type of flash chip (JFFS2, YAFFS, YAFFS2, FTL/EXT2, NFTL/EXT2, etc).  There 
are certain things unique about using direct mapped NAND/NOR flash (as 
opposed to something like CF, or USB flash which has an onboard controller), 
but a completely new filesystem (and one also for each type and variant of 
chip) seems a bit overkill.  Some ideas:

* Come up with some sort of  "unreliable/quirky block device" layer that can 
be used to implement the same sort of internal logic already present in 
devices like CompactFlash and hard drives such that a regular FFS filesystem 
could be placed on it.  Devices (512B NAND, NOR, 2KB NAND) simply register 
some generic block device access functions and their quirks with this layer, 
and then a regular FFS filesystem could be placed on the "de-quirked" block 
device.  The de-quirking driver has all the intelligence of filesystem 
agnostic wear-leveling, ECC generation/checking, and bad block management 
(by reserving a driver-defined percentage of blocks)

* Perhaps 1) extend ffs's block allocation policy to be random within free 
space, (with preference to a sector already erased or in an area already 
marked for erase/rewrite) 2) force block rewrites to go through a block 
reallocation instead of using the same block, 3) rate-limit/aggressively 
buffer FS metadata (inode, block bitmap, etc) writes.  This would still have 
issue w/NAND for bad block management, and having to erase/rewrite an entire 
(Continue reading)

David Laight | 5 Feb 10:37 2005
Picon

Re: TS-72xxx flash and NetBSD

On Fri, Feb 04, 2005 at 04:41:00PM -0700, Jesse Off wrote:
> I'm Cc'ing this to the tech-kern <at> netbsd.org mailing list in order to 
> hopefully solicit a few other expert opinions on the subject.
> 
> I haven't implemented anything for the onboard TS72xx flash support because 
> the best course of action isn't yet perfectly clear (to me anyway).  I know 
> what I'd like to see avoided in an implementation, but don't yet have a 
> good plan of action to offer that would avoid all the chaos thats currently 
> in Linux in the form of "MTD" drivers and special filesystems unique to 
> each type of flash chip (JFFS2, YAFFS, YAFFS2, FTL/EXT2, NFTL/EXT2, etc).  
> There are certain things unique about using direct mapped NAND/NOR flash 
> (as opposed to something like CF, or USB flash which has an onboard 
> controller), but a completely new filesystem (and one also for each type 
> and variant of chip) seems a bit overkill.  Some ideas:

Faced with a similar problem for an embedded device, I did wrote a block
driver with a cache that had the following (rather unusual) properties:

1) Reads return data from the cache, but reads are not saved in the cache
   (ie they ususally read from the media)

2) Write follow the following algorith:
2a) If the write sector is cached, update the cache
2b) If the write can be done without erasing the existing sector,
    then just update then flash memory (eg if data unchanged, or only
    changes convert '1' bits to '0').
2c) If the 'sector' cache isn't full, save the write in the cache.
2d) Erase the flash associated with the cached flash block (maybe 128k)
    and write back that cache entry.
2e) Select the flash block that has the most cached (modified) sectors
(Continue reading)

Francis Dupont | 5 Feb 11:29 2005
Picon
Picon

Re: TS-72xxx flash and NetBSD

 In your previous mail you wrote:

   I'm Cc'ing this to the tech-kern <at> netbsd.org mailing list in order to 
   hopefully solicit a few other expert opinions on the subject.

=> I've registered it in order to avoid extra work to its moderator.

   I haven't implemented anything for the onboard TS72xx flash support
   because the best course of action isn't yet perfectly clear (to me
   anyway).  I know what I'd like to see avoided in an implementation,
   but don't yet have a good plan of action to offer that would avoid all
   the chaos thats currently in Linux in the form of "MTD" drivers and
   special filesystems unique to each type of flash chip (JFFS2, YAFFS,
   YAFFS2, FTL/EXT2, NFTL/EXT2, etc).  There are certain things unique
   about using direct mapped NAND/NOR flash (as opposed to something like
   CF, or USB flash which has an onboard controller), but a completely
   new filesystem (and one also for each type and variant of chip) seems
   a bit overkill.  Some ideas:

   * Come up with some sort of "unreliable/quirky block device" layer

=> I believe we need at least this in order to be able to use dd to
read and write the flash. BTW sys/arch/hpcmips/vr has a CIF driver.

   that can be used to implement the same sort of internal logic
   already present in devices like CompactFlash and hard drives such that
   a regular FFS filesystem could be placed on it.  Devices (512B NAND,
   NOR, 2KB NAND) simply register some generic block device access
   functions and their quirks with this layer, and then a regular FFS
   filesystem could be placed on the "de-quirked" block device.  The
(Continue reading)

Sami Kantoluoto | 5 Feb 14:48 2005
Picon

arm, net and '__attribute__ ((__packed__))'

Hi,

We're using the network stack and wi driver ported from NetBSD to our
embedded operating system and I'm wondering if there's something wrong with
missing '__attribute__ ((__packed__))'s or something. So, I noticed that
'sizeof(struct llc)' returned 10 (arm-elf-gcc 3.4.2). Then I removed the
comments (and 'XXX' and '???') from 'llc_un'. Which means:

struct llc {
	u_int8_t llc_dsap;
	u_int8_t llc_ssap;
	union {
		.
		.
		.
	} llc_un __attribute__((__packed__));
} __attribute__((__packed__));

This had no effect. Then I swapped 'llc_un' and
'__attribute__((__packed__))' and it worked (sizeof(struct llc) == 8). So:

struct llc {
	u_int8_t llc_dsap;
	u_int8_t llc_ssap;
	union {
		.
		.
		.
	} __attribute__((__packed__)) llc_un;
} __attribute__((__packed__));
(Continue reading)

Richard Earnshaw | 5 Feb 15:04 2005
Picon
Picon

Re: arm, net and '__attribute__ ((__packed__))'

On Sat, 05 Feb 2005 15:48:39 +0200, Sami Kantoluoto wrote:
> Hi,
> 
> We're using the network stack and wi driver ported from NetBSD to our
> embedded operating system and I'm wondering if there's something wrong with
> missing '__attribute__ ((__packed__))'s or something. So, I noticed that
> 'sizeof(struct llc)' returned 10 (arm-elf-gcc 3.4.2). Then I removed the
> comments (and 'XXX' and '???') from 'llc_un'. Which means:
> 
> struct llc {
> 	u_int8_t llc_dsap;
> 	u_int8_t llc_ssap;
> 	union {
> 		.
> 		.
> 		.
> 	} llc_un __attribute__((__packed__));
> } __attribute__((__packed__));
> 
> This had no effect. Then I swapped 'llc_un' and
> '__attribute__((__packed__))' and it worked (sizeof(struct llc) == 8). So:
> 
> struct llc {
> 	u_int8_t llc_dsap;
> 	u_int8_t llc_ssap;
> 	union {
> 		.
> 		.
> 		.
> 	} __attribute__((__packed__)) llc_un;
(Continue reading)


Gmane