Hi! I'm a newbie with linuxbios (and linux for that matter).
We are in the process of creating a stripped-down (but extremely dense) dual Opteron server. It is basically a pair of Opterons and an 8111 that has a 10/100 NIC, a pair of USB ports, and an IDE interface, along with 4GB of RAM. We'd like to run linuxbios on it.
I have an Arima Hdma dual Opteron system I am using for development. I'd like to start by building a linuxbios for the Arima system. I have been able to build and run a 64-bit kernel from the Suse _64 distribution on the Arima system successfully.
I have downloaded the latest (as of yesterday) freebios2 tree from sourceforge.net. I went to targets and ran: # buildtarget arima/hdama
Then I did the following: # cd arima/hdma/hdma # make
It successfully made romcc, but when it tried to run it to make either the failover or normal rom, it gets the following error: reset_test.c:13,111: 0x1e43570 copy Internal compiler error: bad type passed to copy
I'm probably missing some steps, or starting in the wrong place. I'd appreciate some advice. I spent some time looking through the archives, but did not find any definitive tutorial for the latest linuxbios creation (although the March 2003 linux-magazine article was useful to gain a perspective).
Any help appreciated. I've been reading the mailing list for about a month, and I'm impressed with the progress this group has made.
Thanks,
Craig
========================================================== Craig C. Forney cforney@opus.com Opus Innovations LLC http://www.opus.com ==========================================================
On Sat, 13 Sep 2003, Craig C. Forney wrote:
It successfully made romcc, but when it tried to run it to make either the failover or normal rom, it gets the following error: reset_test.c:13,111: 0x1e43570 copy Internal compiler error: bad type passed to copy
romcc is sensitive to the version of linux you are running at present.
You have done everything right, or it seems you have.
What distro and version of distro are you running?
ron
ron minnich rminnich@lanl.gov writes:
On Sat, 13 Sep 2003, Craig C. Forney wrote:
It successfully made romcc, but when it tried to run it to make either the failover or normal rom, it gets the following error: reset_test.c:13,111: 0x1e43570 copy Internal compiler error: bad type passed to copy
romcc is sensitive to the version of linux you are running at present.
Ron how so? If romcc compiles it should work. I don't have any excuse for romcc to behave different depending on what compiler compiles it.
Eric
* Eric W. Biederman ebiederman@lnxi.com [030915 13:10]:
Ron how so? If romcc compiles it should work. I don't have any excuse for romcc to behave different depending on what compiler compiles it.
But there is a difference in the resulting romcc depending on whether you compile it for AMD64 or IA32. I tracked it down to lines 211 and 212: /* Long on the destination platform */ typedef unsigned long ulong_t; typedef long long_t;
The IA32 version of the size_of() function will return 4 when it gets a pointer or a long, whereas the AMD64 version will return 8.
The function transform_to_arch_instruction checks the result of size_of() in the OP_COPY branch of the big case statement and fails with an internal compiler error if the size is not 1, 2 or 4.
Since IA32 code (including AMD64 special registers) is the only target platform currently supported, it should be OK to change above typedefs to 4 byte types. If this seems not appropriate it might make sense to seperate the platform dependent code into several files and have an additional target for AMD64 long mode.
Stefan
Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@lnxi.com [030915 13:10]:
Ron how so? If romcc compiles it should work. I don't have any excuse for romcc to behave different depending on what compiler compiles it.
But there is a difference in the resulting romcc depending on whether you compile it for AMD64 or IA32. I tracked it down to lines 211 and 212: /* Long on the destination platform */ typedef unsigned long ulong_t; typedef long long_t;
The IA32 version of the size_of() function will return 4 when it gets a pointer or a long, whereas the AMD64 version will return 8.
The function transform_to_arch_instruction checks the result of size_of() in the OP_COPY branch of the big case statement and fails with an internal compiler error if the size is not 1, 2 or 4.
Ok. That looks like an easy mistake to make and it sounds reasonable that it exists.
Since IA32 code (including AMD64 special registers) is the only target platform currently supported, it should be OK to change above typedefs to 4 byte types. If this seems not appropriate it might make sense to seperate the platform dependent code into several files and have an additional target for AMD64 long mode.
That is where I want to go eventually. For now which ever is most convenient.
I have been doing my best to abstract things so I can add additional ports without too much trouble but I have not been worry about it very much.
Eric
But there is a difference in the resulting romcc depending on whether you compile it for AMD64 or IA32. I tracked it down to lines 211 and 212: /* Long on the destination platform */ typedef unsigned long ulong_t; typedef long long_t;
The IA32 version of the size_of() function will return 4 when it gets a pointer or a long, whereas the AMD64 version will return 8.
The function transform_to_arch_instruction checks the result of size_of() in the OP_COPY branch of the big case statement and fails with an internal compiler error if the size is not 1, 2 or 4.
Although I certainly don't understand all the implications, I changed lines 211 and 212 to:
typedef unsigned int ulong_t; typedef int long_t;
and made romcc on an Opteron based system running the 8.2 beta. Romcc got further, but failed with the following:
console.c: 136.35: Incompatible types in initializer
As an experiment I went ahead and commented out the code in console.c that it was complaining about. The next failure was a malloc error with a HUGE malloc value ... So I gave up and built a PC with a standard Intel 32-bit processor, reloaded everything, and romcc appears to work just fine. It built a ROM image, at least.
I thought I might get lucky building on the Opteron system with the changes, but not today.
Thanks for your help.
Regards,
Craig
========================================================== Craig C. Forney email : cforney@opus.com Opus Innovations LLC www : http://www.opus.com ==========================================================
On 15 Sep 2003, Eric W. Biederman wrote:
romcc is sensitive to the version of linux you are running at present.
Ron how so? If romcc compiles it should work. I don't have any excuse for romcc to behave different depending on what compiler compiles it.
it makes no sense to me either, as romcc is clean and well-written. It is just what I have seen: it won't work on my RH 7.3 box, with: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
BTW, config.py as of today doesn't work with this error: File "/home/rminnich/src/freebios2/util/newconfig/config.py", line 1393, in term return long(NUM, 10) TypeError: long requires exactly 1 argument; 2 given
I think somebody broke something. Python it turns out rotates function definitions frequently, with the result that it is hard to write python-version-independent code.
ron
ron minnich rminnich@lanl.gov writes:
On 15 Sep 2003, Eric W. Biederman wrote:
romcc is sensitive to the version of linux you are running at present.
Ron how so? If romcc compiles it should work. I don't have any excuse for romcc to behave different depending on what compiler compiles it.
it makes no sense to me either, as romcc is clean and well-written. It is just what I have seen: it won't work on my RH 7.3 box, with: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
Hmm. Ok. When you get a good datapoint...
BTW, config.py as of today doesn't work with this error: File "/home/rminnich/src/freebios2/util/newconfig/config.py", line 1393, in term return long(NUM, 10) TypeError: long requires exactly 1 argument; 2 given
I think somebody broke something. Python it turns out rotates function definitions frequently, with the result that it is hard to write python-version-independent code.
Which rev of python is this?
Either I am not executing this, in my configuration file. Or it works fine for me with python2.1 python2.2 and python2.3
Eric
On 15 Sep 2003, Eric W. Biederman wrote:
Either I am not executing this, in my configuration file. Or it works fine for me with python2.1 python2.2 and python2.3
I'll look at version, I just hit this and then had to go to work.
ron
Has anyone done any thinking about booting from USB memory keys? I noticed an article on Dell's site from June, that Ford Motor has standardized on Dells with no floppy and boot capable from USB memory keys. Apparently it is Dell's own BIOS standard to do this. At least, it isn't in the BIOS Boot Specification and I don't recall seeing it in any BIOS I've used lately. I don't own any Dells, though.
-Steve
On Monday 15 September 2003 10:24 pm, Steve Gehlbach wrote:
Has anyone done any thinking about booting from USB memory keys?
Do you mean the little solid state things commonly known as flash drives (even though there's no 'drive' as such)?
I noticed an article on Dell's site from June, that Ford Motor has standardized on Dells with no floppy and boot capable from USB memory keys. Apparently it is Dell's own BIOS standard to do this. At least, it isn't in the BIOS Boot Specification and I don't recall seeing it in any BIOS I've used lately. I don't own any Dells, though.
The Bios of anything I've seen in the past 12-18 months has been capable of booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip
The solid state flash drives behave exactly like USB-IDE as far as what they're plugged into is concerned - just like Compact Flash cards vs. normal IDE drives.
Regards,
Antony.
Antony Stone wrote:
The Bios of anything I've seen in the past 12-18 months has been capable of booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip
The solid state flash drives behave exactly like USB-IDE as far as what they're plugged into is concerned - just like Compact Flash cards vs. normal IDE drives.
Hmmm... I guess I need to look at a current BIOS, I must have overlooked it.
Anyway, any idea how much work it would be to get linuxbios to be able to read the USB-IDE?
-Steve
Steve Gehlbach steve@nexpath.com writes:
Antony Stone wrote:
The Bios of anything I've seen in the past 12-18 months has been capable of booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip The solid state flash drives behave exactly like USB-IDE as far as what they're plugged into is concerned - just like Compact Flash cards vs. normal IDE drives.
Hmmm... I guess I need to look at a current BIOS, I must have overlooked it.
Anyway, any idea how much work it would be to get linuxbios to be able to read the USB-IDE?
I don't think there is USB-IDE. I think the stack looks like USB-SCSI.
The challenge is that the USB stack is fairly tall.
We should be able to incorporate a version of that into etherboot or FILO.
I don't think we want a version of that in the core of LinuxBIOS, but I can be surprised.
Eric
Eric W. Biederman wrote:
I don't think there is USB-IDE. I think the stack looks like USB-SCSI.
The challenge is that the USB stack is fairly tall.
We should be able to incorporate a version of that into etherboot or FILO.
I don't think we want a version of that in the core of LinuxBIOS, but I can be surprised.
I checked the latest EPIA BIOS and it says USB-HDD.
I figured the USB stack was deep; I may do some experimenting with Linux and booting from one of these and see what is involved.
I haven't checked the price to see how these compare with Compact Flash, but the small size and ease of customer installation is attractive. The CF requires an adaptor to IDE that is a little awkward. The USB flash memory can be installed by a customer without opening the case, and saves the price of a CDROM drive (and the mechanical failure problems with a CDROM drive). All of this is from the standpoint of an embedded system and may be of no interest to clusters.
-Steve
I think the USB stuff is of interest. I'm clueless how to write the support for USB however, but I think it's worth somebody looking at it.
ron
Steve Gehlbach steve@nexpath.com writes:
Eric W. Biederman wrote:
I don't think there is USB-IDE. I think the stack looks like USB-SCSI. The challenge is that the USB stack is fairly tall. We should be able to incorporate a version of that into etherboot or FILO. I don't think we want a version of that in the core of LinuxBIOS, but I can be surprised.
I checked the latest EPIA BIOS and it says USB-HDD.
I figured the USB stack was deep; I may do some experimenting with Linux and booting from one of these and see what is involved.
I haven't checked the price to see how these compare with Compact Flash, but the
small size and ease of customer installation is attractive. The CF requires an adaptor to IDE that is a little awkward. The USB flash memory can be installed by a customer without opening the case, and saves the price of a CDROM drive (and the mechanical failure problems with a CDROM drive). All of this is from the standpoint of an embedded system and may be of no interest to clusters.
I totally think USB is interesting.
My only concern is that we will have more problems getting it right than we did IDE.
Eric
Eric W. Biederman wrote:
I totally think USB is interesting.
My only concern is that we will have more problems getting it right than we did IDE.
No kidding, it is clearly much more complicated than IDE, that's for sure. But all of that aside, it would be a slick way to boot from linuxbios.
-Steve
Hi,
I checked the latest EPIA BIOS and it says USB-HDD.
Under Linux, it uses USB and SCSI stack to access USB IDE harddisk or USB flash disk.
I figured the USB stack was deep; I may do some experimenting with Linux and booting from one of these and see what is involved. I haven't checked the price to see how these compare with Compact Flash, but the small size and ease of customer installation is attractive. The
It is just a little more expensive than CF, but its size is much smaller.
CF requires an adaptor to IDE that is a little awkward. The USB flash memory can be installed by a customer without opening the case, and saves the price of a CDROM drive (and the mechanical failure problems with a CDROM drive). All of this is from the standpoint of an embedded system and may be of no interest to clusters.
I think we can take a look at u-boot which has USB storage access already.
-Andrew
On Tue, Sep 16, 2003 at 11:12:44AM +0800, Andrew Ip wrote:
I think we can take a look at u-boot which has USB storage access already.
I've been interested in supporting USB storage (as well as keyboards) in FILO, but I didn't know where to start. I'm now looking at the sourcecode of u-boot, and I think this is what I've been looking for. Thanks a lot, Andrew!
-- Takeshi
Greetings,
Just getting caught up again. I have a more or less functional polling USB stack for UHCI controllers built on the baremetal toolkit. So far, it works on some devices but not others.
I'm cleaning it up now, but should be able to get it in CVS in the next few days.
G'day, sjames
On Tue, 16 Sep 2003, SONE Takeshi wrote:
On Tue, Sep 16, 2003 at 11:12:44AM +0800, Andrew Ip wrote:
I think we can take a look at u-boot which has USB storage access already.
I've been interested in supporting USB storage (as well as keyboards) in FILO, but I didn't know where to start. I'm now looking at the sourcecode of u-boot, and I think this is what I've been looking for. Thanks a lot, Andrew!
-- Takeshi _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Tue, Sep 16, 2003 at 05:44:31PM -0400, steven james wrote:
Just getting caught up again. I have a more or less functional polling USB stack for UHCI controllers built on the baremetal toolkit. So far, it works on some devices but not others.
That sounds great. I would love to see this code.
-- Takeshi
Hello Antony,
Tuesday, September 16, 2003, 1:31:40 AM, you wrote:
AS> The Bios of anything I've seen in the past 12-18 months has been capable of AS> booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip
AS> The solid state flash drives behave exactly like USB-IDE as far as what AS> they're plugged into is concerned - just like Compact Flash cards vs. normal AS> IDE drives.
Actually, most USB flash drives comply to USB-ZIP, not to USB-IDE.
With best regards, Alexander spirit@reactor.ru
--8<--just-a-cookie---------------------------------------------- Solution for any problem of your life can be found on the Net. You just need to know how to search. --8<-------------------------------------------------------------
Hello (again) from Gregg C Levine Actually gentlemen, and ladies, no it is not. I have available for this system a USB Key Drive, from Memorex, and a CF reader, also from them. To use them under Linux, I need to turn on SCSI, and USB-Mass drive support. Also, the mass drive functions look more like SCSI to me, then anything like IDE. Granted this is one example.
I grok, that there are others out there who do use IDE, but I doubted. There are mistakes in the mass transport layers for Linux, certainly. But nothing that gross. Incidentally that's the 2.4.20 group, and I am using Slackware Linux here. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios- admin@clustermatic.org] On Behalf Of Alexander Amelkin Sent: Tuesday, September 16, 2003 2:08 AM To: Antony Stone Cc: linuxbios@clustermatic.org Subject: Re[2]: USB Memory Key booting
Hello Antony,
Tuesday, September 16, 2003, 1:31:40 AM, you wrote:
AS> The Bios of anything I've seen in the past 12-18 months has been
capable of
AS> booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip
AS> The solid state flash drives behave exactly like USB-IDE as far
as what
AS> they're plugged into is concerned - just like Compact Flash
cards vs. normal
AS> IDE drives.
Actually, most USB flash drives comply to USB-ZIP, not to USB-IDE.
With best regards, Alexander spirit@reactor.ru
--8<--just-a-cookie---------------------------------------------- Solution for any problem of your life can be found on the Net. You
just need to
know how to search. --8<-------------------------------------------------------------
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Tue, 16 Sep 2003, Gregg C Levine wrote:
Actually gentlemen, and ladies, no it is not. I have available for this system a USB Key Drive, from Memorex, and a CF reader, also from them. To use them under Linux, I need to turn on SCSI, and USB-Mass drive support. Also, the mass drive functions look more like SCSI to me, then anything like IDE. Granted this is one example.
here again is the case for linux in the bios, if only the flash parts were big enough. Linux in the bios could easily drive all usb devices for mass storage, and boot linux off the mass store. Without linux in the bios, we will have to write all that code and deal with all the hardware bugs.
If only the flash parts would get big.
ron
"Craig C. Forney" cforney@opus.com writes:
Hi! I'm a newbie with linuxbios (and linux for that matter).
We are in the process of creating a stripped-down (but extremely dense) dual Opteron server. It is basically a pair of Opterons and an 8111 that has a 10/100 NIC, a pair of USB ports, and an IDE interface, along with 4GB of RAM. We'd like to run linuxbios on it.
Sounds reasonable.
I have an Arima Hdma dual Opteron system I am using for development. I'd like to start by building a linuxbios for the Arima system. I have been able to build and run a 64-bit kernel from the Suse _64 distribution on the Arima system successfully.
I have downloaded the latest (as of yesterday) freebios2 tree from sourceforge.net. I went to targets and ran: # buildtarget arima/hdama
Then I did the following: # cd arima/hdma/hdma # make
It successfully made romcc, but when it tried to run it to make either the failover or normal rom, it gets the following error: reset_test.c:13,111: 0x1e43570 copy Internal compiler error: bad type passed to copy
I'm probably missing some steps, or starting in the wrong place. I'd appreciate some advice. I spent some time looking through the archives, but did not find any definitive tutorial for the latest linuxbios creation (although the March 2003 linux-magazine article was useful to gain a perspective).
Any help appreciated. I've been reading the mailing list for about a month, and I'm impressed with the progress this group has made.
Something very strange is going on. If you get an error like that it should be:
reset_test.c:13.111: 0x1e43570 copy Internal compiler error: bad type passed to copy
The comma instead of the period is worrisome.
So far everything has been done with a 32bit toolchain. So that may account for some of the differences. If romcc has problems as Ron suggests when it is a compiled with different compilers that is something needs to get fixed, as that is a very bad bug and not the kind I would expect to still remain in the code.
Eric
-
Alexander Amelkin -
Andrew Ip -
Antony Stone -
Craig C. Forney -
ebiederman＠lnxi.com -
Gregg C Levine -
ron minnich -
SONE Takeshi -
Stefan Reinauer -
Steve Gehlbach -
steven james