freebsd-embedded@...

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/101228  embedded   [nanobsd] [patch] Two more entries for FlashDevice.sub
o misc/52256   embedded   [picobsd] picobsd build script does not read in user/s
o kern/42728   embedded   [picobsd] many problems in src/usr.sbin/ppp/*  after c
o misc/15876   embedded   [picobsd] PicoBSD message of the day problems

4 problems total.

How to support a TrueIDE (ATA) NANDrive chip

We have an SST NANDrive chip on our board that supports the simple ATA
command set. What's the easiest way to get support for this into our
kernel so we can partition and mount the device?

Using "da" and "umass" isn't really an option, since it is neither SCSI,
nor attached to USB. Pulling in all of "ata" seems like overkill; all we
really need is read/write block and some simple sense commands. They are
all synchronous, it's low traffic and we are more concerned with
simplicity than performance. Is there some subset of "ata" I can use
that won't involve pci bus, controllers, etc? We just want to be able to
write the LBA, SECT_CNT, and GO command and read the data.

--

Andrew Duane             Juniper Networks
978-589-0551             10 Technology Park Dr
aduane@...       Westford, MA  01886-3418

Looking to formalize board support in embedded platforms.

I've spent a little bit of time implementing the start of board files
for the arm port. The initial push has been for the at91 subport only,
and many improvements could be made to this. I've written up my
initial thoughts on this on the FreeBSD wiki
http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much
improvement, I'm sure.

One idea that hasn't been reflected there yet, was shown to me by Sam
Laffler who suggested using linker sets to allow boards to 'probe',
'init' and other standardized functions. This is an interesting idea
and I plan on working on adding it to the above links when Sam has
results to share.

I'd also like to expand the above wiki page to be a 'best practices'
guide for all architectures where there's great diversity of
boards/cpus/etc (eg, not the homogeneous env that x86 provides).

I'm also soliciting comments on the above boards in addition to the
above. Send them to me, or post them here.

Re: Looking to formalize board support in embedded platforms.

On Dec 4, 2008, at 11:37 PM, M. Warner Losh wrote:
> I've spent a little bit of time implementing the start of board files
> for the arm port. The initial push has been for the at91 subport only,
> and many improvements could be made to this. I've written up my
> initial thoughts on this on the FreeBSD wiki
> http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much
> improvement, I'm sure.
Some comments:
What is the point of a std.* file for every board, cant this be in the  
config file? I can understand the reason for having std.at91 and  
std.xscale that board configs can include to set cpu dependent  
options. But imo it would be cleaner to skip the std.* files for the  
boards.

"There's some suggestions that there be a separate "boards" directory.  
I'm not sure that I like it."
Depends on have many board we have, with 2 board it doesn't matter  
much, but with 10+ board all with a separate std.*, *.c and maybe  
files.* then its probably best to add the "boards" directory.

>
> One idea that hasn't been reflected there yet, was shown to me by Sam
> Laffler who suggested using linker sets to allow boards to 'probe',
> 'init' and other standardized functions. This is an interesting idea
> and I plan on working on adding it to the above links when Sam has
> results to share.
Sounds interesting

>
> I'd also like to expand the above wiki page to be a 'best practices'

Re: Looking to formalize board support in embedded platforms.

In message: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@...>
            Arnar Mar Sig <antab@...> writes:
: On Dec 4, 2008, at 11:37 PM, M. Warner Losh wrote:
: > I've spent a little bit of time implementing the start of board files
: > for the arm port. The initial push has been for the at91 subport only,
: > and many improvements could be made to this. I've written up my
: > initial thoughts on this on the FreeBSD wiki
: > http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much
: > improvement, I'm sure.
: Some comments:
: What is the point of a std.* file for every board, cant this be in the  
: config file? I can understand the reason for having std.at91 and  
: std.xscale that board configs can include to set cpu dependent  
: options. But imo it would be cleaner to skip the std.* files for the  
: boards.

The thinking here is that each of the board defines a certain set of
things that are standard for all users of that board, and that the
kernel config just stitches together the non-board specific parts for
the kernel.  Each of these boards may have slightly different load
addresses, and the like, and putting that in the kernels for the board
is very repetitive and error prone.

It is a hierarchy: boards define the most specific thing, and then
include the next more general thing (usually the SoC definitions),
which in turn includes the next more general thing (say, the family 
of devices) and so on until we get to the std.arm file which is what's
standard for all arm boards.

In any event, that's why it is there.  I'll keep track of your

Re: How to support a TrueIDE (ATA) NANDrive chip

On Thu, 4 Dec 2008 17:23:41 -0500
Andrew Duane <aduane@...> mentioned:

> We have an SST NANDrive chip on our board that supports the simple ATA
> command set. What's the easiest way to get support for this into our
> kernel so we can partition and mount the device?
> 
> Using "da" and "umass" isn't really an option, since it is neither SCSI,
> nor attached to USB. Pulling in all of "ata" seems like overkill; all we
> really need is read/write block and some simple sense commands. They are
> all synchronous, it's low traffic and we are more concerned with
> simplicity than performance. Is there some subset of "ata" I can use
> that won't involve pci bus, controllers, etc? We just want to be able to
> write the LBA, SECT_CNT, and GO command and read the data.
> 

Why not attach the ATA stack to the register space the chip provides.
Doesn't look like an overkill to me. It should work pretty well.
I'm using something like this for AT91 CF controller. I'v attached
it source, it might be useful to you. It's simple enough.

--

-- 
Stanislav Sedov
ST4096-RIPE

On Thu, 4 Dec 2008 17:23:41 -0500
Andrew Duane <aduane@...> mentioned:

i2c(8) diagnostic tool for review

This nice little program is helpful with inspecting an I2C bus, when bringing
up a new system, or just for diagnostic purposes:
http://people.freebsd.org/~raj/patches/misc/i2c.diff

Note the patch extends the /dev/iicX interface with a ioctl for the 'repeated
start' method.

More detailed description of the tool is in the manual page:
http://people.freebsd.org/~raj/patches/misc/i2c-man.txt

Any comments welcome.

Rafal

Re: How to support a TrueIDE (ATA) NANDrive chip

In message: <20081205113502.f9871231.stas@...>
            Stanislav Sedov <stas@...> writes:
: -----BEGIN PGP SIGNED MESSAGE-----
: Hash: SHA1
: 
: On Thu, 4 Dec 2008 17:23:41 -0500
: Andrew Duane <aduane@...> mentioned:
: 
: > We have an SST NANDrive chip on our board that supports the simple ATA
: > command set. What's the easiest way to get support for this into our
: > kernel so we can partition and mount the device?
: > 
: > Using "da" and "umass" isn't really an option, since it is neither SCSI,
: > nor attached to USB. Pulling in all of "ata" seems like overkill; all we
: > really need is read/write block and some simple sense commands. They are
: > all synchronous, it's low traffic and we are more concerned with
: > simplicity than performance. Is there some subset of "ata" I can use
: > that won't involve pci bus, controllers, etc? We just want to be able to
: > write the LBA, SECT_CNT, and GO command and read the data.
: > 
: 
: Why not attach the ATA stack to the register space the chip provides.
: Doesn't look like an overkill to me. It should work pretty well.
: I'm using something like this for AT91 CF controller. I'v attached
: it source, it might be useful to you. It's simple enough.

I'd concur.  I believe that we can configure the ata stuff such that
we don't get pci, et al, in this case.  If not, we should fix that.

Warner

Re: i2c(8) diagnostic tool for review

Looks good, though I haven't built or tested it. I've found smbmsg to be 
very useful, although of course if you are working with raw i2c, it's 
not useful.

I noticed that the x1226 clock chip doesn't seem to show up on the NSLUG 
atthe i2c address I'd expect it to, this will come in very useful for that.

I am doubtful I'll get free time to look at that right away-- I have new 
stuff brewing and want to try to hand off stuff where possible.

cheers
BMS

Re: i2c(8) diagnostic tool for review

On Fri, 05 Dec 2008 16:08:44 +0100
Rafal Jaworowski <raj@...> mentioned:

> This nice little program is helpful with inspecting an I2C bus, when bringing
> up a new system, or just for diagnostic purposes:
> http://people.freebsd.org/~raj/patches/misc/i2c.diff
> 
> Note the patch extends the /dev/iicX interface with a ioctl for the 'repeated
> start' method.
> 
> More detailed description of the tool is in the manual page:
> http://people.freebsd.org/~raj/patches/misc/i2c-man.txt
> 
> Any comments welcome.
> 

Great!
I haven't tried the tool itself yet, but there're some comments for
the source itself. Hopefully, it'll be useful.

> +The options are as follows:
> +.Bl -tag -width ".Fl d Ar direction"
> +.It Fl a Ar address
> +7-bit address on the I2C device to operate on (hex).
> +.It Fl f Ar device
> +I2C bus to use (default is /dev/iic0).
> +.It Fl d Ar r|w
> +transfer direction: r - read, w - write.
> +.It Fl w Ar 0|8|16
> +device addressing width (in bits).