For s2880 that with LSI scsi FW and some other ATI onboad Server Mainboard may need us to put the FW or VGA ROM in the linuxbios.rom too.
For s2880 I cat lsiscsifw, normal, and fallback together.
-----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年9月12日 10:05 收件人: LinuxBIOS 主题: extending "buildrom"
Hi,
to get used to the config tool, I wrote the attached little patch to change the buildrom command to allow specifying a filename of a rom file that is produced when building LinuxBIOS
i.e. buildrom ROM_SIZE "normal" "fallback" changed to: buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"
creating a linuxbios.rom file in the build target directory that consists of the 2 concatenated romimages "normal" and "fallback" This way it's now possible to build several roms with "buildrom" that take the specified "romimage"s that were built. This could i.e. be used to build several roms at once i.e. with different payloads in them.
Is this ok to check in?
* YhLu YhLu@tyan.com [030912 19:20]:
For s2880 that with LSI scsi FW and some other ATI onboad Server Mainboard may need us to put the FW or VGA ROM in the linuxbios.rom too.
For s2880 I cat lsiscsifw, normal, and fallback together.
then we should maybe change this to fit the other linuxbios config commands, maybe like this:
buildrom <imagename.rom> size ROM_SIZE data ./lsiscsifw 65536 image normal NORMAL_SIZE image fallback FALLBACK_SIZE end
Or maybe it makes sense to move the payloads into the buildrom section as well and keep the romimage tag for building the LinuxBIOS code only while the buildrom tag describes the composition of the final rom image to flash?
Stefan
On Mon, 15 Sep 2003, Stefan Reinauer wrote:
buildrom <imagename.rom> size ROM_SIZE data ./lsiscsifw 65536
????????? What is that data thing?
ron
image normal NORMAL_SIZE
no, you need this info when you build the board, it can't move here.
Or maybe it makes sense to move the payloads into the buildrom section as well and keep the romimage tag for building the LinuxBIOS code only while the buildrom tag describes the composition of the final rom image to flash?
it's not a romimage tag, it's the name of the output file, I thought.
ron
* ron minnich rminnich@lanl.gov [030915 16:51]:
On Mon, 15 Sep 2003, Stefan Reinauer wrote:
buildrom <imagename.rom> size ROM_SIZE data ./lsiscsifw 65536
????????? What is that data thing?
I assumed that packing option roms or similar data hunks into an image might become more and more a default. But it does not really fit, I agree.
image normal NORMAL_SIZE
no, you need this info when you build the board, it can't move here.
What information is needed? I would have thought it's only the start address of the payload?
Stefan
On Tue, 16 Sep 2003, Stefan Reinauer wrote:
- ron minnich rminnich@lanl.gov [030915 16:51]:
On Mon, 15 Sep 2003, Stefan Reinauer wrote:
buildrom <imagename.rom> size ROM_SIZE data ./lsiscsifw 65536
????????? What is that data thing?
I assumed that packing option roms or similar data hunks into an image might become more and more a default. But it does not really fit, I agree.
Now that you've explained it, I realize that's a really good idea. It would eliminate much kludgery that we have for the linuxbios splash image.
image normal NORMAL_SIZE
no, you need this info when you build the board, it can't move here.
What information is needed? I would have thought it's only the start address of the payload?
Actually it is good to have it here after all, as it is a double-check: if the "normal" image is not NORMAL_SIZE then there is a problem in building.
I would like as many checks as possible in this process, since when things go wrong the machine usually sits there with no output.
ron
On Tue, 16 Sep 2003, ron minnich wrote:
On Tue, 16 Sep 2003, Stefan Reinauer wrote:
- ron minnich rminnich@lanl.gov [030915 16:51]:
On Mon, 15 Sep 2003, Stefan Reinauer wrote:
buildrom <imagename.rom> size ROM_SIZE data ./lsiscsifw 65536
So the one change I'd make is to have an optional offset.
data ./lsiscsifs 65536 image normal NORMAL_SIZE 0x20000
etc.
This would be so that you could have non-contiguous data areas.
ron