headers
Ignacio Verona | 1 Jun 2004 06:13

Has anyone heard about EPIA MII FastBoot ROM Utility?

Hi! Here http://www.viaarena.com/?PageID=343 under Booting Utility I've
found what via calls FastBoot ROM. It says we can boot from
PCMCIA-CompactFlash and MDOC on epia MII, and source code is provided.
I'll be givin a try this week, because it will be nice to my proyect if I
can boot from CF, so I can forgot about using harddisk. What do you think
about? Anyone has used this?
_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Permalink | Reply | 1 comment |
headers
Ignacio Verona | 1 Jun 2004 06:39

Re: Has anyone heard about EPIA MII FastBoot ROM Utility?

Sorry, I think source code is not provided, only the one necessary for
boot customizing.
_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Eric W. Biederman | 1 Jun 2004 08:05

Large mmio resources and 4G+ of RAM...


For the longest time I have been fighting what to do with machines
that have 4GB or more of memory and large memory mapped I/O resources.
As the conflict in memory space can cause a loss of 1/2GB of memory.
Which does not tend to be good for performance.

Looking the large memory mapped I/O resources all have 64bit BARs.  So
I am just going to modify the LinuxBIOS resource allocator to put
64bit BARs on x86-64 boxes at least above the top of memory.

There are a couple of short term hacks that I can do with relocating
memory but on the Opteron the more memory I add the more problems
I run into.  And moving BARS above 4G looks like the right term
fix.

Any objections?

Eric

_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Permalink | Reply | 12 comments |
headers
Stefan Reinauer | 1 Jun 2004 09:27
Gravatar

Re: Large mmio resources and 4G+ of RAM...

* Eric W. Biederman <ebiederman <at> lnxi.com> [040601 08:05]:
> Looking the large memory mapped I/O resources all have 64bit BARs.  So
> I am just going to modify the LinuxBIOS resource allocator to put
> 64bit BARs on x86-64 boxes at least above the top of memory.
> 
> There are a couple of short term hacks that I can do with relocating
> memory but on the Opteron the more memory I add the more problems
> I run into.  And moving BARS above 4G looks like the right term
> fix.

When running a 32bit operating system (like linux/x86) does this mean
that I am able to see more of my memory, but my pci devices will vanish?

Stefan
_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Permalink | Reply | 10 comments |
headers
Mathieu Deschamps | 1 Jun 2004 09:28

LinuxBios documentation

Le ven 28/05/2004 à 18:25, Nathanael Noblet a écrit :
> On Friday, May 28, 2004, at 08:52 AM, Mathieu Deschamps wrote:
> > For the time being, i'am at writing doc and well
> > this is a needed step, first it helps me understand in the whole,
> > second i've been ordered to do so.
> >
> > I would gladly help ... what I could is bringing my doc to you and
> > LinuxBios people.
> > But I write it in french since i'll prepare a 'conference'  at
> > my university based upon it: hey, my intented audience is frenchy.
> 
> I can translate it to english for you.

So everythings seems OK. Let's do it.
For me, since I got a realeaseable version , I let it on the maillist
and/or on your mail. On the latter, this will be done in one or two
weeks.

mathieu.
_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Eric W. Biederman | 1 Jun 2004 09:53

Re: Large mmio resources and 4G+ of RAM...

Stefan Reinauer <stepan <at> openbios.org> writes:

> * Eric W. Biederman <ebiederman <at> lnxi.com> [040601 08:05]:
> > Looking the large memory mapped I/O resources all have 64bit BARs.  So
> > I am just going to modify the LinuxBIOS resource allocator to put
> > 64bit BARs on x86-64 boxes at least above the top of memory.
> > 
> > There are a couple of short term hacks that I can do with relocating
> > memory but on the Opteron the more memory I add the more problems
> > I run into.  And moving BARS above 4G looks like the right term
                                                              ^long
> > fix.
> 
> When running a 32bit operating system (like linux/x86) does this mean
> that I am able to see more of my memory, but my pci devices will vanish?

Essentially.  Although the pci devices don't vanish you likely can't use
them because some of their BARS have values that 32bit kernels can't
cope with.  lspci should let you see that though.   A 32bit kernel
with PAE enabled could code but no one has written the code.

