flashrom: Can't mmap memory

[Myles Watson]

When I boot using the factory BIOS on my s2895 flashrom works.  When I
boot with Coreboot, I get the Error:

Can't mmap memory using /dev/mem: Operation not permitted

It shouldn't be kernel parameters since I'm using the same grub2 entry
to boot either way.

This sounds a little too familiar, but I can't find a thread where
this isn't linked to a newer, more restrictive kernel.

Thanks,
Myles

[Peter Stuge]

Myles Watson wrote:
> When I boot using the factory BIOS on my s2895 flashrom works.  When I
> boot with Coreboot, I get the Error:
>
> Can't mmap memory using /dev/mem: Operation not permitted

Please try this with the latest revision, which will have a slightly
better error message.
> This sounds a little too familiar, but I can't find a thread where
> this isn't linked to a newer, more restrictive kernel.

I have seen this once before, in a system with a custom BIOS. I did
not invest the time needed to debug why the kernel does not permit
the mmap. printk needs to go into the kernel for that.

//Peter

[Peter Stuge]

Peter Stuge wrote:
> > Can't mmap memory using /dev/mem: Operation not permitted
>
> I have seen this once before, in a system with a custom BIOS.

Should mention that it was resolved with lseek()+read() instead of
mmap().

//Peter

[Carl-Daniel Hailfinger]

On 05.02.2009 21:26, Myles Watson wrote:
> When I boot using the factory BIOS on my s2895 flashrom works.  When I
> boot with Coreboot, I get the Error:
>
> Can't mmap memory using /dev/mem: Operation not permitted
>
> It shouldn't be kernel parameters since I'm using the same grub2 entry
> to boot either way.
>
> This sounds a little too familiar, but I can't find a thread where
> this isn't linked to a newer, more restrictive kernel.

Could be the memory map passed by cbtable or e820. A diff between dmesg
for each configuration would probably reveal quite a bit of info.

Regards,
Carl-Daniel

[Myles Watson]

> -----Original Message-----
> From: Carl-Daniel Hailfinger [mailto:[e-mail]]
> Sent: Thursday, February 05, 2009 4:19 PM
> To: Myles Watson
> Cc: Coreboot
> Subject: Re: [coreboot] flashrom: Can't mmap memory
>
> On 05.02.2009 21:26, Myles Watson wrote:
> > When I boot using the factory BIOS on my s2895 flashrom works.  When I
> > boot with Coreboot, I get the Error:
> >
> > Can't mmap memory using /dev/mem: Operation not permitted
> >
> > It shouldn't be kernel parameters since I'm using the same grub2 entry
> > to boot either way.
> >
> > This sounds a little too familiar, but I can't find a thread where
> > this isn't linked to a newer, more restrictive kernel.
>
> Could be the memory map passed by cbtable or e820. A diff between dmesg
> for each configuration would probably reveal quite a bit of info.

Good idea.  Tomorrow I'll look at that.  The memory maps are quite
different, but in both cases the ROM is marked uncacheable.

Thanks,
Myles

[Myles Watson]

On Thu, Feb 5, 2009 at 8:18 PM, Myles Watson  wrote:
> > -----Original Message-----
> > From: Carl-Daniel Hailfinger [mailto:[e-mail]]
> > Sent: Thursday, February 05, 2009 4:19 PM
> > To: Myles Watson
> > Cc: Coreboot
> > Subject: Re: [coreboot] flashrom: Can't mmap memory
> >
> > On 05.02.2009 21:26, Myles Watson wrote:
> > > When I boot using the factory BIOS on my s2895 flashrom works.  When I
> > > boot with Coreboot, I get the Error:
> > >
> > > Can't mmap memory using /dev/mem: Operation not permitted
> > >
> > > It shouldn't be kernel parameters since I'm using the same grub2 entry
> > > to boot either way.
> > >
> > > This sounds a little too familiar, but I can't find a thread where
> > > this isn't linked to a newer, more restrictive kernel.
> >
> > Could be the memory map passed by cbtable or e820. A diff between dmesg
> > for each configuration would probably reveal quite a bit of info.
>
> Good idea.  Tomorrow I'll look at that.  The memory maps are quite
> different, but in both cases the ROM is marked uncacheable.

It turns out that flashrom is getting confused and trying to map
0xfff00000-0x10100000.  The factory BIOS doesn't boost memory up
there, so it was fine.  If I specify the chip with -c SST49LF080A it
succeeds.  I don't know why the size is different depending on whether
you specify the chip or not.

An added printf shows that flash->total_size = 0x800 when it fails,
and 0x400 when it succeeds.

Thanks,
Myles

[Myles Watson]

