SATA devices should be in legacy mode and filo should be able to load
your
kernel. The only challenge is getting the drive numbering lined up. in buildrom do a make filo-config. You also need a grub like menu.lst
on
the drive.
I thought there was no legacy mode because it's Nvidia's CK804. If
there is
I went through a lot of pain for nothing (except learning of course :)
Ah, it would be a controller limitation not a filo one. Sorry. I didn't mean to confuse the issue.
No problem. I should have been clearer in the original response. You probably helped clarify it for everyone else.
Myles
Hello, I'm the newb that Myles was kind enough to address in the original post.
Sorry in advance if I ask stupid questions that are covered in a FAQ or the like. If that's the case, I can't seem to find it, so feel free to point me in that direction.
What I'm trying to do, is take an existing Linux installation (on a SATA disk) and shrink the BIOS-related part of the boot time. I don't ever need to boot with different kernels or ramdisks. They will always be located at /dev/sda1/boot/<static kernel|initrd name>.
So I grabbed the latest buildrom from SVN, and had trouble doing a 'make menuconfig' on various Linux boxes. I was finally able to do a 'make menuconfig' after installing ncurses on an Ubuntu box, and then after selecting the appropriate options for the Tyan S2892, and FILO (before I saw Myle's response), the long awaited tyan-s2892.rom file appeared in my deploy directory.
In the discussion between Myles and Marc about SATA/FILO, I became more confused about what my payload should be. Based on my system configuration, should I use FILO? LAB? GRUB2? What is "legacy mode" SATA?
The first ROM image I created painted some nice pinstripes on the display after a warm reboot, and when I fully powered down and started again, I got a nice alternating tone from the PC speaker. I'm suspecting this has something to do with my payload. Either it is wrong entirely, or it needs additional configuration.
Serial console output seems to indicate that basic coreboot initialization was happening, but maybe never got to the point where it could give me useful VGA output.
Sorry also for top-posting, but I'm stuck with Outlook.
-Bijoy
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Myles Watson Sent: Friday, November 07, 2008 4:30 PM To: 'Marc Jones' Cc: 'Coreboot' Subject: Re: [coreboot] Coreboot on Tyan S2892
SATA devices should be in legacy mode and filo should be able to load
your
kernel. The only challenge is getting the drive numbering lined
up.
in buildrom do a make filo-config. You also need a grub like menu.lst
on
the drive.
I thought there was no legacy mode because it's Nvidia's CK804. If
there is
I went through a lot of pain for nothing (except learning of course :)
Ah, it would be a controller limitation not a filo one. Sorry. I didn't mean to confuse the issue.
No problem. I should have been clearer in the original response. You probably helped clarify it for everyone else.
Myles
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Sorry in advance if I ask stupid questions that are covered in a FAQ or the like. If that's the case, I can't seem to find it, so feel free to point me in that direction.
These aren't stupid questions. There are plenty of non-obvious things here.
What I'm trying to do, is take an existing Linux installation (on a SATA disk) and shrink the BIOS-related part of the boot time. I don't ever need to boot with different kernels or ramdisks. They will always be located at /dev/sda1/boot/<static kernel|initrd name>.
So I grabbed the latest buildrom from SVN, and had trouble doing a 'make menuconfig' on various Linux boxes. I was finally able to do a 'make menuconfig' after installing ncurses on an Ubuntu box, and then after selecting the appropriate options for the Tyan S2892, and FILO (before I saw Myle's response), the long awaited tyan-s2892.rom file appeared in my deploy directory.
In the discussion between Myles and Marc about SATA/FILO, I became more confused about what my payload should be. Based on my system configuration, should I use FILO? LAB? GRUB2? What is "legacy mode" SATA?
Legacy mode SATA is where the SATA adapter responds to ATA commands. Nvidia's ck804 (on the s2892) doesn't support that.
Because of that, you need something with a SATA driver to load your kernel. You could: 1. port a driver to FILO 2. Use LAB (linux kernel with the driver in your ROM)
The first ROM image I created painted some nice pinstripes on the display after a warm reboot, and when I fully powered down and started again, I got a nice alternating tone from the PC speaker. I'm suspecting this has something to do with my payload. Either it is wrong entirely, or it needs additional configuration.
Are you going to use the onboard video controller? Did you include the VGA BIOS for it?
Serial console output seems to indicate that basic coreboot initialization was happening, but maybe never got to the point where it could give me useful VGA output.
Including the boot log once you decide which payload you want to use would help us track it down.
Thanks, Myles
Sorry also for top-posting, but I'm stuck with Outlook.
-Bijoy
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Myles Watson Sent: Friday, November 07, 2008 4:30 PM To: 'Marc Jones' Cc: 'Coreboot' Subject: Re: [coreboot] Coreboot on Tyan S2892
SATA devices should be in legacy mode and filo should be able to load
your
kernel. The only challenge is getting the drive numbering lined
up.
in buildrom do a make filo-config. You also need a grub like menu.lst
on
the drive.
I thought there was no legacy mode because it's Nvidia's CK804. If
there is
I went through a lot of pain for nothing (except learning of course :)
Ah, it would be a controller limitation not a filo one. Sorry. I didn't mean to confuse the issue.
No problem. I should have been clearer in the original response. You probably helped clarify it for everyone else.
Myles
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[...]
Legacy mode SATA is where the SATA adapter responds to ATA commands. Nvidia's ck804 (on the s2892) doesn't support that.
Because of that, you need something with a SATA driver to load your kernel. You could:
- port a driver to FILO
- Use LAB (linux kernel with the driver in your ROM)
I tried using LAB, but the LAB kernel build failed with what looked like linker errors:
kernel/built-in.o: In function `getnstimeofday': (.text+0x15491): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1553c): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1555f): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c55): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c7f): undefined reference to `__umoddi3' make[1]: *** [vmlinux] Error 1
I highly doubt that the vanilla kernel from kernel.org had build issues, so I'm guessing one or more of the patches are suspect.
In case this turns out to be a dead end, what does porting a driver to FILO involve?
The first ROM image I created painted some nice pinstripes on the display after a warm reboot, and when I fully powered down and
started
again, I got a nice alternating tone from the PC speaker. I'm suspecting this has something to do with my payload. Either it is wrong entirely, or it needs additional configuration.
Are you going to use the onboard video controller? Did you include the VGA BIOS for it?
Ultimately, we would like to have VGA capability, but until I have basic coreboot functionality working, using the serial console will be just fine. I thought the buildrom config/build process was going to take care of that, but I guess I was mistaken. If I understand correctly, leaving out the ~36k chunk will still allow me to have all the core functionality, just without VGA output..
Of course, when this is all done and working (crossing my fingers) I won't be able to resist adding that Tetris-like video game to the ROM.
Serial console output seems to indicate that basic coreboot initialization was happening, but maybe never got to the
point where
it could give me useful VGA output.
Including the boot log once you decide which payload you want to use would help us track it down.
I will definitely do that, as soon as I can get a successful build again. :) It built successfully before, since I chose FILO as my payload, but now with LAB, I haven't yet created a ROM image.
Thanks again for your patience and help.
-Bijoy
I tried using LAB, but the LAB kernel build failed with what looked like linker errors:
kernel/built-in.o: In function `getnstimeofday': (.text+0x15491): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1553c): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1555f): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c55): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c7f): undefined reference to `__umoddi3' make[1]: *** [vmlinux] Error 1
I've only ever used the 64-bit LAB. Configure buildrom to use a 64-bit kernel and send me your .config from the buildrom-devel directory if it still doesn't build.
In case this turns out to be a dead end, what does porting a driver to FILO involve?
I don't know, since I went the LAB way.
Thanks, Myles
Anose, Bijoy K (N-Aerotek) wrote:
I tried using LAB, but the LAB kernel build failed with what looked like linker errors:
kernel/built-in.o: In function `getnstimeofday': (.text+0x15491): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1553c): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1555f): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c55): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c7f): undefined reference to `__umoddi3' make[1]: *** [vmlinux] Error 1
I highly doubt that the vanilla kernel from kernel.org had build issues, so I'm guessing one or more of the patches are suspect.
I've seen problem before, but I'm afraid I don't recall exactly what the solution was in the end. I think it was something to do with the particular compiler or libgcc in the distribution.
In case this turns out to be a dead end, what does porting a driver to FILO involve?
It depends on the requirements of the driver, but hopefully it wont be neccessary. Which kind of driver are we talking about? Storage or filesystem?
//Peter
In case this turns out to be a dead end, what does porting a driver to FILO involve?
It depends on the requirements of the driver, but hopefully it wont be neccessary. Which kind of driver are we talking about? Storage or filesystem?
Storage. nvidia ck804 sata.
Thanks, Myles
On Wed, Nov 12, 2008 at 03:19:06PM -0700, Myles Watson wrote:
> In case this turns out to be a dead end, what does porting a driver > to FILO involve? It depends on the requirements of the driver, but hopefully it wont be neccessary. Which kind of driver are we talking about? Storage or filesystem?Storage. nvidia ck804 sata.
Ugly. No docs for that chipset. We've got known issues in coreboot on some boards with that chipset - we have a Tyan s2891 where disk througput on ck804 sata is about half the speed it should be under coreboot, compared to the factory bios.
Thanks, Ward.
Myles Watson wrote:
In case this turns out to be a dead end, what does porting a driver to FILO involve?
It depends on the requirements of the driver,
Storage. nvidia ck804 sata.
Ugh. Probably painful. From linux/drivers/ata/sata_nv.c:
* No hardware documentation available outside of NVIDIA. * This driver programs the NVIDIA SATA controller in a similar * fashion as with other PCI IDE BMDMA controllers, with a few * NV-specific details such as register offsets, SATA phy location, * hotplug info, etc. * * CK804/MCP04 controllers support an alternate programming interface * similar to the ADMA specification (with some modifications). * This allows the use of NCQ. Non-DMA-mapped ATA commands are still * sent through the legacy interface.
There's no DMA infrastructure in FILO or libpayload.
But the second paragraph seems to imply that PIO through legacy interface should work.
but hopefully it wont be neccessary.
Really, try to avoid it. Get larger flash chips.
//Peter
Peter Stuge wrote:
Myles Watson wrote:
In case this turns out to be a dead end, what does porting a driver to FILO involve?
It depends on the requirements of the driver,
Storage. nvidia ck804 sata.
Ugh. Probably painful. From linux/drivers/ata/sata_nv.c:
- No hardware documentation available outside of NVIDIA.
- This driver programs the NVIDIA SATA controller in a similar
- fashion as with other PCI IDE BMDMA controllers, with a few
- NV-specific details such as register offsets, SATA phy location,
- hotplug info, etc.
- CK804/MCP04 controllers support an alternate programming interface
- similar to the ADMA specification (with some modifications).
- This allows the use of NCQ. Non-DMA-mapped ATA commands are still
- sent through the legacy interface.
There's no DMA infrastructure in FILO or libpayload. But the second paragraph seems to imply that PIO through legacy interface should work.
Its easy enough to tell - if you look at the PCI device before it gets switched into NCQ mode the PCI config space should be immediately recognizable as a IDE part.
Jordan
On Wed, Nov 12, 2008 at 04:29:41PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
I tried using LAB, but the LAB kernel build failed with what looked like linker errors:
kernel/built-in.o: In function `getnstimeofday': (.text+0x15491): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1553c): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1555f): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c55): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c7f): undefined reference to `__umoddi3' make[1]: *** [vmlinux] Error 1
I highly doubt that the vanilla kernel from kernel.org had build issues, so I'm guessing one or more of the patches are suspect.
Is this with an unmodified buildrom?
I just built an s2892 rom image with LAB payload (32 bit) using the latest buildrom revision, without problems. I'm building on 32-bit Ubuntu Hardy. Toolchain issue?
In case this turns out to be a dead end, what does porting a driver to FILO involve?
LAB shouldn't be a dead end - I've got it in production on several Tyan systems (s2881, s2882).
The first ROM image I created painted some nice pinstripes on the display after a warm reboot, and when I fully powered down and
started
again, I got a nice alternating tone from the PC speaker. I'm suspecting this has something to do with my payload. Either it is wrong entirely, or it needs additional configuration.
Are you going to use the onboard video controller? Did you include the VGA BIOS for it?
Ultimately, we would like to have VGA capability, but until I have basic coreboot functionality working, using the serial console will be just fine. I thought the buildrom config/build process was going to take care of that, but I guess I was mistaken. If I understand correctly, leaving out the ~36k chunk will still allow me to have all the core functionality, just without VGA output..
Yes. Once you have the image, you just prepend your VGA rom to the image, and flash it. You can get the VGA rom from the factory bios by using the correct decode utility (see the s2881 tutorial, for example).
Thanks, Ward.
On Wed, Nov 12, 2008 at 04:29:41PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
I tried using LAB, but the LAB kernel build failed with what looked like linker errors:
kernel/built-in.o: In function `getnstimeofday': (.text+0x15491): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1553c): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1555f): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c55): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x15c7f): undefined reference to `__umoddi3' make[1]: *** [vmlinux] Error 1
I highly doubt that the vanilla kernel from kernel.org had build issues, so I'm guessing one or more of the patches are suspect.
Is this with an unmodified buildrom?
I did a 'make menuconfig' but I didn't modify any source, if that's what you mean.
I just built an s2892 rom image with LAB payload (32 bit) using the latest buildrom revision, without problems. I'm building on 32-bit Ubuntu Hardy. Toolchain issue?
Hmm.. I attempted the 32-bit LAB build with a (32-bit) Intrepid Ibex system that had just recently been upgraded from Hardy.. I do have a Hardy box to build on as well, and I'll try that when I get home.
In case this turns out to be a dead end, what does porting
a driver to
FILO involve?
LAB shouldn't be a dead end - I've got it in production on several Tyan systems (s2881, s2882).
Ok. This is encouraging.
[... ] If I understand correctly, leaving out the ~36k chunk will still allow me
to have all
the core functionality, just without VGA output..
Yes. Once you have the image, you just prepend your VGA rom to the image, and flash it. You can get the VGA rom from the factory bios by using the correct decode utility (see the s2881 tutorial, for example).
I did happen to see the link to the "amideco" utility on the S2881 tutorial, but the S2892 has a Phoenix BIOS. If there is a Phoenix version of that utility, could someone make it available on the coreboot site? The Russian domain is blocked by our Net Nanny..
-Bijoy
On Wed, Nov 12, 2008 at 07:08:42PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
I just built an s2892 rom image with LAB payload (32 bit) using the latest buildrom revision, without problems. I'm building on 32-bit Ubuntu Hardy. Toolchain issue?
Hmm.. I attempted the 32-bit LAB build with a (32-bit) Intrepid Ibex system that had just recently been upgraded from Hardy.. I do have a Hardy box to build on as well, and I'll try that when I get home.
OK. I'll see if I can find out what goes wrong on Intrepid.
In case this turns out to be a dead end, what does porting
a driver to
FILO involve?
LAB shouldn't be a dead end - I've got it in production on several Tyan systems (s2881, s2882).
Ok. This is encouraging.
And I've got it working on an s2891, but there I see the ck804 sata performance problem that I mentioned, so that box still runs under the proprietary bios :/
[... ] If I understand correctly, leaving out the ~36k chunk will still allow me
to have all
the core functionality, just without VGA output..
Yes. Once you have the image, you just prepend your VGA rom to the image, and flash it. You can get the VGA rom from the factory bios by using the correct decode utility (see the s2881 tutorial, for example).
I did happen to see the link to the "amideco" utility on the S2881 tutorial, but the S2892 has a Phoenix BIOS. If there is a Phoenix version of that utility, could someone make it available on the coreboot site? The Russian domain is blocked by our Net Nanny..
I'm not sure that site is still what it used to be - the registration lapsed a while ago iirc. In any case, there is a phoenix utility as well, and they are all in debian and ubuntu universe (thanks to Uwe!). So you should be able to just
apt-get install phnxdeco
it.
Thanks, Ward.
I just built an s2892 rom image with LAB payload (32 bit)
using the
latest buildrom revision, without problems. I'm building
on 32-bit
Ubuntu Hardy. Toolchain issue?
Hmm.. I attempted the 32-bit LAB build with a (32-bit)
Intrepid Ibex
system that had just recently been upgraded from Hardy.. I
do have a
Hardy box to build on as well, and I'll try that when I get home.
OK. I'll see if I can find out what goes wrong on Intrepid.
Sure enough, I was able to successfully build a 32-bit LAB on my Hardy box.
In case this turns out to be a dead end, what does porting
a driver to
FILO involve?
LAB shouldn't be a dead end - I've got it in production
on several
Tyan systems (s2881, s2882).
Ok. This is encouraging.
And I've got it working on an s2891, but there I see the ck804 sata performance problem that I mentioned, so that box still runs under the proprietary bios :/
I hope we don't have SATA performance issues with the S2892.. that would probably prevent us from using coreboot.
[... ] If I understand correctly, leaving out the ~36k chunk will still allow me
to have all
the core functionality, just without VGA output..
Yes. Once you have the image, you just prepend your VGA
rom to the
image, and flash it. You can get the VGA rom from the
factory bios
by using the correct decode utility (see the s2881 tutorial, for example).
I did happen to see the link to the "amideco" utility on the S2881 tutorial, but the S2892 has a Phoenix BIOS. If there is a Phoenix version of that utility, could someone make it available on the coreboot site? The Russian domain is blocked by our Net Nanny..
I'm not sure that site is still what it used to be - the registration lapsed a while ago iirc. In any case, there is a phoenix utility as well, and they are all in debian and ubuntu universe (thanks to Uwe!). So you should be able to just
apt-get install phnxdeco
it.
Got it -- thanks! I never would have suspected such a tool would be available via the ubuntu repositories. Thank you Uwe indeed!
-Bijoy
On Thu, Nov 13, 2008 at 01:24:07PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
Sure enough, I was able to successfully build a 32-bit LAB on my Hardy box.
OK.
I hope we don't have SATA performance issues with the S2892.. that would
probably prevent us from using coreboot.
So far it's just me seeing that, on one specific board (s2891). So don't worry about that too much just yet.
Thanks, Ward.
From: Ward Vandewege [mailto:ward@gnu.org] Sent: Thursday, November 13, 2008 3:01 PM To: Anose, Bijoy K (N-Aerotek) Cc: Myles Watson; Marc Jones; Coreboot Subject: Re: [coreboot] Coreboot on Tyan S2892
On Thu, Nov 13, 2008 at 01:24:07PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
Sure enough, I was able to successfully build a 32-bit LAB
on my Hardy
box.
OK.
Unfortunately, I didn't get a successful boot. I didn't try appending the VGA chunk yet. Maybe I'll need to, in order to have any hope of debugging though, since I'm not getting any serial console output at all.
I hope we don't have SATA performance issues with the S2892.. that would
probably prevent us from using coreboot.
So far it's just me seeing that, on one specific board (s2891). So don't worry about that too much just yet.
True, I'll cross that bridge when I get there.
First I'll need to be able to boot, period. So far, what I've done is this:
1. Subversion checkout of latest buildrom 2. make menuconfig, specifying Tyan S2892, 32-bit LAB 3. make
Do I need to do further configuration (Config.lb etc)? I thought that the menuconfig took care of everything. Maybe that was wishful thinking..
-Bijoy
On Thu, Nov 13, 2008 at 07:04:49PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
So far it's just me seeing that, on one specific board (s2891). So don't worry about that too much just yet.
True, I'll cross that bridge when I get there.
First I'll need to be able to boot, period. So far, what I've done is this:
- Subversion checkout of latest buildrom
- make menuconfig, specifying Tyan S2892, 32-bit LAB
- make
Do I need to do further configuration (Config.lb etc)? I thought that the menuconfig took care of everything. Maybe that was wishful thinking..
It's not. The only other thing you need to do is *pre*pend the vga image to the generated image, which will generate an image that is exactly 1024KB large, and which you can flash, and which *should* just boot your system.
Thanks, Ward.
Ward Vandewege wrote:
I thought that the menuconfig took care of everything. Maybe that was wishful thinking..
It's not. The only other thing you need to do is *pre*pend the vga image to the generated image,
We need to make buildrom do this as well.
//Peter
On Fri, Nov 14, 2008 at 02:49:01AM +0100, Peter Stuge wrote:
Ward Vandewege wrote:
I thought that the menuconfig took care of everything. Maybe that was wishful thinking..
It's not. The only other thing you need to do is *pre*pend the vga image to the generated image,
We need to make buildrom do this as well.
We can't distribute the vga rom...
Thanks, Ward.
Peter Stuge wrote:
Ward Vandewege wrote:
I thought that the menuconfig took care of everything. Maybe that was wishful thinking..
It's not. The only other thing you need to do is *pre*pend the vga image to the generated image,
We need to make buildrom do this as well.
The infrastructure is already in place for the dbm690t, so we can extend it. The way it works is that if the .rom file doesn't exist, a friendly message tells you how to aquire it. In the case of the dbm690t, it would be a download from the web, in the case of the Tyan, it would give a link to the wiki site explaining how to extract the ROM. The .rom gets copied to a known file and boom - you are in business.
Jordan
Jordan Crouse wrote:
In the case of the dbm690t, it would be a download from the web, in the case of the Tyan, it would give a link to the wiki site explaining how to extract the ROM. The .rom gets copied to a known file and boom - you are in business.
Yes, like that.
//Peter
From: Ward Vandewege [mailto:ward@gnu.org] Sent: Thursday, November 13, 2008 6:56 PM To: Anose, Bijoy K (N-Aerotek) Cc: Myles Watson; Marc Jones; Coreboot Subject: Re: [coreboot] Coreboot on Tyan S2892
On Thu, Nov 13, 2008 at 07:04:49PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
So far it's just me seeing that, on one specific board
(s2891). So
don't worry about that too much just yet.
True, I'll cross that bridge when I get there.
First I'll need to be able to boot, period. So far, what
I've done is
this:
- Subversion checkout of latest buildrom 2. make menuconfig,
specifying Tyan S2892, 32-bit LAB 3. make
Do I need to do further configuration (Config.lb etc)? I
thought that
the menuconfig took care of everything. Maybe that was wishful thinking..
It's not. The only other thing you need to do is *pre*pend the vga image to the generated image, which will generate an image that is exactly 1024KB large, and which you can flash, and which *should* just boot your system.
I finally got coreboot+LAB to boot my target kernel/initrd on the SATA disks (many thanks to Ward)!
However, once the init script in the initrd attempts to assembly the software RAID, it fails because it can't see the SATA disks. The same disk boots fine when I boot with the legacy BIOS installed.
My guess is that coreboot is originally doing some low level block reads from the disk to load the kernel/initrd but when the final kernel attempts to do a SATA read from the disk, the controller has not been fully/properly initialized, and it fails.
I assume that whatever modifications that Myles made to successfully boot from SATA devices with coreboot+LAB on S2892 have trickled down to buildrom..
Are there other tweaks I need to make, Myles?
-Bijoy
On Wed, Nov 19, 2008 at 9:40 AM, Anose, Bijoy K (N-Aerotek) < bijoy.k.anose@lmco.com> wrote:
From: Ward Vandewege [mailto:ward@gnu.org] Sent: Thursday, November 13, 2008 6:56 PM To: Anose, Bijoy K (N-Aerotek) Cc: Myles Watson; Marc Jones; Coreboot Subject: Re: [coreboot] Coreboot on Tyan S2892
On Thu, Nov 13, 2008 at 07:04:49PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
So far it's just me seeing that, on one specific board
(s2891). So
don't worry about that too much just yet.
True, I'll cross that bridge when I get there.
First I'll need to be able to boot, period. So far, what
I've done is
this:
- Subversion checkout of latest buildrom 2. make menuconfig,
specifying Tyan S2892, 32-bit LAB 3. make
Do I need to do further configuration (Config.lb etc)? I
thought that
the menuconfig took care of everything. Maybe that was wishful thinking..
It's not. The only other thing you need to do is *pre*pend the vga image to the generated image, which will generate an image that is exactly 1024KB large, and which you can flash, and which *should* just boot your system.
I finally got coreboot+LAB to boot my target kernel/initrd on the SATA disks (many thanks to Ward)!
However, once the init script in the initrd attempts to assembly the software RAID, it fails because it can't see the SATA disks.
How many do you have? Ward has seen a problem with some disk controllers not functioning on the ck804. I've never used more than one.
My guess is that coreboot is originally doing some low level block reads from the disk to load the kernel/initrd but when the final kernel attempts to do a SATA read from the disk, the controller has not been fully/properly initialized, and it fails.
Have you tried configure the busybox shell to not load automatically, and looked at the SATA drives from there?
I assume that whatever modifications that Myles made to successfully
boot from SATA devices with coreboot+LAB on S2892 have trickled down to buildrom..
I used buildrom. I think the multiple drives may be getting you, though.
Thanks, Myles
I enabled the busybox option and used the default value of "5 second pause to allow access to busybox" but it doesn't pause anywhere, as far as I can tell. Coreboot starts, LAB starts, LAB kexecs the kernel/initrd on the SATA disk, and then at that busybox prompt, I get no output when I issue "fdisk -l /dev/sda".
Could you send me a tarball of your buildrom-devel? Something must be different in our config. Also your lab.conf and the kernel/initrd that is on your SATA disk, if that would ok. I built my own static kexec and xfer'd it to the SATA drive.
Multiple drives shouldn't make any difference -- if the controller can see one drive, it can see them all (if it is actually working properly). My system may have 2 drives or 8, depending on its function. The one I'm currently experimenting with has only 2 installed.
-Bijoy
(sorry again for top-posting, Outlook is acting differently over VPN/rdesktop for some reason)
________________________________
From: Myles Watson [mailto:mylesgw@gmail.com] Sent: Wednesday, November 19, 2008 11:19 AM To: Anose, Bijoy K (N-Aerotek) Cc: Ward Vandewege; Coreboot Subject: Re: [coreboot] Coreboot on Tyan S2892
On Wed, Nov 19, 2008 at 9:40 AM, Anose, Bijoy K (N-Aerotek) bijoy.k.anose@lmco.com wrote:
> From: Ward Vandewege [mailto:ward@gnu.org] > Sent: Thursday, November 13, 2008 6:56 PM > To: Anose, Bijoy K (N-Aerotek) > Cc: Myles Watson; Marc Jones; Coreboot > Subject: Re: [coreboot] Coreboot on Tyan S2892 > > On Thu, Nov 13, 2008 at 07:04:49PM -0500, Anose, Bijoy K > (N-Aerotek) wrote: > > > So far it's just me seeing that, on one specific board > (s2891). So > > > don't worry about that too much just yet. > > > > True, I'll cross that bridge when I get there. > > > > First I'll need to be able to boot, period. So far, what > I've done is > > this: > > > > 1. Subversion checkout of latest buildrom 2. make menuconfig, > > specifying Tyan S2892, 32-bit LAB 3. make > > > > Do I need to do further configuration (Config.lb etc)? I > thought that > > the menuconfig took care of everything. Maybe that was wishful > > thinking.. > > It's not. The only other thing you need to do is *pre*pend > the vga image to the generated image, which will generate an > image that is exactly 1024KB large, and which you can flash, > and which *should* just boot your system. > I finally got coreboot+LAB to boot my target kernel/initrd on the SATA disks (many thanks to Ward)! However, once the init script in the initrd attempts to assembly the software RAID, it fails because it can't see the SATA disks.
How many do you have? Ward has seen a problem with some disk controllers not functioning on the ck804. I've never used more than one.
My guess is that coreboot is originally doing some low level block reads from the disk to load the kernel/initrd but when the final kernel attempts to do a SATA read from the disk, the controller has not been fully/properly initialized, and it fails.
Have you tried configure the busybox shell to not load automatically, and looked at the SATA drives from there?
I assume that whatever modifications that Myles made to successfully boot from SATA devices with coreboot+LAB on S2892 have trickled down to buildrom..
I used buildrom. I think the multiple drives may be getting you, though. Thanks, Myles
On Wed, Nov 19, 2008 at 2:12 PM, Anose, Bijoy K (N-Aerotek) < bijoy.k.anose@lmco.com> wrote:
I enabled the busybox option and used the default value of "5 second pause to allow access to busybox" but it doesn't pause anywhere, as far as I can tell. Coreboot starts, LAB starts, LAB kexecs the kernel/initrd on the SATA disk, and then at that busybox prompt, I get no output when I issue "fdisk -l /dev/sda".
So your kernel/initrd is busybox-based as well? Is the new kernel really getting run?
I'd start with ls -l /dev/sda or something simple like that.
Could you send me a tarball of your buildrom-devel?
Since it's old I don't think that would be really helpful. Are you changing the .config files? Are you changing the skeleton/ files?
Something must be different in our config. Also your lab.conf and the kernel/initrd that is on your SATA disk, if that would ok.
I don't have that machine up right now, so it would take a while. I think there's a shorter path to the answer than that.
I built my own static kexec and xfer'd it to the SATA drive.
Great.
Multiple drives shouldn't make any difference -- if the controller can see one drive, it can see them all (if it is actually working properly).
You're right. If they don't all work it's a bug. Maybe it's been fixed. If you're only using two drives, though, it's probably not that.
My system may have 2 drives or 8, depending on its function. The one I'm currently experimenting
with has only 2 installed.
-Bijoy
(sorry again for top-posting, Outlook is acting differently over VPN/rdesktop for some reason)
*From:* Myles Watson [mailto:mylesgw@gmail.com] *Sent:* Wednesday, November 19, 2008 11:19 AM *To:* Anose, Bijoy K (N-Aerotek) *Cc:* Ward Vandewege; Coreboot
*Subject:* Re: [coreboot] Coreboot on Tyan S2892
On Wed, Nov 19, 2008 at 9:40 AM, Anose, Bijoy K (N-Aerotek) < bijoy.k.anose@lmco.com> wrote:
From: Ward Vandewege [mailto:ward@gnu.org] Sent: Thursday, November 13, 2008 6:56 PM To: Anose, Bijoy K (N-Aerotek) Cc: Myles Watson; Marc Jones; Coreboot Subject: Re: [coreboot] Coreboot on Tyan S2892
On Thu, Nov 13, 2008 at 07:04:49PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
So far it's just me seeing that, on one specific board
(s2891). So
don't worry about that too much just yet.
True, I'll cross that bridge when I get there.
First I'll need to be able to boot, period. So far, what
I've done is
this:
- Subversion checkout of latest buildrom 2. make menuconfig,
specifying Tyan S2892, 32-bit LAB 3. make
Do I need to do further configuration (Config.lb etc)? I
thought that
the menuconfig took care of everything. Maybe that was wishful thinking..
It's not. The only other thing you need to do is *pre*pend the vga image to the generated image, which will generate an image that is exactly 1024KB large, and which you can flash, and which *should* just boot your system.
I finally got coreboot+LAB to boot my target kernel/initrd on the SATA disks (many thanks to Ward)!
However, once the init script in the initrd attempts to assembly the software RAID, it fails because it can't see the SATA disks.
How many do you have? Ward has seen a problem with some disk controllers not functioning on the ck804. I've never used more than one.
My guess is that coreboot is originally doing some low level block reads from the disk to load the kernel/initrd but when the final kernel attempts to do a SATA read from the disk, the controller has not been fully/properly initialized, and it fails.
Have you tried configure the busybox shell to not load automatically, and looked at the SATA drives from there?
I assume that whatever modifications that Myles made to successfully
boot from SATA devices with coreboot+LAB on S2892 have trickled down to buildrom..
I used buildrom. I think the multiple drives may be getting you, though.
Thanks, Myles
Yes, it is busybox-based, and yes, the final kernel is definitely getting run, as evidenced by 'uname -a' output at the busybox prompt. The file '/dev/sda' does exist.. I don't remember the major/minor numbers, etc.
My .config file is attached. I am not modifying the skeleton/* files.
-Bijoy
________________________________
From: Myles Watson [mailto:mylesgw@gmail.com] Sent: Wednesday, November 19, 2008 3:24 PM To: Anose, Bijoy K (N-Aerotek) Cc: Ward Vandewege; Coreboot Subject: Re: [coreboot] Coreboot on Tyan S2892
On Wed, Nov 19, 2008 at 2:12 PM, Anose, Bijoy K (N-Aerotek) < bijoy.k.anose@lmco.com> wrote:
I enabled the busybox option and used the default value of "5 second pause to allow access to busybox" but it doesn't pause anywhere, as far as I can tell. Coreboot starts, LAB starts, LAB kexecs the kernel/initrd on the SATA disk, and then at that busybox prompt, I get no output when I issue "fdisk -l /dev/sda".
So your kernel/initrd is busybox-based as well? Is the new kernel really getting run? I'd start with ls -l /dev/sda or something simple like that.
Could you send me a tarball of your buildrom-devel?
Since it's old I don't think that would be really helpful. Are you changing the .config files? Are you changing the skeleton/ files?
Something must be different in our config. Also your lab.conf and the kernel/initrd that is on your SATA disk, if that would ok.
I don't have that machine up right now, so it would take a while. I think there's a shorter path to the answer than that.
I built my own static kexec and xfer'd it to the SATA drive.
Great.
Multiple drives shouldn't make any difference -- if the controller can see one drive, it can see them all (if it is actually working properly).
You're right. If they don't all work it's a bug. Maybe it's been fixed. If you're only using two drives, though, it's probably not that.
My system may have 2 drives or 8, depending on its function. The one I'm currently experimenting
with has only 2 installed.
-Bijoy (sorry again for top-posting, Outlook is acting differently over VPN/rdesktop for some reason)
________________________________
From: Myles Watson [mailto:mylesgw@gmail.com] Sent: Wednesday, November 19, 2008 11:19 AM
To: Anose, Bijoy K (N-Aerotek) Cc: Ward Vandewege; Coreboot
Subject: Re: [coreboot] Coreboot on Tyan S2892
On Wed, Nov 19, 2008 at 9:40 AM, Anose, Bijoy K (N-Aerotek) bijoy.k.anose@lmco.com wrote:
> From: Ward Vandewege [mailto: ward@gnu.org] > Sent: Thursday, November 13, 2008 6:56 PM > To: Anose, Bijoy K (N-Aerotek) > Cc: Myles Watson; Marc Jones; Coreboot > Subject: Re: [coreboot] Coreboot on Tyan S2892 > > On Thu, Nov 13, 2008 at 07:04:49PM -0500, Anose, Bijoy K > (N-Aerotek) wrote: > > > So far it's just me seeing that, on one specific board > (s2891). So > > > don't worry about that too much just yet. > > > > True, I'll cross that bridge when I get there. > > > > First I'll need to be able to boot, period. So far, what > I've done is > > this: > > > > 1. Subversion checkout of latest buildrom 2. make menuconfig, > > specifying Tyan S2892, 32-bit LAB 3. make > > > > Do I need to do further configuration (Config.lb etc)? I > thought that > > the menuconfig took care of everything. Maybe that was wishful > > thinking.. > > It's not. The only other thing you need to do is *pre*pend > the vga image to the generated image, which will generate an > image that is exactly 1024KB large, and which you can flash, > and which *should* just boot your system. > I finally got coreboot+LAB to boot my target kernel/initrd on the SATA disks (many thanks to Ward)! However, once the init script in the initrd attempts to assembly the software RAID, it fails because it can't see the SATA disks.
How many do you have? Ward has seen a problem with some disk controllers not functioning on the ck804. I've never used more than one.
My guess is that coreboot is originally doing some low level block reads from the disk to load the kernel/initrd but when the final kernel attempts to do a SATA read from the disk, the controller has not been fully/properly initialized, and it fails.
Have you tried configure the busybox shell to not load automatically, and looked at the SATA drives from there?
I assume that whatever modifications that Myles made to successfully boot from SATA devices with coreboot+LAB on S2892 have trickled down to buildrom..
I used buildrom. I think the multiple drives may be getting you, though. Thanks, Myles
On Thu, Nov 20, 2008 at 10:24 AM, Anose, Bijoy K (N-Aerotek) < bijoy.k.anose@lmco.com> wrote:
Yes, it is busybox-based, and yes, the final kernel is definitely getting run, as evidenced by 'uname -a' output at the busybox prompt. The file '/dev/sda' does exist.. I don't remember the major/minor numbers, etc.
My .config file is attached. I am not modifying the skeleton/* files.
-Bijoy
All right. The only differences I see are that you are building on a 32-bit machine and you're building a 32-bit LAB image. CONFIG_TARGET_64BIT CONFIG_CHOOSE_64BIT
Since your kernel gets loaded, I don't see why either of those should matter. It seems like there's a difference between the way your LAB kernel and your regular kernel are handling the SATA drive. Since the LAB kernel finds and reads it, but yours doesn't...
I hope that helps.
Thanks, Myles
*From:* Myles Watson [mailto:mylesgw@gmail.com] *Sent:* Wednesday, November 19, 2008 3:24 PM *To:* Anose, Bijoy K (N-Aerotek) *Cc:* Ward Vandewege; Coreboot *Subject:* Re: [coreboot] Coreboot on Tyan S2892
On Wed, Nov 19, 2008 at 2:12 PM, Anose, Bijoy K (N-Aerotek) < bijoy.k.anose@lmco.com> wrote:
I enabled the busybox option and used the default value of "5 second pause to allow access to busybox" but it doesn't pause anywhere, as far as I can tell. Coreboot starts, LAB starts, LAB kexecs the kernel/initrd on the SATA disk, and then at that busybox prompt, I get no output when I issue "fdisk -l /dev/sda".
So your kernel/initrd is busybox-based as well? Is the new kernel really getting run?
I'd start with ls -l /dev/sda or something simple like that.
Could you send me a tarball of your buildrom-devel?
Since it's old I don't think that would be really helpful. Are you changing the .config files? Are you changing the skeleton/ files?
Something must be different in our config. Also your lab.conf and the kernel/initrd that is on your SATA disk, if that would ok.
I don't have that machine up right now, so it would take a while. I think there's a shorter path to the answer than that.
I built my own static kexec and xfer'd it to the SATA drive.
Great.
Multiple drives shouldn't make any difference -- if the controller can see one drive, it can see them all (if it is actually working properly).
You're right. If they don't all work it's a bug. Maybe it's been fixed. If you're only using two drives, though, it's probably not that.
My system may have 2 drives or 8, depending on its function. The one I'm currently experimenting
with has only 2 installed.
-Bijoy
(sorry again for top-posting, Outlook is acting differently over VPN/rdesktop for some reason)
*From:* Myles Watson [mailto:mylesgw@gmail.com] *Sent:* Wednesday, November 19, 2008 11:19 AM *To:* Anose, Bijoy K (N-Aerotek) *Cc:* Ward Vandewege; Coreboot
*Subject:* Re: [coreboot] Coreboot on Tyan S2892
On Wed, Nov 19, 2008 at 9:40 AM, Anose, Bijoy K (N-Aerotek) < bijoy.k.anose@lmco.com> wrote:
From: Ward Vandewege [mailto:ward@gnu.org] Sent: Thursday, November 13, 2008 6:56 PM To: Anose, Bijoy K (N-Aerotek) Cc: Myles Watson; Marc Jones; Coreboot Subject: Re: [coreboot] Coreboot on Tyan S2892
On Thu, Nov 13, 2008 at 07:04:49PM -0500, Anose, Bijoy K (N-Aerotek) wrote:
So far it's just me seeing that, on one specific board
(s2891). So
don't worry about that too much just yet.
True, I'll cross that bridge when I get there.
First I'll need to be able to boot, period. So far, what
I've done is
this:
- Subversion checkout of latest buildrom 2. make menuconfig,
specifying Tyan S2892, 32-bit LAB 3. make
Do I need to do further configuration (Config.lb etc)? I
thought that
the menuconfig took care of everything. Maybe that was wishful thinking..
It's not. The only other thing you need to do is *pre*pend the vga image to the generated image, which will generate an image that is exactly 1024KB large, and which you can flash, and which *should* just boot your system.
I finally got coreboot+LAB to boot my target kernel/initrd on the SATA disks (many thanks to Ward)!
However, once the init script in the initrd attempts to assembly the software RAID, it fails because it can't see the SATA disks.
How many do you have? Ward has seen a problem with some disk controllers not functioning on the ck804. I've never used more than one.
My guess is that coreboot is originally doing some low level block reads from the disk to load the kernel/initrd but when the final kernel attempts to do a SATA read from the disk, the controller has not been fully/properly initialized, and it fails.
Have you tried configure the busybox shell to not load automatically, and looked at the SATA drives from there?
I assume that whatever modifications that Myles made to successfully
boot from SATA devices with coreboot+LAB on S2892 have trickled down to buildrom..
I used buildrom. I think the multiple drives may be getting you, though.
Thanks, Myles
-
Anose, Bijoy K (N-Aerotek) -
Jordan Crouse -
Myles Watson -
Peter Stuge -
Ward Vandewege