I don't have a problem with adding an option to disable this for 32bit
kernels.  I am just tired of optimizing 64bit machines for 32bit
kernels.

I need to be a little bit careful here as AMD's IO-APICs have 64bit
BARs but are only 4K.  So I might want to put in a size filter.  Plus
I need to ensure the bridges have enough resources to move things.

Eric
(Continue reading)

Permalink | Reply | 9 comments |
headers
Stefan Reinauer | 1 Jun 2004 10:33
Gravatar

Re: Large mmio resources and 4G+ of RAM...

* Eric W. Biederman <ebiederman <at> lnxi.com> [040601 09:53]:
> Essentially.  Although the pci devices don't vanish you likely can't use
> them because some of their BARS have values that 32bit kernels can't
> cope with.  lspci should let you see that though.   A 32bit kernel
> with PAE enabled could code but no one has written the code.

Are there any drawbacks to that solution? This should be addressed to
the Linux kernel developers. Given the advantages this brings, this
would probably something people would like to see.

> I don't have a problem with adding an option to disable this for 32bit
> kernels.  I am just tired of optimizing 64bit machines for 32bit
> kernels.

The silver bullet would be an option in the cmos option table to trigger
the one or the other behaviour. Or maybe it is enough to just put the
PCI BARs into 32bit address space whenever it fits there, taking the
amount of RAM into regard.
I agree it does not make sense to _optimize_ for 32bit kernels.
Essentially there are two groups of potential LinuxBIOS users in this
case: Those with small amounts of RAM (ie amd64 based embedded
solutions) might use 32bit code because it's easy to test it on many
PCs. Those with large amounts of RAM don't want to use a 32bit kernel
anyways. With more than about 1G of RAM 32bit Linux performance breaks
down noticably compared to the 64bit variant.

Stefan

_______________________________________________
Linuxbios mailing list
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric W. Biederman | 1 Jun 2004 10:49

Re: Large mmio resources and 4G+ of RAM...

Stefan Reinauer <stepan <at> openbios.org> writes:

> * Eric W. Biederman <ebiederman <at> lnxi.com> [040601 09:53]:
> > Essentially.  Although the pci devices don't vanish you likely can't use
> > them because some of their BARS have values that 32bit kernels can't
> > cope with.  lspci should let you see that though.   A 32bit kernel
> > with PAE enabled could code but no one has written the code.
>  
> Are there any drawbacks to that solution? This should be addressed to
> the Linux kernel developers. Given the advantages this brings, this
> would probably something people would like to see.

struct resource {} needs to be defined in terms of u64 instead of
unsigned long.  I know just that tweak was discussed and there were
some problems with that.

> > I don't have a problem with adding an option to disable this for 32bit
> > kernels.  I am just tired of optimizing 64bit machines for 32bit
> > kernels.
>  
> The silver bullet would be an option in the cmos option table to trigger
> the one or the other behaviour. 

Right that is what I was thinking.

> Or maybe it is enough to just put the
> PCI BARs into 32bit address space whenever it fits there, taking the
> amount of RAM into regard.

Except for some very small filters that starts requiring a filter
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mathieu Deschamps | 1 Jun 2004 14:48

About memory allocation code ...

Hello,

I got something something i cant get rid of. 
In the src/lib directory, it holds memory allocations
and relatives progs. Why are they redefined ? 
I mean couldn't we use standard's definitions ?
I've seen there are debug dumps mechanisms but 
surely as in standard's def.?

Could you enlighten me on this point ?

Thanks
mathieu
_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Permalink | Reply | 1 comment |
headers
ron minnich | 1 Jun 2004 15:09

Re: Chipsets: status page?

On Fri, 28 May 2004, Joshua Wise wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I read the FAQ looking for information on chipsets supported in LinuxBIOS, and 
> it pointed me towards the status page, however I can only find information 
> about mainboards on that page. Am I looking in the wrong place? For 
> reference, I'm wondering if the AMD-760 and the VIA VT82C686 are supported.

they're supported.

see the tyan guiness.

ron

_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Permalink | Reply | 1 comment |

Gmane