Re: How to get a device_t

[John Birrell]

On Wed, Aug 06, 2003 at 07:45:32PM -0600, M. Warner Losh wrote:
> Well, I don't know.  The PC Cards that we have in the system are
> mapped into the I/O and memory ranges traditionally reserved for the
> ISA bus.  In ISA systems, this made sense because pccard was attached
> to pcic was attached to isa.  However, now we have situations where
> pccard is attached to cbb which is attached to pci.  There may be a
> isab device with isa bus hanging off of it that makes the relationship
> between the pccard devices cousins rather than nephews in the tree.
> And there isn't any harm from that.  Wouldn't this be a similar
> situation?

The flash I'm talking about is not pccard related. Sorry if I gave that
impression. The SC520 has onboard support to control 3 flash chips.
The board I have has 2 Mb NOR flash chip containing BIOS plus a DOS
file system (at the moment) where I keep a copy of an etherboot
executable. The board also has a 64Mb NAND flash chip which I've
written a FreeBSD UFS image into. Our standard bootloader happily
loads the kernel from that. Now I need to get a flash driver working
for the root file system. I've got an existing read-only flash driver
that I used to use on an Intel 386EX board, but that had the entire
flash chip memory mapped. This new board maps the NAND flash in 4K
pages.

> : >From my reading of the AMD docs, only the CPU core is identifiable
> : via the CPUID instruction. The docs say that the first two bytes of
> : the MMCR are the REVID and those can be used to "identify the device
> : itself". The second byte is set to zero to "identify the product as
> : the ElanSC520 microcontroller".  So if you know the MMCR is there,
> : you can go to that byte and get confirmation!  Thanks AMD. It seems
> : that the discovery via the host to PCI bridge is the only reliable
> : way to go.
> 
> Can you send me a URL for that document?  I thought I understood
> things, but making sure by reading it would sure help.

This URL lists the relevent docs:



The ones you want are the "ElanSC520 Users Manual" and "ElanSC520
Register Set Manual"

>From what I can see, all the SC520 specific things are accessed via
the MMCR registers. The direct mapped registers are only for PC/AT
compatible stuff, so they are of no help. Then there are the PCI
things. To be PCI compatible, AMD *had* to give the host bridge a
device ID. That is the _only_ thing given an ID.

> But adding it as a child of nexus in the host bridge code wouldn't
> make it probe any earlier.  To do that you'd need to make it a true
> child of nexus with a identify routine that would go out and try to
> find the host bridge at a certain address and use the right kind of
> bridge there to add the device.  You could then map the mmcr space to
> a convenient location, and then dole it out to child drivers such that
> the bus_space macros would do the right thing.  Since it is memory
> mapped, this would be relatively easy to do.  This would also allow
> you to make it known earlier in the boot process.  This is also very
> much analygous to what pccard and cardbus does.  You wouldn't have the
> problems that we have with picking resources in the cardbus bridge
> code because it looks like the mmcr is at a fixed address (either by
> design of the chip or by phk's big stick).
> 
> If you'd like, I can sketch out in code what I'm trying to say in
> words here.

If you have time, I'd be interested. This is a hot topic for me because
it is exactly where I'm up to. I have everything else working on the
board.

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: In fact what you may want to do is hang the entire MMCR off the nexus
: as a bus, and hang the various drivers off that bus.

That certainly makes sense.  nexus is for things that hang off of the
CPU or things directly connected to the cpu...

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: possible deadlocks?

[Robert Watson]

On Wed, 6 Aug 2003, Ted Unangst wrote:

> My advisor Dawson Engler has written a deadlock detector, and we'd like
> some verification. They look like bugs, unless there is some other
> reason why two call chains cannot happen at the same time. 

Neat -- sounds like two good catches given the responses so far.  Can we
expect more such reports forthcoming?  This kind of help will be
invaluable in finishing up the fine-grained locking work.  Alternatively,
do you plan to post the software?  Is this static or dynamic analysis? 
etc, etc?  :-)

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[John Baldwin]

On 07-Aug-2003 M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Bernd Walter <[EMAIL PROTECTED]> writes:
>: The host bridge is not available yet at probing time of the host bridge.
>: What we have is the host bridges parent (nexus) in the calling function.
>: Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or
>: we find it out later.
> 
> Don't you mean legacy_pcib_is_host_bridge?  That's where the matching
> is done in current right now (well, at least as of my last sync) If
> so, passing the host bridge's device down to it would be trivial to
> add.  It would also allow other CPUs with builtin host bridges to do
> similar tricks to the one that is done for the ELAN.  These sorts of
> features have been very common in other CPU families, and there's no
> reason to think that there won't be more of them in the x86 family as
> time goes on.
> 
> I'm not sure that adding it to nexus at this stage of the boot would
> truly work.  Since the legacy device has decided to attach, the nexus
> bus is already walking through its children.  Adding a child during
> that walk strikes me as dangerous, since we have no locking on the
> children element of the device_t.  Hmmm, looks I just found a source
> of problems in my newbus locking code that might explain some weird
> things happening when I enable it  Thanks for making me go look :-)

You would add it to legacy, not nexus.  What you probably really want
to do is to write a host-PCI bridge driver that attaches to the actual
PCI device like 'hostb' and 'agp' do that creates a suitable child bus
for the MMCR stuff.  This works for both ACPI and non-ACPI and doesn't
require hacking the legacy_pcib stuff.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: USB versus SMP and Epson printers.

[Don Lewis]

On  7 Aug, Frank Mayhar wrote:
> Don Lewis wrote:
>> Unless someone snuck it in while I wasn't looking, our ulpt
>> implementation doesn't support reading data from the printer, so it's
>> not possible to check the ink levels.  I've had to boot Linux in order
>> to do this.
> 
> Hmm.  Okay...  Unfortunately, the straight printing didn't work, either.  I
> tried the "check the ink levels" trick only after my test page never printed.
> I'm using CUPS, could this be a limitation of the ulpt driver?  Should I be
> using another device?

I use a laser printer for most of my printing, so I only use my Epson
Photo 890 when I need to print color.  I never bothered to set up print
spooling for it, and just point ghostscript at it.  One problem I ran
into is that anything I attempt to print after a power-on gets turned
into garbage that prints a few funky-looking characters at the top the
page and then ejects the page unless I first run "escputil -n -u -r
/dev/ulpt0", which seems to send a magic escape sequence to the printer
that puts it in the proper mode.  I haven't had a time to investigate
further.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

BSD make question

[Andrew Gallatin]

Using BSD make, how can I apply different rules based on different
directories while using only a single makefile?


Ie, the appended Makefile results in the following compilations:

gcc -DLIB -c lib/foo.c -o lib/foo.o
gcc -DLIB -c lib/bar.c -o lib/bar.o
gcc -DMCP -c mcp/baz.c -o mcp/baz.o

Is it possible to do something similar with BSD make?

Drew


###
.SUFFIXES:
.SUFFIXES: .o .c

LIB=\
lib/foo.c \
lib/bar.c

MCP=\
mcp/baz.c

all: $(LIB:.c=.o) $(MCP:.c=.o)

lib/%.o: lib/%.c
gcc -DLIB -c $< -o $@

mcp/%.o: mcp/%.c
gcc -DMCP -c $< -o $@

.PHONY: clean
clean:
rm -f $(LIB:.c=.o) $(MCP:.c=.o)
###
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"