[LinuxBIOS] 64bit issues was: [PATCH] LBv3: fix printk format warnings

Stefan Reinauer stepan at coresystems.de
Tue Aug 21 17:01:32 CEST 2007

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [070820 22:50]:
> I was talking about ./superio/winbond/w83627hf/superio.c:init_hwm()
> where Ron assumed that base was a pointer, however init_hwm defines it
> as u16. Which is somewhat interesting because w83627hf_init() calls
> init_hwm(res0->base + HWM_INDEX_PORT) where res0->base is resource_t aka
> u64. That means we have an implicit truncation from u64 to u16. Is that
> intentional?

Hm this looks like a shortcoming of our device model. The superio base
address is 0x2e or 0x4e

> ./device/pci_rom.c:pci_rom_probe():
> printk(BIOS_DEBUG, "ROM address for %s = %lx\n", dev_path(dev),
> rom_address);
> I was wondering whether rom_address (which is essentially a pointer)
> should be resource_t.

In the current PCI standard the rom address is always a 32bit value. In
theory ROMs might be mapped above 4G in future standards. It's nothing
we need to handle too soon though in that scope. (ie. when that happens
we are probably not going to have x86 pcbios option roms anymore)

> Also, how should we printk anything that's resource_t? Everything with
> type resource_t is essentially a pointer. %p won't work unless we
> compile for 64bit. Maybe introduce %P or some other ugly hack.

Hm. probably %P is a good idea. or %lp to stay consistent?

> > We don't confine ourselfes. There's PAE
> Which we don't want to handle in LB.
We already do.

> > 32bit OSes can not handle system resources above 4GB except with tricks
> > (PAE). That is why 32bit OSes are dying out and are not being used
> > anymore in environments where resources above 4GB happen.
> The interesting question is whether we can set up resources in a way
> that allows 32bit OSes to boot, e.g. by "moving" RAM to above 4G and
> making it inaccessible that way.

That's what happens in the default configuration if you dont set

> > If you run a 32bit OS on a machine with 4G of RAM you simply can not be
> > helped. Linux starts having severe performance problems in 32bit mode
> > when you cross the 1G border. Which basically every machine does today,
> > except lowend hobbyist stuff and embedded systems.
> Yes, but we should allow it to boot if this is technically possible.

It is allowed and possible.

> > we want to go 64bit mode.
> > The really broken thing with x86_64's long mode is that it does not work
> > without paging enabled. That makes the effort to use it in the bios
> > harder than the gain.
> Seems we are caught between a rock and a hard place. PAE is ugly, long
> mode is difficult.
Not only difficult, it is impossible for most of our code. For long mode
you need paging. For paging you need page tables. These need to be in
RAM. RAM is not initialized yet.

It might not be a problem when switching to long mode before entering
stage2. That would disallow our calls into stage0/1 functions that we
currently do. Might be a low price to pay.

Then there's the next question: What do we do with OSes and payloads 
that have no 64bit entry point? Go back to 32bit mode?


coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/

More information about the coreboot mailing list