[LinuxBIOS] On flashrom architecture

[Darmawan Salihun]

Hi all,
   Sorry if this is quite very basic question. I haven't got the time to
read the latest version of linuxbios's flashrom. Is the basic mechanism to
access the BIOS chip address space is through mmap function? haven't grep
the code though :-(.

--Darmawan

[Stefan Reinauer]

* Darmawan Salihun  [070424 17:37]:
> Hi all,
>    Sorry if this is quite very basic question. I haven't got the time to read
> the latest version of linuxbios's flashrom. Is the basic mechanism to access
> the BIOS chip address space is through mmap function? haven't grep the code
> though :-(.

Yes. The bios chip is mmapped into the processes address space. There
are some occurences of mmap over the place. I recently cleaned the code
up a little bit, dropping multiple open() calls on /dev/mem.

Do we need a wrapper for those "map-physical-memory" functions?

Stefan

[Darmawan Salihun]

On 4/24/07, Stefan Reinauer  wrote:
> Darmawan Salihun  [070424 17:37]:
> > Hi all,
> >    Sorry if this is quite very basic question. I haven't got the time to
>
> read
> > the latest version of linuxbios's flashrom. Is the basic mechanism to
>
> access
> > the BIOS chip address space is through mmap function? haven't grep the
>
> code
> > though :-(.
>
> Yes. The bios chip is mmapped into the processes address space. There
> are some occurences of mmap over the place. I recently cleaned the code
> up a little bit, dropping multiple open() calls on /dev/mem.
>
> Do we need a wrapper for those "map-physical-memory" functions?
>
> I think we don't need it because it has an "equivalent" in Windows' kernel

mode driver, i.e.

PVOID MmGetSystemAddressForMdlSafe(IN PMDL  Mdl, IN MM_PAGE_PRIORITY
Priority);

Unless, we are planning for a "single-build" for all platforms (Linux, BSD,
etc.), we don't need a wrapper.
The main problem is the mechanism will be a bit different because flashrom
will be divided into kernel mode driver
and user mode application in Windows.

-- Darmawan
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-

[Peter Stuge]

On Tue, Apr 24, 2007 at 11:15:24PM +0700, Darmawan Salihun wrote:
> > Do we need a wrapper for those "map-physical-memory" functions?
>
> I think we don't need it because it has an "equivalent" in Windows'
> kernel mode driver, i.e.
>
> PVOID MmGetSystemAddressForMdlSafe(IN PMDL  Mdl, IN
> MM_PAGE_PRIORITY Priority);

Is MmMapIoSpace() strictly for io? Otherwise it may also be a
candidate.

It seems an MDL is always specified with a virtual address but I
can't find a phystovirt() in the Mm functions. Admittedly I didn't
look very hard so you may already have found it. :)
> The main problem is the mechanism will be a bit different because
> flashrom will be divided into kernel mode driver and user mode
> application in Windows.

I think I like having more of the logic in the kernel driver for
once, this is because the algorithms can benefit in speed, and
because the system will be more stable as long as the kernel driver
is bug free. ;)

Letting the app drive everything is less intrusive of course, but
could also put the system into an unknown state if the app is aborted
halfway through something.

//Peter

[Darmawan Salihun]

On 4/25/07, Peter Stuge  wrote:
> On Tue, Apr 24, 2007 at 11:15:24PM +0700, Darmawan Salihun wrote:
> > > Do we need a wrapper for those "map-physical-memory" functions?
> >
> > I think we don't need it because it has an "equivalent" in Windows'
> > kernel mode driver, i.e.
> >
> > PVOID MmGetSystemAddressForMdlSafe(IN PMDL  Mdl, IN
> > MM_PAGE_PRIORITY Priority);
>
> Is MmMapIoSpace() strictly for io? Otherwise it may also be a
> candidate.

...ah, you're right Peter. It was in the midnight back then when I wrote
mail. It should've been
MmMapIoSpace(..), not MmGetSystemAddressForMdlSafe(..) function. I have
something in the works right now for the porting of flashrom to Windows.
Below is the snippet (in case you are curious about it ;)
----------
    //
    // We have obtained a free mapZone, map the physical address range.
    //
    pUsermodeMem =  (MMIO_MAP*) MmGetSystemAddressForMdlSafe(
pIrp->MdlAddress, NormalPagePriority );
    if( NULL == pUsermodeMem) {
    return STATUS_INVALID_USER_BUFFER;
    }

phyAddr.HighPart = 0;
    phyAddr.LowPart = pUsermodeMem->phyAddrStart;

pDevExt->mapZone[free_idx].sysAddrBase = MmMapIoSpace( phyAddr,
pUsermodeMem->size, MmNonCached);
    if(NULL == pDevExt->mapZone[free_idx].sysAddrBase)
    {
    return STATUS_BUFFER_TOO_SMALL;
    }

pDevExt->mapZone[free_idx].pMdl =
IoAllocateMdl(pDevExt->mapZone[free_idx].sysAddrBase,
                            pUsermodeMem->size, FALSE, FALSE, NULL);
    if(NULL == pDevExt->mapZone[free_idx].pMdl)
    {
    MmUnmapIoSpace(pDevExt->mapZone[free_idx].sysAddrBase,
pUsermodeMem->size);
    pDevExt->mapZone[free_idx].sysAddrBase = NULL;
    return STATUS_BUFFER_TOO_SMALL;
    }

pDevExt->mapZone[free_idx].size = pUsermodeMem->size;

//
    // Map the system virtual address to usermode virtual address
    //
    MmBuildMdlForNonPagedPool(pDevExt->mapZone[free_idx].pMdl);
    pDevExt->mapZone[free_idx].usermodeAddrBase =
MmMapLockedPagesSpecifyCache(    pDevExt->mapZone[free_idx].pMdl,
                                        UserMode, MmNonCached,
                                        NULL, FALSE,
                                        NormalPagePriority);
    if(NULL ==  pDevExt->mapZone[free_idx].usermodeAddrBase)
    {
    IoFreeMdl(pDevExt->mapZone[free_idx].pMdl);
    MmUnmapIoSpace(pDevExt->mapZone[free_idx].sysAddrBase,
pDevExt->mapZone[free_idx].size);
    pDevExt->mapZone[free_idx].sysAddrBase = NULL;
    pDevExt->mapZone[free_idx].size = 0;
    return STATUS_BUFFER_TOO_SMALL;
    }
-----------------
>

It seems an MDL is always specified with a virtual address but I
> can't find a phystovirt() in the Mm functions. Admittedly I didn't
> look very hard so you may already have found it. :)

