On Wed, Jan 26, 2005 at 09:52:11PM -0800, Adam Talbot wrote:
> -Ron (Linuxbios team)
> Humm, had one of my strange ideas. Would it be possible to use the
> linuxbios kernel as the system kernel?? So instead of calling a
> new kernel through FILO or booting from etherboot, could I just
> have Linu
* Adam Talbot <[EMAIL PROTECTED]> [050127 06:52]:
> -Ron (Linuxbios team)
> Humm, had one of my strange ideas. Would it be possible to use the
> linuxbios kernel as the system kernel?? So instead of calling a new kernel
> through FILO or booting from etherboot, could I just have Linux bios call
>
-Ron (Linuxbios team)
Humm, had one of my strange ideas. Would it be possible to use the
linuxbios kernel as the system kernel?? So instead of calling a new kernel
through FILO or booting from etherboot, could I just have Linux bios call
INIT, like a normal kernel. I am looking to get the best p
also, you should try to make memtest86 a payload and see if it passes.
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
are you building the kernel with ONLY serial console, and not vga console?
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
> Yes you can do that with ELF.
>
> The big gotcha is going to be that there are pirq tables current
> stored at 0xf that you are not going to want to stomp.
Actually thats not that much of an issue. It currently stomps it already
ADLO has that table broken out into a single binary file. Al
Adam Sulmicki <[EMAIL PROTECTED]> writes:
> On Wed, 26 Jan 2005, Richard Smith wrote:
> > I wonder if we could not just set things up where the ELF loader just
> > loas it into the right spot in the first place. Perhaps that
> > overwrites where the ELF code lives?
>
> if the ram/shadowing was s
Ah, I had assumed that filo could only load an elf
image. Okay. Replaced that with a fresh bzImage with
early printk enabled. Looks to fail at the same point.
I noticed filo is now able to show the kernel version
and build date so I'd guess that this is getting
better. Here's the debug output. I'm
* Greg Lindahl <[EMAIL PROTECTED]> [050126 22:48]:
> You mean you tested for a short time and didn't see the AMD 8131 bug,
> and so you are going to run production at the higher speed?
>
> This is not so smart. The bug in the 8131 HT core is rare, but big
> clusters will see it fairly frequently.
I add one OPT_HT_LINK in it to disable the ht_setup_link.
for the ht_setup_link is already done in auto.c stage.
YH
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
On Wed, Jan 26, 2005 at 11:17:10AM +0100, Stefan Reinauer wrote:
> 1) hypertransport clocking
>
>This patch allows to disable the speed cuts during hypertransport
>setup using cmos variables "amdk8_1GHz" and "amd8131_800MHz".
>I've tried them on hardware which worked perfectly fine
>
But I actually think that is overkill. v2 by default and design
enables all of the shadow ranges as memory. So we just need to
use those ranges. That should be much easier having to patch
ADLO each time. It is fairly unlikely a writable ROM segment is
going to break anything.
FWIW, I actually d
On Wed, 26 Jan 2005, Richard Smith wrote:
http://cvs.sourceforge.net/viewcvs.py/freebios/freebios/util/ADLO/loader.s?rev=1.1&view=auto
it mentions sources as 0x8000 and 0x18000, so I guess they have been
aready copied out of rom into the the low memory by linuxbios ???
(i think that's part
>
> http://cvs.sourceforge.net/viewcvs.py/freebios/freebios/util/ADLO/loader.s?rev=1.1&view=auto
>
> it mentions sources as 0x8000 and 0x18000, so I guess they have been
> aready copied out of rom into the the low memory by linuxbios ???
>
> (i think that's part of the ELF header specs t
On Wed, 26 Jan 2005, Richard Smith wrote:
> I think that I when I remeber looking at the diff between ADLO and the
> latest bochs stuff that the ADLO stuff payed attention to some status
> bits that the stock bochs stuff didn't.
>
> Plus the ADLO IDE stuff worked where the latest bochs stuff di
> or perhaps to put it other way around; 95% of current problems with BOCHS
> bios is related to the ide driver. Get IDE driver right and it is quite
> possible most of the stuff will work.
I think that I when I remeber looking at the diff between ADLO and the
latest bochs stuff that the ADLO stuf
On Wed, 26 Jan 2005, Richard Smith wrote:
On Wed, 26 Jan 2005 13:12:27 -0600, Richard Smith <[EMAIL PROTECTED]> wrote:
But I actually think that is overkill. v2 by default and design
enables all of the shadow ranges as memory. So we just need to
use those ranges. That should be much easier having
On Wed, 26 Jan 2005, Eric W. Biederman wrote:
But I actually think that is overkill. v2 by default and design
enables all of the shadow ranges as memory. So we just need to
use those ranges. That should be much easier having to patch
ADLO each time. It is fairly unlikely a writable ROM segment i
> But I actually think that is overkill. v2 by default and design
> enables all of the shadow ranges as memory. So we just need to
> use those ranges. That should be much easier having to patch
> ADLO each time. It is fairly unlikely a writable ROM segment is
Ok.. Well when you put it that way
On Wed, 26 Jan 2005, Richard Smith wrote:
I don't see any reason that ADLO sould not be able to boot FreeDOS.
ADLO is a deriative of the bios from the bochs project so if you can
get bochs to boot FreeDOS or MSDOS then the same should be possible
under ADLO.
starting with FreeDOS is probably a good
On Wed, 26 Jan 2005 13:12:27 -0600, Richard Smith <[EMAIL PROTECTED]> wrote:
> > But I actually think that is overkill. v2 by default and design
> > enables all of the shadow ranges as memory. So we just need to
> > use those ranges. That should be much easier having to patch
> > ADLO each time.
* Richard Smith <[EMAIL PROTECTED]> [050126 18:40]:
> What if we created a shadow.c file that was in the northbridge
> directory with a simple API type setup that enabled and disabled the
> various shadow ranges.
What about going the LinuxBIOS table way, providing an array of writes
typedef struc
* YhLu <[EMAIL PROTECTED]> [050126 18:50]:
> For 2)
> That bit only control x4 DIMM, So please don't do that on x8 or x16. All the
> Normal BIOS only compare that to 4 only, and AMD document only said x4
> Only.
At least one commercial bios vendor does this for x8 as well, and it is
definitely n
Richard Smith <[EMAIL PROTECTED]> writes:
> Thinking about ADLO and the shadow enable/disable got some wheels turning.
>
> I've been spending lots of time in V2 and I was wondering if the same
> type of methodology can't work for ADLO.
>
> In V2 there are specifc .c files that do thing in a chip
On Wed, 26 Jan 2005, Richard Smith wrote:
> Then the ADLO build system could just romcc these files and the loader
> would include them just like crt0.S does.
it makes sense except ... why romcc? You've got memory at this point, and
Eric was pretty careful to make sure the same code will com
Thinking about ADLO and the shadow enable/disable got some wheels turning.
I've been spending lots of time in V2 and I was wondering if the same
type of methodology can't work for ADLO.
In V2 there are specifc .c files that do thing in a chipset specific
way and the auto.c includes them as necesa
For 1)
Please don't do that on amd8131_800Mhz.
Also I suggest you need to check the CPU rev to decide if set to 1GMhz.
For 2)
That bit only control x4 DIMM, So please don't do that on x8 or x16. All the
Normal BIOS only compare that to 4 only, and AMD document only said x4
Only.
For 3)
Should
Yes the posion in rom
Linbios_ram.rom
auto.c
entry
failover
reset_vector
just need to make sure entry/failover is in 64k limit. So enable_rom in
failover can be executed.
YH
> Progress however unless I am mistaken this will fail
> miserably on an 8111 that only enables 64KiB of ROM by defaul
> Look at Adam Sulmicki's ADLO work, he did something very similar to this.
I currently use ADLO so I might be able to answer your questions.
I've only sucessfully booted linux via LILO under ADLO. I mostly use
ADLO to get the video bios up and going.
I've tried to boot a MSDOS compact flash bu
On Wed, 26 Jan 2005, Digital Infra, Inc. wrote:
> First, LinuxBIOS is loaded from flash ROM. Then, it moves itself to
> uppder 16M area. and it loads some free 16bit BIOS image from somewhere
> ( e.g. HDD, USB memory or even network) to under 1M area. And LinuxBIOS
> jumps to 16bit BIOS. Of cour
Before you do anything else, set your kernel up with CONFIG_EARLY_PRINTK
You'll get output you might not get otherwise.
> I
> think filo isn't able to read the version info out of
> the kernel for some reason.
I don't think that is it.
filo will work fine with a normal bzImage anyway, you don
Hi,
I am planning to user a new 2.6 kernel for linuxbios, to be able to use klibc
and a cpio archive as an early boot image. Any hints on how to use kexec or
similar to pass the control to another kernel loaded from network/disk?
To strip down the 2.6 kernel I intent to use patches from:
www.se
hmm, that's a good point. i used the version of
mkelfImage that was part of the src tree. it reports
itself as 1.16.
# /usr/local/sbin/mkelfImage --version
/usr/local/sbin/mkelfImage 1.16
and it came from:
freebios/util/mkelfImage
now that i look, i see there is another mkelfimage in
the tree as
* Digital Infra, Inc. <[EMAIL PROTECTED]> [050126 15:20]:
>
> And it boots Windows XP?
AFAIK only Win2k, but it could be advanced.
The current URL is
http://www.missl.cs.umd.edu/sebos.html
The code is in LinuxBIOS v1 CVS
Stefan
___
Linuxbios mail
And it boots Windows XP?
Thanks! I did just reinvent the wheel.
BTW, how it has progressed?
these two URLs get not found.
http://www.missl.cs.umd.edu/Projects/sebos/main.shtml
http://www.missl.cs.umd.edu/Projects/sebos/phase2.shtml
--- Okajima.
>* Digit
Thanks! I did just reinvent the wheel.
BTW, how it has progressed?
these two URLs get not found.
http://www.missl.cs.umd.edu/Projects/sebos/main.shtml
http://www.missl.cs.umd.edu/Projects/sebos/phase2.shtml
--- Okajima.
>* Digital Infra, Inc. <[EMAIL PROTECTE
* Digital Infra, Inc. <[EMAIL PROTECTED]> [050126 13:51]:
>
> Hello.
>
> As my understanding, current LinuxBIOS can not boot Windows and
> the reason for it is that it depends on 16bit bios feature much.
> So far is right? If right, how about this way. Have you noticed already?
>
> First, LinuxB
Hello.
As my understanding, current LinuxBIOS can not boot Windows and
the reason for it is that it depends on 16bit bios feature much.
So far is right? If right, how about this way. Have you noticed already?
First, LinuxBIOS is loaded from flash ROM. Then, it moves itself to
uppder 16M area. an
Hi,
I would like to check the applied patch into LinuxBIOS CVS if nobody
happens to disagree loudly:
1) hypertransport clocking
This patch allows to disable the speed cuts during hypertransport
setup using cmos variables "amdk8_1GHz" and "amd8131_800MHz".
I've tried them on hardware wh
On Tue, Jan 25, 2005 at 11:31:10PM -0800, ramesh bios wrote:
> I converted my bzImage using mkelfImage like so:
>
> --kernel=./bzImage.in --output=bzImage.elf
> --command-line="root=/dev/hdc2 console=tty0
> console=ttyS0,38400 ro init=/sbin/init"
Which version of mkelfImage are you using? There h
40 matches
Mail list logo
