Hi, My name is Lee and my machine has a ECS Elitegroup K7S5A motherboard. It has an AMD AthlonXP 1800+ processor and (apparently) a SiS735 chipset. It also has a 2Mb Flash EEPROM for the bios (AMIBIOS right now).
Will the BIOS slot take a DoC or should I use regular replacement Flash EEPROM and is it possible to use an EEPROM/DoC with greater capacity than the current EEPROM? I'm also told I should use a Zero Insertion Force socket for the EEPROM.
Do you know a UK supplier for the M-Systems DiskOnChip because I've tried Maplin Electronics' website with no avail and google UK has found little of any use. Also, where would you reccomend I get started with LinuxBIOS?
Lee Causier, Signing off.
if you have an sis 735, cwlinux.com is a great place to start. You can actually get a motherboard from them with a linuxbios part pre-loaded.
I realize you have the mainboard, you can talk to Andrew about just buying a part.
ron
M-Systems list these as the UK distibutors:
ABACUS Polar http://www.abacus.co.uk City: Leighton Buzzard, Bedfordshire Contact: Craig Langley Tel: 01525-858070 Fax: 01525-858101 E-mail: clangley@abacus.co.uk mailto:clangley@abacus.co.uk
Arrow Contact: Daryl Kingsbury Tel: +44- 01279 455194 Fax: +44- 01279 455045 E-mail: dkingsbury@arrowuk.com mailto:dkingsbury@arrowuk.com%20
http://www.m-sys.com/content/distributors/distInfo.asp?CNTID=208&CNT=Uni...
Bari
Ronald G Minnich wrote:
if you have an sis 735, cwlinux.com is a great place to start. You can actually get a motherboard from them with a linuxbios part pre-loaded.
I realize you have the mainboard, you can talk to Andrew about just buying a part.
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Sunday 08 September 2002 5:37 pm, Bari Ari wrote:
M-Systems list these as the UK distibutors:
Abacus Polar Arrow Electronics
I contacted these last week looking for the MD-2800-D08 part.
Abacus gave me the name of a reseller and said they'd get them to contact me (but they didn't).
In meantime I bought three DoCs from Arrow Electronics - I have my own company, so they were happy to supply me direct. I'm not sure they'd do the same for a private individual.
However:
1. I believe I bought the last three MD-2800-D08 they had in stock :-)
2. They told me M-Systems are discontinuing the MD-2800 series, and replacing them with the MD-2802 series, which are "electrical and software drop-in replacements". I didn't ask what the difference between the two was.
If you can't get any joy trying to find a supplier, let me know and I'll either get some through Arrow for you (if they have more) or I might part with one I've got already...
Regards,
Antony.
On Sun, 2002-09-08 at 18:38, Lee wrote:
Hi, My name is Lee and my machine has a ECS Elitegroup K7S5A motherboard. It has an AMD AthlonXP 1800+ processor and (apparently) a SiS735 chipset. It also has a 2Mb Flash EEPROM for the bios (AMIBIOS right now).
One fundamental problem is that the DRAM init sequence for SiS 735 is too complex to fit in the 512 Byte IPL area of DoC. There used to be some samples of DoC millennium in TSOP package available which have 1024 Byte of IPL SRAM. I have no idea if they are still available or not. Don't ask about the new DoC Plus, we have no way to program it since M-system does not release the spec.
Will the BIOS slot take a DoC or should I use regular replacementFlash EEPROM and is it possible to use an EEPROM/DoC with greater capacity than the current EEPROM? I'm also told I should use a Zero Insertion Force socket for the EEPROM.
Unless you can fix the previous problem, your only chance is a Flash EEPROM.
Dear all, Thanks for the great advice, I really appreciate it. Is it possible to fit an EEPROM with a greater capacity than the current 2MB one?
Also, on an unrelated issue, I noticed that when I moved from Linux kernel 2.2.19 (c/o Debian Potato) to Linux kernel 2.4.18 (c/o Debian Woody) the Penguin logo on the framebuffer device at startup no longer has a pint of bitter statically linked to it's arm :D. Any Ideas why?
Lee Causier, signing off.
ollie lho wrote:
On Sun, 2002-09-08 at 18:38, Lee wrote:
Hi, My name is Lee and my machine has a ECS Elitegroup K7S5A motherboard. It has an AMD AthlonXP 1800+ processor and (apparently) a SiS735 chipset. It also has a 2Mb Flash EEPROM for the bios (AMIBIOS right now).
One fundamental problem is that the DRAM init sequence for SiS 735 is too complex to fit in the 512 Byte IPL area of DoC. There used to be some samples of DoC millennium in TSOP package available which have 1024 Byte of IPL SRAM. I have no idea if they are still available or not. Don't ask about the new DoC Plus, we have no way to program it since M-system does not release the spec.
Will the BIOS slot take a DoC or should I use regular replacement Flash EEPROM and is it possible to use an EEPROM/DoC with greater capacity than the current EEPROM? I'm also told I should use a Zero Insertion Force socket for the EEPROM.
Unless you can fix the previous problem, your only chance is a Flash EEPROM.
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Mon, 2002-09-09 at 09:56, Lee wrote:
Dear all, Thanks for the great advice, I really appreciate it. Is it possible to fit an EEPROM with a greater capacity than the current 2MB one?
For current architecture, 4M bits is the limit. I have no idea about how Firmware HUB does.
Also, on an unrelated issue, I noticed that when I moved from Linux kernel 2.2.19 (c/o Debian Potato) to Linux kernel 2.4.18 (c/o Debian Woody) the Penguin logo on the framebuffer device at startup no longer has a pint of bitter statically linked to it's arm :D. Any Ideas why?
The Penguin Logo does changed from 2.2.x to 2.4.x.
Ollie
Dear Ollie, Thanks, are you sure it's Megabits and not Megabytes? That'd be annoying. Anyway, I'm off to school now. I'll catch up with my mail later.
Have a nice Day,
Lee Causier.
ollie lho wrote:
On Mon, 2002-09-09 at 09:56, Lee wrote:
Dear all, Thanks for the great advice, I really appreciate it. Is it possible to fit an EEPROM with a greater capacity than the current 2MB one?
For current architecture, 4M bits is the limit. I have no idea about how Firmware HUB does.
Also, on an unrelated issue, I noticed that when I moved from Linux kernel 2.2.19 (c/o Debian Potato) to Linux kernel 2.4.18 (c/o Debian Woody) the Penguin logo on the framebuffer device at startup no longer has a pint of bitter statically linked to it's arm :D. Any Ideas why?
The Penguin Logo does changed from 2.2.x to 2.4.x.
Ollie
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Just having had a look at one of the BIOS flash vendors - there are now devices up to 8Mbit available for both firmware hub and LPC - one vendor in particular has an 8Mbit flash device which attaches directly to LPC.
I have not looked to see which chipset vendors are supporting firmware hub, but according to a bit of documentation I saw, this is aimed at the i8xx chipsets, but it appears as though there is still the 8Mbit barrier.
I guess this all depends upon the application - is the application a purely embedded solution with only flash being used, or is it a case of being able to fit a kernel into the BIOS chip - for the latter case, I guess 8Mbit would be adequate.
Hamish
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios-admin@clustermatic.org]On Behalf Of ollie lho Sent: 09 September 2002 09:12 To: Lee Cc: LinuxBIOS Mailing List Subject: Re: Any UK DiskOnChip Retailers?
On Mon, 2002-09-09 at 09:56, Lee wrote:
Dear all, Thanks for the great advice, I really appreciate it. Is it possible to fit an EEPROM with a greater capacity than
the current
2MB one?
For current architecture, 4M bits is the limit. I have no idea about how Firmware HUB does.
Also, on an unrelated issue, I noticed that when I moved from Linux kernel 2.2.19 (c/o Debian Potato) to Linux kernel 2.4.18 (c/o Debian Woody) the Penguin logo on the framebuffer device at startup no longer has a pint of bitter statically linked to it's arm :D. Any Ideas why?
The Penguin Logo does changed from 2.2.x to 2.4.x.
Ollie
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Just having had a look at one of the BIOS flash vendors - there are now devices up to 8Mbit available for both firmware hub and LPC - one vendor in particular has an 8Mbit flash device which attaches directly to LPC.
...
I guess this all depends upon the application - is the application a purely embedded solution with only flash being used, or is it a case of being able to fit a kernel into the BIOS chip - for the latter case, I guess 8Mbit would be adequate.
Yes, the SST49LF080A- 8Mbit and it has 4bits of strap options so (it appears) you can have 16 of these. I don't know how multiport termination works on LPC, though. These parts are pretty cheap too, at least, I have the 020A and it was a little over US$1.
But CF is probably better if you need lots of size, although I have also been thinking about using a raw partition on the hard disk. Has anyone tried this? The idea is to put vmlinux.bin.gz in hda1 (raw, using dd), which is say, 10MB. You know where hda1 is, just one cylinder over from the start. Then the ext2 fs is in hda2, which is the rest of the disk. The ide routines in linuxbios work fine for this, although the partition table skip-over is hardcoded and needs to be made a variable.
Anyone done this already or have comments?
-Steve
On Mon, 9 Sep 2002, Steve M. Gehlbach wrote:
But CF is probably better if you need lots of size, although I have also been thinking about using a raw partition on the hard disk. Has anyone tried this? The idea is to put vmlinux.bin.gz in hda1 (raw, using dd), which is say, 10MB. You know where hda1 is, just one cylinder over from the start. Then the ext2 fs is in hda2, which is the rest of the disk. The ide routines in linuxbios work fine for this, although the partition table skip-over is hardcoded and needs to be made a variable.
Anyone done this already or have comments?
yep, I've done it, it works fine.
And key is Eric's code which will hunt the elf header down ...
ron
The idea is to put vmlinux.bin.gz in hda1 (raw, using dd),
which is say, 10MB. You know where hda1 is, just one cylinder
over from the
start. Then the ext2 fs is in hda2, which is the rest of the
disk. The ide
routines in linuxbios work fine for this, although the partition table skip-over is hardcoded and needs to be made a variable.
Anyone done this already or have comments?
yep, I've done it, it works fine.
And key is Eric's code which will hunt the elf header down ...
Could you be more specific about elf. I was using option BOOT_IDE which uses ide_fill_inbuf.c etc. Seems to work for a raw partition, but I have not tried the combination with the Linux ext2fs in the other partition (right now using a ramdisk loaded from a floppy as the rootfs). Are you talking about ELF_BOOT?
/sg
On Mon, 9 Sep 2002, Steve M. Gehlbach wrote:
And key is Eric's code which will hunt the elf header down ...
Could you be more specific about elf. I was using option BOOT_IDE which uses ide_fill_inbuf.c etc. Seems to work for a raw partition, but I have not tried the combination with the Linux ext2fs in the other partition (right now using a ramdisk loaded from a floppy as the rootfs). Are you talking about ELF_BOOT?
If you put the raw ELF image in /dev/hda1, eric's code will read block after block hunting for that elf header. Point being that you can put the elfimage in /dev/hda1, and are not constrained to putting it in /dev/hda.
ron
"Hamish Guthrie (Mail Lists)" hamishl@dplanet.ch writes:
Just having had a look at one of the BIOS flash vendors - there are now devices up to 8Mbit available for both firmware hub and LPC - one vendor in particular has an 8Mbit flash device which attaches directly to LPC.
I have not looked to see which chipset vendors are supporting firmware hub, but according to a bit of documentation I saw, this is aimed at the i8xx chipsets, but it appears as though there is still the 8Mbit barrier.
To be clear the firmware hub is a variant on the LPC bus. And as addresses are clocked across the LPC bus there is no theoretical ROM size limit.
I guess this all depends upon the application - is the application a purely embedded solution with only flash being used, or is it a case of being able to fit a kernel into the BIOS chip - for the latter case, I guess 8Mbit would be adequate.
I suspect Beoboot would be a tight fit, but that is a different problem.
Eric
Ronald G Minnich rminnich@lanl.gov writes:
On Mon, 9 Sep 2002, Steve M. Gehlbach wrote:
And key is Eric's code which will hunt the elf header down ...
Could you be more specific about elf. I was using option BOOT_IDE which uses ide_fill_inbuf.c etc. Seems to work for a raw partition, but I have not tried the combination with the Linux ext2fs in the other partition (right now using a ramdisk loaded from a floppy as the rootfs). Are you talking about ELF_BOOT?
Yes.
If you put the raw ELF image in /dev/hda1, eric's code will read block after block hunting for that elf header. Point being that you can put the elfimage in /dev/hda1, and are not constrained to putting it in /dev/hda.
The easy solution is putting the whole image in /dev/hda1 thought it is theoretically possible to put the image on a filesystem and just setup an ELF header at the start of the disk that points to it.
Etherboot also supports booting this way. And it will allow you to multiplex between a hard drive and the network. So it is definitely a good direction to look at.
Eric
The easy solution is putting the whole image in /dev/hda1 thought it is theoretically possible to put the image on a filesystem and just setup an ELF header at the start of the disk that points to it.
Etherboot also supports booting this way. And it will allow you to multiplex between a hard drive and the network. So it is definitely a good direction to look at.
The raw image is most appealing to me rather than a filesystem. It's simple and easy. I don't know much about ELF headers.
My systems can only boot from the hdd, the network is not always in use. I was under the impression Etherboot was for only for networks. I assume Etherboot within Linuxbios is the option USE_TFTP. How does the disk/net multiplex work? I am not familiar with that.
-Steve
"Steve M. Gehlbach" steve@nexpath.com writes:
The easy solution is putting the whole image in /dev/hda1 thought it is theoretically possible to put the image on a filesystem and just setup an ELF header at the start of the disk that points to it.
Etherboot also supports booting this way. And it will allow you to multiplex between a hard drive and the network. So it is definitely a good direction to look at.
The raw image is most appealing to me rather than a filesystem. It's simple and easy. I don't know much about ELF headers.
My systems can only boot from the hdd, the network is not always in use. I was under the impression Etherboot was for only for networks. I assume Etherboot within Linuxbios is the option USE_TFTP.
Nope the external etherboot project.
How does the disk/net multiplex work? I am not familiar with that.
You have never set the boot order in the BIOS? Roughly you have a booloader that can boot off of either the hard driver or the network.
Eric
My systems can only boot from the hdd, the network is not
always in use. I
was under the impression Etherboot was for only for networks. I assume Etherboot within Linuxbios is the option USE_TFTP.
Nope the external etherboot project.
Thanks, within 5-10 minutes of trying TFTP I figured out it that wasn't it. A kind soul sent me an email pointing me to the URL of Etherboot. I was not previously familiar with the project.
How does the disk/net multiplex work? I am not familiar with that.
You have never set the boot order in the BIOS? Roughly you have a booloader that can boot off of either the hard driver or the network.
I guess my question was more about the mechanics of doing it. Is it possible to multiplex without a BIOS, completely within a (no PC-BIOS) Etherboot started from linuxbios? And if the answer is yes, then how do you specify the disk, partition, and what is the format, etc.
-Steve
"Steve M. Gehlbach" steve@nexpath.com writes:
How does the disk/net multiplex work? I am not familiar with that.
You have never set the boot order in the BIOS? Roughly you have a booloader that can boot off of either the hard driver or the network.
I guess my question was more about the mechanics of doing it. Is it possible to multiplex without a BIOS, completely within a (no PC-BIOS) Etherboot started from linuxbios?
Yes. At least in the current development version. 5.1.2+
And if the answer is yes, then how do you specify the disk, partition, and what is the format, etc.
It depends. The code is still maturing so all of the details have not been worked out.
My prefered way of doing it is to scan the first 8K for an ELF header and to find the rest of the image from the pointers within that header.
If there is nothing on one disk etherboot will continue looking at other possible boot devices.
For the time being I just put a partition at the start of the disk right after the partition table and everything works. Likely a better way to manage this so you can multiple kernels on the hard drive will evolve.
There are some other development version that have been thrown around by Ollie Lho and Adam Agnew that actually includes a partition and a a filesystem parser. Personally I don't think those are necessary in the firmware, but people who think otherwise are free to implement it. The code structure in etherboot is now clean enough it should fit in cleanly.
Mostly I think there is a very large difference between code that resides in firmware that as a matter of policy you don't want to update, and you want very simple so you can reuse and verify it is correct. And code that you read off of a hard drive that is easy to update and replace without chance of killing your computer. And I do not believe it is appropriate for the system rom to set such a precedent, when alternatives exist.
But it is all a policy matter and in the long run I will go with whatever works.
Eric
On Mon, 2002-09-16 at 13:30, Eric W. Biederman wrote:
"Steve M. Gehlbach" steve@nexpath.com writes:
How does the disk/net multiplex work? I am not familiar with that.
You have never set the boot order in the BIOS? Roughly you have a booloader that can boot off of either the hard driver or the network.
I guess my question was more about the mechanics of doing it. Is it possible to multiplex without a BIOS, completely within a (no PC-BIOS) Etherboot started from linuxbios?
Yes. At least in the current development version. 5.1.2+
And if the answer is yes, then how do you specify the disk, partition, and what is the format, etc.
There are some other development version that have been thrown around by Ollie Lho and Adam Agnew that actually includes a partition and a a filesystem parser. Personally I don't think those are necessary in the firmware, but people who think otherwise are free to implement it. The code structure in etherboot is now clean enough it should fit in cleanly.
We have an internal version of Etherboot which contains some code from GRUB. The GRUB code let us put kernel image on a filesystem and the way to specify the patch to kernel is the same as GRUB.
Ollie
* ollie lho ollie@sis.com.tw [020916 07:46]:
We have an internal version of Etherboot which contains some code from GRUB. The GRUB code let us put kernel image on a filesystem and the way to specify the patch to kernel is the same as GRUB.
Are your patches available somewhere?
Stefan
On Mon, 2002-09-16 at 19:19, Stefan Reinauer wrote:
- ollie lho ollie@sis.com.tw [020916 07:46]:
We have an internal version of Etherboot which contains some code from GRUB. The GRUB code let us put kernel image on a filesystem and the way to specify the patch to kernel is the same as GRUB.
Are your patches available somewhere?
I will send you the .tgz in another mail.
Ollie
ollie lho ollie@sis.com.tw writes:
On Mon, 2002-09-16 at 19:19, Stefan Reinauer wrote:
- ollie lho ollie@sis.com.tw [020916 07:46]:
We have an internal version of Etherboot which contains some code from GRUB. The GRUB code let us put kernel image on a filesystem and the way to specify the patch to kernel is the same as GRUB.
Are your patches available somewhere?
I will send you the .tgz in another mail.
Is this stuff useful enough to merge with the stock etherboot?
Eric
On Tue, 2002-09-17 at 14:24, Eric W Biederman wrote:
ollie lho ollie@sis.com.tw writes:
On Mon, 2002-09-16 at 19:19, Stefan Reinauer wrote:
- ollie lho ollie@sis.com.tw [020916 07:46]:
We have an internal version of Etherboot which contains some code from GRUB. The GRUB code let us put kernel image on a filesystem and the way to specify the patch to kernel is the same as GRUB.
Are your patches available somewhere?
I will send you the .tgz in another mail.
Is this stuff useful enough to merge with the stock etherboot?
IMHO, booting from kernel image on filesystem is more similar to what average end-user used to than booting from a boot partition. I have no idea if this makes it useful enough.
Ollie
On 17 Sep 2002, ollie lho wrote:
IMHO, booting from kernel image on filesystem is more similar to what average end-user used to than booting from a boot partition. I have no idea if this makes it useful enough.
I agree with you here.
Interestingly enough the 9load program now understands the native Plan 9 file system, kfs. No more FAT partitions.
ron
Ronald G Minnich rminnich@lanl.gov writes:
On 17 Sep 2002, ollie lho wrote:
IMHO, booting from kernel image on filesystem is more similar to what average end-user used to than booting from a boot partition. I have no idea if this makes it useful enough.
I agree with you here.
I also do. Ultimately putting kernels onto a filesystem that needs to be the interface. The question is what is the most maintainable route to get there.
I run on the assumption that for general purpose machines, I want to limit flashing the BIOS as much as possible.
For an embedded or special purpose machine it is not a problem to build everything to know your local filesystem and partition types. For a more general purpose configuration, it potentially becomes a support problem. Which is why I am leery of putting the entire bootloader functionality into the firmware. I definitely can not give every one beoboot for example because my largest customers disagree about wanting it.
Anyway this looks like time will tell we don't have so much development energy flying around that if we don't agree we will have 10 incompatible versions. We should be able to each use what works for them and then compare notes.
Interestingly enough the 9load program now understands the native Plan 9 file system, kfs. No more FAT partitions.
Nice. But has it stopped supporting FAT so all of the users who used FAT are in trouble?
Eric
On 17 Sep 2002, Eric W Biederman wrote:
Interestingly enough the 9load program now understands the native Plan 9 file system, kfs. No more FAT partitions.
Nice. But has it stopped supporting FAT so all of the users who used FAT are in trouble?
no. I wonder if in the year 2500 people will still write code for FAT.
Using quantum computers of course.
ron
Ronald G Minnich rminnich@lanl.gov writes:
On 17 Sep 2002, Eric W Biederman wrote:
Interestingly enough the 9load program now understands the native Plan 9 file system, kfs. No more FAT partitions.
Nice. But has it stopped supporting FAT so all of the users who used FAT are in trouble?
no. I wonder if in the year 2500 people will still write code for FAT.
Using quantum computers of course.
No. I'm pretty certain the spec will be in machine comprehensible form and the computers will write the code in 2500 :)
Eric
-
Antony Stone -
Bari Ari -
ebiederman＠lnxi.com -
Eric W Biederman
-
Hamish Guthrie (Mail Lists) -
Lee -
ollie lho -
Ronald G Minnich -
Stefan Reinauer -
Steve M. Gehlbach