Hi,
Is it acceptable to do direct port I/O through driver for I/O port
accesses (other than
the PCI bus accesses). I still couldn't figure out the solution for this
kind of problem.
It will require fair amount of changes to the current flashrom code base
for that :-(.
--Darmawan
Stefan
Hi,
On Mon, Jun 25, 2007 at 11:02:50PM +0700, Darmawan Salihun wrote:
Is it acceptable to do direct port I/O through driver for I/O
port accesses (other than the PCI bus accesses). I still couldn't
figure out the solution for this kind of problem.
Ahh - for enabling flash writes. Well -
Hi,
Peter Stuge wrote:
Hi,
On Mon, Jun 25, 2007 at 11:02:50PM +0700, Darmawan Salihun wrote:
Is it acceptable to do direct port I/O through driver for I/O
port accesses (other than the PCI bus accesses). I still couldn't
figure out the solution for this kind of problem.
Ahh -
* Darmawan Salihun [EMAIL PROTECTED] [070624 11:42]:
Anyway, what is the zlib library used for?
compression of pci.ids for libpci.
Is the binary from LinuxBIOS build (presumably the payload) compressed
using some functions in zlib?
No, flashrom does not do any of that intelligent stuff. It
On Sun, Jun 17, 2007 at 11:43:14AM +0700, Darmawan Salihun wrote:
And other thing is to remove the direct IO routine because it's too
dangerous and replace it with Windows driver setup API instead
because what flashrom need is only the PCI id's and some other
stuff that I think can be found in
On Tue, Jun 19, 2007 at 07:45:15PM +0700, Darmawan Salihun wrote:
flashrom also maps the low 1MB for certain purposes.
Do you know why?
Therefore, I decided to modify the driver to support both address
range. I think it should be acceptable, isn't it?
Sure, if there's really a need for it.
* Peter Stuge [EMAIL PROTECTED] [070621 01:00]:
On Tue, Jun 19, 2007 at 07:45:15PM +0700, Darmawan Salihun wrote:
flashrom also maps the low 1MB for certain purposes.
Do you know why?
For reading the LinuxBIOS table.
I unified memory mapping in LinuxBIOS a bit a while ago. There are a
lot
Hi,
Stefan Reinauer wrote:
One thing that should really drive this home, is that using this
architecture on Linux *and* Windows, the same userspace tool could be
used on both, so the fancy code for incremental updates, writing
parameter blocks, etc., wouldn't have to be duplicated.
It
Okay, I hate to sound naive, but what Windows versions can/will this
support? I'm assuming 2000 and XP, what about Vista and 98? Also, where
this is going to be a driver, will there be any problem with Vista
complaining about it not being signed? Vista can be a real pain with
drivers that aren't
Hi,
Corey Osgood wrote:
Okay, I hate to sound naive, but what Windows versions can/will this
support? I'm assuming 2000 and XP,
Yes, indeed. The current driver is still on 2000/XP because I only have
the DDK for that version of Windows right now.
I haven't evaluate the WDK that's used for
Stefan Reinauer wrote:
Oh I love playing advocatus diaboli ;-)
* Jeremy Jackson [EMAIL PROTECTED] [070611 16:58]:
One thing that should really drive this home, is that using this
architecture on Linux *and* Windows, the same userspace tool could be
used on both, so the fancy code for
* Jeremy Jackson [EMAIL PROTECTED] [070611 19:36]:
Nonetheless, you can make sure it does not happen by unloading the
network card module.
Well unloading the driver seems a bit clumsy, and a contradiction
really. (unloading a driver to use hardware). I would add the flash
ROM
* Jeremy Jackson [EMAIL PROTECTED] [070611 19:27]:
area. I'm looking for a way to pass that info to the kernel (from
linuxbios table?) similar to e820, so that can be used as RAM. (keyword:
legacy removal)
GOOOD idea!
I'm curious to know what depends on the below 1MB alias, and could they
* Peter Stuge [EMAIL PROTECTED] [070611 19:36]:
On Mon, Jun 11, 2007 at 01:27:17PM -0400, Jeremy Jackson wrote:
I'm curious to know what depends on the below 1MB alias,
DMA IIRC.
Is ISA DMA still being used?
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761
Jeremy Jackson schrieb:
Well unloading the driver seems a bit clumsy, and a contradiction
really. (unloading a driver to use hardware). I would add the flash
ROM functionality to the NIC driver, and have it export an MTD map. The
space.c stub implementation would just return EBUSY if the
Peter Stuge wrote:
On Wed, Jun 06, 2007 at 10:47:59PM +0700, Darmawan Salihun wrote:
I know, it's not a good example of software engineering practice.
Nonetheless, I want to discuss, on which API that I should be
removing from user mode application accesses and which one to
retain.
On Wed, Jun 06, 2007 at 11:16:03PM +0700, Darmawan Salihun wrote:
1. Kernel driver allowing unrestricted reads and writes to top 16MB.
The current version of the driver code is capable of mapping
*anywhere* within the 4GB physical address space. It shouldn't be a
problem to restrict it to
Peter Stuge wrote:
On Thu, Jun 07, 2007 at 12:12:45AM +0700, Darmawan Salihun wrote:
NTSTATUS MapMmio(PDEVICE_OBJECT pDO, PIRP pIrp)
[..]
pDO - pointer to the device object of this driver.
pIrp - pointer to an I/O Request Packet.
Uff. What's wrong with void * ? I
18 matches
Mail list logo