On Fri, Feb 6, 2009 at 10:19 AM, Myles Watson  wrote:
> On Thu, Feb 5, 2009 at 8:18 PM, Myles Watson  wrote:
> > > -----Original Message-----
> > > From: Carl-Daniel Hailfinger [mailto:[e-mail]]
> > > Sent: Thursday, February 05, 2009 4:19 PM
> > > To: Myles Watson
> > > Cc: Coreboot
> > > Subject: Re: [coreboot] flashrom: Can't mmap memory
> > >
> > > On 05.02.2009 21:26, Myles Watson wrote:
> > > > When I boot using the factory BIOS on my s2895 flashrom works.  When I
> > > > boot with Coreboot, I get the Error:
> > > >
> > > > Can't mmap memory using /dev/mem: Operation not permitted
> > > >
> > > > It shouldn't be kernel parameters since I'm using the same grub2 entry
> > > > to boot either way.
> > > >
> > > > This sounds a little too familiar, but I can't find a thread where
> > > > this isn't linked to a newer, more restrictive kernel.
> > >
> > > Could be the memory map passed by cbtable or e820. A diff between dmesg
> > > for each configuration would probably reveal quite a bit of info.
> >
> > Good idea.  Tomorrow I'll look at that.  The memory maps are quite
> > different, but in both cases the ROM is marked uncacheable.
>
> It turns out that flashrom is getting confused and trying to map
> 0xfff00000-0x10100000.  The factory BIOS doesn't boost memory up
> there, so it was fine.  If I specify the chip with -c SST49LF080A it
> succeeds.  I don't know why the size is different depending on whether
> you specify the chip or not.
>
> An added printf shows that flash->total_size = 0x800 when it fails,
> and 0x400 when it succeeds.

I should have used flashrom -V earlier.  Here it is:

Probing for SST SST49LF040, 512 KB: probe_jedec: id1 0xbf, id2 0x5b
Probing for SST SST49LF040B, 512 KB: probe_jedec: id1 0xbf, id2 0x5b
Probing for SST SST49LF080A, 1024 KB: probe_jedec: id1 0xbf, id2 0x5b
Found chip "SST SST49LF080A" (1024 KB) at physical address 0xfff00000.
Probing for SST SST49LF160C, 2048 KB: Error accessing flash chip,
0x200000 bytes at 0xfff00000
/dev/mem mmap failed: Operation not permitted

I don't know enough about flashrom to know if it should have stopped,
or if it should have figured out a better base address for the
SST49LF160C.

Hopefully that's enough information to point in the right direction.

Thanks,
Myles

[ron minnich]

On Fri, Feb 6, 2009 at 9:29 AM, Myles Watson  wrote:
> Probing for SST SST49LF040, 512 KB: probe_jedec: id1 0xbf, id2 0x5b
> Probing for SST SST49LF040B, 512 KB: probe_jedec: id1 0xbf, id2 0x5b
> Probing for SST SST49LF080A, 1024 KB: probe_jedec: id1 0xbf, id2 0x5b
> Found chip "SST SST49LF080A" (1024 KB) at physical address 0xfff00000.
> Probing for SST SST49LF160C, 2048 KB: Error accessing flash chip,
> 0x200000 bytes at 0xfff00000
> /dev/mem mmap failed: Operation not permitted
>
> I don't know enough about flashrom to know if it should have stopped,
> or if it should have figured out a better base address for the
> SST49LF160C.

I think it's a bug.

See this code in probe_flash.

base = flashbase ? flashbase : (0xffffffff - size + 1);
    	flash->virtual_memory = bios = physmap("flash chip", base, size);

It seems to me that if we probed the 1M part and flashbase was
0xfff00000, then the next time through, when we have a 2M part, we'll
use a flashbase that is wrong -- 0xfff00000.

I wonder why we even make this test: flashbase ? flashbase :
(0xffffffff - size + 1)

I think it goes back to the lovely sc520 and other chips that had a
non-standard flashbase. But in that case, we ought to have a better
way to set it than this global.

ron

[ron minnich]

I have not seen a patch for this one so here is mine. Untested. Not signed off.

Thanks
ron

Index: util/flashrom/flashrom.c
===================================================================
--- util/flashrom/flashrom.c	(revision 3930)
+++ util/flashrom/flashrom.c	(working copy)
@@ -122,6 +122,13 @@
    	}

base = flashbase ? flashbase : (0xffffffff - size + 1);
+		/* this part might be much larger than the last part.
+ 		 * If so, we have to ignore the flashbase value
+ 		 */
+		if (flashbase && (base + size) < flashbase)
+			base = 0xffffffff - size + 1;
+
    	flash->virtual_memory = bios = physmap("flash chip", base, size);

[Peter Stuge]

ron minnich wrote:
> I have not seen a patch for this one so here is mine. Untested. Not
> signed off.

It'll work in this case but the flash chip size can also be smaller
than the last detected chip.

I'll prepare a generic fix tonight. Thanks for the bump.

//Peter

[ron minnich]

On Sun, Feb 8, 2009 at 9:45 AM, Peter Stuge  wrote:
> ron minnich wrote:
> > I have not seen a patch for this one so here is mine. Untested. Not
> > signed off.
>
> It'll work in this case but the flash chip size can also be smaller
> than the last detected chip.

I'm not sure there is any harm in the smaller case.

ron

[Peter Stuge]

ron minnich wrote:
> > It'll work in this case but the flash chip size can also be smaller
> > than the last detected chip.
>
> I'm not sure there is any harm in the smaller case.

