Hi,
yesterday I started to write an MI driver for the Catweasel MK3 and MK4 PCI
boards (http://www.icomp.de/indexe.htm).
The card is recognized, the io space is mapped and the hardware is
initialized (firmware uploaded into the card's FPGA).
ATM I have two questions:
1. The firmware is large,
On Sat, Feb 06, 2010 at 01:33:33PM +0100, Frank Wille wrote:
1. The firmware is large, with about 60k. Does anybody have experience
with using a compressed firmware image in the driver, which is uncompressed
on the fly, while uploading it to the chip? How would I do that?
(This would probably
On Sat, Feb 06, 2010 at 09:55:03PM +0900, Masao Uebayashi wrote:
A word from a UVM learner...
This case shouldn't be hit too often as the clusters are already
allocated from a pool, so the locking difference shouldn't make a big
difference. Comments?
My understanding is that the main
mbuf clusters have a pool cache already, so they generally won't go to
the backing map.
Thanks for clarification. The diff looks fine to me.
Masao
I think it's called firmload(9).
Masao
Probably we can think of a nice way to apply modules(9) to load a firmware
image, upload it to the device, then unload. When firmload(9) was invented,
we didn't have a nice kernel module support yet.
(I'm not sure what the dependency of them will look like, tho. :)
Masao
On Feb 6, 2010, at 4:20 AM, Masao Uebayashi wrote:
This kills phys_addr member at all. I don't think UVM_PAGE_TO_PHYS() is
called often. If we need performance, we should probably vectorize this
operation, like:
struct vm_page *pgs[16];
paddr_t pas[16];
Well, i need phys_addr for VM_MDPAGE_INIT to set the initial color of a page
but
that could be a second parameter to it.
My concern is that if you have several vm_physseg then finding the right could
be expensive. Or are we going to sort vm_physmem by increasing pa (and then
we
could
Masao Uebayashi wrote:
Probably we can think of a nice way to apply modules(9) to load a
firmware image, upload it to the device, then unload. When firmload(9)
was invented, we didn't have a nice kernel module support yet.
As I understand this would also need a filesystem to load from?
Hi,
on a server running netbsd-5, access to the second serial port
(com2 in bios, com1 for NetBSD) leads to an interrupt storm on ioapic0 pin 9,
used for the ACPI callback. This immediatly freeze the kernel on Xen,
and freeze a amd64 GENERIC kernel a few seconds later.
This doesn't happends with a
On 6 February 2010 13:33, Frank Wille fr...@phoenix.owl.de wrote:
Joerg Sonnenberger wrote:
Can't you use the approach e.g. of the wpi(4) driver and load the
firmware image from the filesystem?
No, firmload(9) would not really be an option, because I want to detect
connected devices, like a
On Sat, 6 Feb 2010 18:46:56 +
David Brownlee a...@netbsd.org wrote:
firmload can currently load from a set of directories. Has anyone
considered extending firmload to optionally load from memory as well -
possibly an included ramdisk image? That would allow the choice of
building in
On Wed, Feb 03, 2010 at 03:20:36AM +0900, Masao Uebayashi wrote:
As I briefly mentioned before, I'll need device page to support XIP. It's
a struct vm_page *, which is actually a magic value which conveys data from
pgo_get() to pmap_enter().
What's pgo_get()? Since you seem to be immersed in
On 2010-02-06, Jonathan A. Kollasch wrote:
*NICE*, our own firmware, and sufficent docs (and compilers) to modify
it are public it looks like.
Yes, you need pkgsrc/devel/sdcc and pkgsrc-wip/srecord
(GPL v2 and v3 respectively). Documentation is available
from the Texas Instruments website, and
On Sat, 6 Feb 2010, Paul Goyette wrote:
On Sat, 6 Feb 2010, Tobias Nygren wrote:
On Sat, 6 Feb 2010 20:12:32 +
Paul Goyette pgoye...@netbsd.org wrote:
Modified Files:
src/sys/arch/amd64/conf: GENERIC
src/sys/arch/i386/conf: ALL GENERIC
Log Message:
Add acpismbus enries -
On Sun, 7 Feb 2010, Masao Uebayashi wrote:
This will break mchines that store additional information such as
cacheing in the physaddr_t.
Could you be more specific? The only instance accessing phys_addr member I
can find is:
sys/arch/arm/include/arm32/vmparam.h:
1. The firmware is large, with about 60k. Does anybody have experience
with using a compressed firmware image in the driver, which is uncompressed
on the fly, while uploading it to the chip? How would I do that?
(This would probably make sense for most firmware, so a common
On Sat, Feb 06, 2010 at 11:10:00PM +0200, Yorick Hardy wrote:
There's not much point in putting the firmware in the kernel
by default until we have console-on-ucom(4) support.
I did not figure out how to delay firmware load if the device
is already connected on boot, then the filesystem is
On Sun, Feb 07, 2010 at 08:30:27AM +0100, Joerg Sonnenberger wrote:
On Sun, Feb 07, 2010 at 09:04:54AM +0200, Jukka Ruohonen wrote:
* The following sensors should be removed: technology,
low capacity, and warning capacity. These are not really
something that should be
19 matches
Mail list logo