Basically, the conversion to User mode virtual address is in the code
snippet above ;-)
> > The main problem is the mechanism will be a bit different because
> > flashrom will be divided into kernel mode driver and user mode
> > application in Windows.
>
> I think I like having more of the logic in the kernel driver for
> once, this is because the algorithms can benefit in speed, and
> because the system will be more stable as long as the kernel driver
> is bug free. ;)
>
> Letting the app drive everything is less intrusive of course, but
> could also put the system into an unknown state if the app is aborted
> halfway through something.

I'll look forward this issue. Thanks.

--Darmawan
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-

[Darmawan Salihun]

Anyway, what is the

#define TS5300

used for?

Is it for AMD586 boards? IIRC this is AMD Elan Platform, right?

-- Darmawan
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-

[Stefan Reinauer]

* Darmawan Salihun  [070428 13:33]:
> Anyway, what is the
>
> #define TS5300
>
> used for?
>
> Is it for AMD586 boards? IIRC this is AMD Elan Platform, right?

Yes. It's a specific sc520 system which has it's flash mapped to another
position. I was a bit uncertain whether to allow flash probing in that
area on non-TS5300 systems. Do you have a good idea for a runtime check?
Maybe just checking for an sc520 would be enough already.

Stefan

[Darmawan Salihun]

On 4/28/07, Stefan Reinauer  wrote:
> Darmawan Salihun  [070428 13:33]:
> > Anyway, what is the
> >
> > #define TS5300
> >
> > used for?
> >
> > Is it for AMD586 boards? IIRC this is AMD Elan Platform, right?
>
> Yes. It's a specific sc520 system which has it's flash mapped to another
> position. I was a bit uncertain whether to allow flash probing in that
> area on non-TS5300 systems. Do you have a good idea for a runtime check?

hmm..., I'm not sure because I think that address range mostly used for PCI
devices in Windows and it's dangerous to probe such range at runtime in
Windows. It needs more testing though

Maybe just checking for an sc520 would be enough already.
>

I think so.

--Darmawan

[Stefan Reinauer]

* Darmawan Salihun  [070428 13:44]:
> Yes. It's a specific sc520 system which has it's flash mapped to another
> position. I was a bit uncertain whether to allow flash probing in that
> area on non-TS5300 systems. Do you have a good idea for a runtime check?

In fact, the SC520 has three possible flash banks that should be probed,
instead of the single hard coded one:

Registers are
BOOTCS (MMCR offs 0x50), ROMCS1 (MMCR offs 0x54), ROMCS2 (MMCR offs 0x56)

and one of PAR0-PAR15 (32bit registers at 0x88-0xc4) - The highest 3 bit
describe the target, 100 is BOOTCS, 101 is ROMCS1, 110 is ROMCS2

See Élan™ SC520 Microcontroller Register Set Manual

The Linux MTD mapping driver suggests changing the default mapping of
those areas for some interesting reasons. We might take the chance to
unify the ROM mappings on all SC520 boards.

Ron?

Stefan

[ron minnich]

On 4/28/07, Stefan Reinauer  wrote:
> Darmawan Salihun  [070428 13:44]:
> > Yes. It's a specific sc520 system which has it's flash mapped to another
> > position. I was a bit uncertain whether to allow flash probing in that
> > area on non-TS5300 systems. Do you have a good idea for a runtime check?
>
> In fact, the SC520 has three possible flash banks that should be probed,
> instead of the single hard coded one:
>
> Registers are
> BOOTCS (MMCR offs 0x50), ROMCS1 (MMCR offs 0x54), ROMCS2 (MMCR offs 0x56)
>
> and one of PAR0-PAR15 (32bit registers at 0x88-0xc4) - The highest 3 bit
> describe the target, 100 is BOOTCS, 101 is ROMCS1, 110 is ROMCS2
>
> See Élan™ SC520 Microcontroller Register Set Manual
>
> The Linux MTD mapping driver suggests changing the default mapping of
> those areas for some interesting reasons. We might take the chance to
> unify the ROM mappings on all SC520 boards.
>
> Ron?

The Elan SC520 is a really interesting design. I don't know how much
longer Elan will be around. For now, I would not put a lot of effort
into cleaning it up -- there is lots of other work to do.

ron
> Stefan