Some chips are particular about the addresses that offsets are
written to and e.g. block erase will not work properly.

//Peter

[ron minnich]

On Sun, Feb 8, 2009 at 9:55 AM, Peter Stuge  wrote:
> ron minnich wrote:
> > > It'll work in this case but the flash chip size can also be smaller
> > > than the last detected chip.
> >
> > I'm not sure there is any harm in the smaller case.
>
> Some chips are particular about the addresses that offsets are
> written to and e.g. block erase will not work properly.

Actually, I'm not that picky about the patch, but ... I doubt the
flash chips themselves know or care. It's the chipsets (e.g. the
sc520) that are the real trouble.

I am not sure why we have that test for flashbase anyway. What's it
matter? Why do we use the old value for the next value?

ron

[Peter Stuge]

ron minnich wrote:
> I doubt the flash chips themselves know or care.

They do. Look at how any LPC/FWH chip does block erase. Which block
to erase depends on the address relative start of chip that is used
in the block erase command.
> I am not sure why we have that test for flashbase anyway. What's it
> matter? Why do we use the old value for the next value?

It's a bug. I'll fix it but need to go off for a bit first.

//Peter

[ron minnich]

On Sun, Feb 8, 2009 at 10:03 AM, Peter Stuge  wrote:
> ron minnich wrote:
> > I doubt the flash chips themselves know or care.
>
> They do. Look at how any LPC/FWH chip does block erase. Which block
> to erase depends on the address relative start of chip that is used
> in the block erase command.

relative to the start of the chip yes. But the chip itself could be
physically addressed at, e.g., 0x8000000, and all the programming
would be fine.

The only issue I've had with physical chip address was on the sc520,
where the put a bunch of registers in the middle of the flash address
space.

thanks

ron

[Peter Stuge]

ron minnich wrote:
> I am not sure why we have that test for flashbase anyway. What's it
> matter? Why do we use the old value for the next value?

The reason it is used like that is that SC520 code runs before all
probes and can set flashbase, which should then be used by the
probes.

ron minnich wrote:
> relative to the start of the chip yes. But the chip itself could be
> physically addressed at, e.g., 0x8000000, and all the programming
> would be fine.

If the chip is at top of 4GB and the base does is not the start of
the chip some if not all commands to the chip will fail.
> The only issue I've had with physical chip address was on the
> sc520, where the put a bunch of registers in the middle of the
> flash address space.

Many flash chips also have registers, and even if they don't at the
very least block erase operations absolutely need the mmap to start
where the flash chip starts.

Attaching my suggested patch. Myles, could you give it a go please?

//Peter

[ron minnich]

Peter, you're right, I was misunderstanding your point at first.

I'm still a bit concerned about the "sc520 must be probed first" but
it's not even really that important anyway; any sc520's left out
there? Are they still made?

ron

[Stefan Reinauer]

On 09.02.2009 1:31 Uhr, ron minnich wrote:
> Peter, you're right, I was misunderstanding your point at first.
>
> I'm still a bit concerned about the "sc520 must be probed first"

The sc520 rom area is never probed "first".. It's only probed when an
sc520 is detected.

[Peter Stuge]

ron minnich wrote:
> I'm still a bit concerned about the "sc520 must be probed first"

Stefan Reinauer wrote:
> The sc520 rom area is never probed "first".. It's only probed when
> an sc520 is detected.

Thanks for clarifying Stefan!

flashrom runs chipset enables, then board enables, then finally
probes for flash chips.

The SC520 chipset enable sets flashbase according to hardware
configuration and the chip probes then use that base.

Only the first flash chip base is honored for SC520. For subsequent
probes (after the first found chip) flashrom will again look at top
of 4GB. I don't care too much. Multichip is already a corner case.

For non-SC520 flashrom now consistently looks at top of 4GB.

All this multi chip and moving base stuff is a total hack in flashrom
as it stands. I think that's fine for now.

//Peter

[Myles Watson]

On Sun, Feb 8, 2009 at 5:05 PM, Peter Stuge  wrote:
> ron minnich wrote:
> > I am not sure why we have that test for flashbase anyway. What's it
> > matter? Why do we use the old value for the next value?
>
> The reason it is used like that is that SC520 code runs before all
> probes and can set flashbase, which should then be used by the
> probes.
>
> ron minnich wrote:
> > relative to the start of the chip yes. But the chip itself could be
> > physically addressed at, e.g., 0x8000000, and all the programming
> > would be fine.
>
> If the chip is at top of 4GB and the base does is not the start of
> the chip some if not all commands to the chip will fail.
> > The only issue I've had with physical chip address was on the
> > sc520, where the put a bunch of registers in the middle of the
> > flash address space.
>
> Many flash chips also have registers, and even if they don't at the
> very least block erase operations absolutely need the mmap to start
> where the flash chip starts.
>
> Attaching my suggested patch. Myles, could you give it a go please?

It works for me.

Acked-by: Myles Watson

Thanks,
Myles

[Peter Stuge]

Myles Watson wrote:
> It works for me.
>
> Acked-by: Myles Watson

r3932