coreboot

coreboot@coreboot.org

12 participants
39716 discussions

[LinuxBIOS] RE: boot from SATA
by YhLu 24 May '05

24 May '05

Please use 5.2.6 and gcc 3.2.2, so you need to use RH9. for that. You may try 5.4 too (use CVS to get latest one), it can be compiled in late compiler. The problem it doesn't support memtest till now.... YH _____ From: Stephen.Kimball(a)bench.com [mailto:Stephen.Kimball@bench.com] Sent: Tuesday, May 24, 2005 9:31 AM To: YhLu Subject: boot from SATA YH, I want to boot from a SATA drive with etherboot. I made the Config file change from http://www.linuxbios.org/index.php/Etherboot <http://www.linuxbios.org/index.php/Etherboot> . But I get these errors: ld -r bin/tg3.o bin/filo.rt.o -o bin/tg3--filo.rt.o objcopy -R .text16 bin/elfprefix.o bin/elfprefix.entry.o objcopy -R .prefix bin/elfprefix.o bin/elfprefix.exit.o ld -N -T arch/i386/core/etherboot.lds -o bin/tg3--filo.elf.rt bin/elfprefix.exit.o bin/tg3--filo.rt.o bin/tg3--filo.rt.o(.text+0x4507): In function `install_pxe_stack': : undefined reference to `allot_base_memory' bin/tg3--filo.rt.o(.text+0x457e): In function `install_pxe_stack': : undefined reference to `e820mangler_size' bin/tg3--filo.rt.o(.text+0x4763): In function `install_pxe_stack': : undefined reference to `install_rm_callback_interface' bin/tg3--filo.rt.o(.text+0x4769): In function `install_pxe_stack': : undefined reference to `install_e820mangler' bin/tg3--filo.rt.o(.text+0x4787): In function `use_undi_ds_for_rm_stack': : undefined reference to `forget_real_mode_stack' bin/tg3--filo.rt.o(.text+0x47b7): In function `hook_pxe_stack': : undefined reference to `hide_etherboot' bin/tg3--filo.rt.o(.text+0x4852): In function `unhook_pxe_stack': : undefined reference to `unhide_etherboot' bin/tg3--filo.rt.o(.text+0x4889): In function `remove_pxe_stack': : undefined reference to `forget_base_memory' bin/tg3--filo.rt.o(.text+0x4a51): In function `filo_pci_probe': : undefined reference to `filo' bin/tg3--filo.rt.o(.text+0x98b9): In function `pxenv_restart_tftp': : undefined reference to `get_free_base_memory' make: *** [bin/tg3--filo.elf.rt] Error 1 rm bin/elfprefix.exit.o bin/tg3--filo.rt.o bin/filo.rt.o bin/elfprefix.entry.o bin/filo.o What am I missing? Thanks. Steve

1 0

RE: [LinuxBIOS] About Nvidia chipset support
by YhLu 23 May '05

23 May '05

Onboard SATA works now. YH > -----Original Message----- > From: YhLu > Sent: Friday, May 13, 2005 1:54 PM > To: 'Ronald G. Minnich'; 'ebiederman(a)lnxi.com'; 'Stefan > Reinauer'; 'Li-Ta Lo' > Cc: 'linuxbios(a)openbios.org' > Subject: RE: [LinuxBIOS] About Nvidia chipset support > > Just commit some lines to ondie Lan work now. > > YH > > > -----Original Message----- > > From: YhLu > > Sent: Wednesday, May 11, 2005 1:36 PM > > To: YhLu; Ronald G. Minnich; ebiederman(a)lnxi.com; Stefan Reinauer; > > Li-Ta Lo > > Cc: linuxbios(a)openbios.org > > Subject: RE: [LinuxBIOS] About Nvidia chipset support > > > > commited. > > > > > -----Original Message----- > > > From: YhLu > > > Sent: Wednesday, May 11, 2005 11:21 AM > > > To: Ronald G. Minnich; ebiederman(a)lnxi.com; Stefan > > Reinauer; Li-Ta Lo > > > Cc: linuxbios(a)openbios.org > > > Subject: [LinuxBIOS] About Nvidia chipset support > > > > > > All, > > > > > > Finally I get the approval for releasing Nvidia chipset > support for > > > Ck804. I hope end user to press nvidia to release more > info to make > > > sata and on die lan work. > > > > > > The problem my code is messed up dual core support etc. I > need some > > > time to split them up. > > > > > > I will commit soon about > > > Nvidia CK804 support > > > smbus bus number support (to handle multi sumbus and mux) > > superio smsc > > > 47 support Tyan S2895/S2891/S2892 support flash_rom Ck804 support > > > > > > maybe two months later after AMD issue auth letter or put > > dual core on > > > public > > > > > > AMD D0/E0 Opteron new mem mapping support AMD E Opteron dual core > > > support AMD E Opteron mem hole support AMD K8 Four Ranks > > DIMM support > > > > > > Regards > > > > > > YH > > > > > > _______________________________________________ > > > LinuxBIOS mailing list > > > LinuxBIOS(a)openbios.org > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS(a)openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios >

1 0

[LinuxBIOS] VIA VT8231 documentation
by Josiah England 23 May '05

23 May '05

Does anyone have good links to recent documentation? Latest I have is from 2/1/2001.

2 1

[LinuxBIOS] Adding Support for ATA Freeze Command.
by Ralph Corderoy 23 May '05

23 May '05

Hi, Are people generally aware of the ATA security commands? They allow a password to be set on a hard drive. It's the hard drive that's doing the password storing, not the motherboard, so the drive's still locked if it's moved to another machine. On boot-up the BIOS recognises the drive's locked and prompts the user for the password. It's also the normal UI for setting it in the first place. Anyway, my point is passwords are typically not set. This means something malicous can set it and the next time the machine boots the user's locked out of his own drive. The c't magazine had an article on it recently. http://www.heise.de/ct/english/05/08/172/ Once a drive's locked with an unknown user password then it's a dead drive unless the manufacturer can be persuade to give you the higher level password that allows a security format of the device to be done. This normally requires a paper-chase to prove you're the rightful owner. Options are for users to set the password on their drives so it can't be set malicously to something unknown to them but that's a pain because it needs supplying on boot-up. Or, for the ATA Freeze command to be used soon after boot-up. This puts the drive in a state where it won't accept any password setting until after the next boot. (The ATA-3 spec. is http://www.t13.org/project/d2008r7b-ATA-3.pdf -- see pages 33 and 75 by the number written on the page.) Ideally, the Freeze needs to be done as soon as possible in the BIOS -> bootloader -> OS chain to make it harder to set the password before the freeze is done. That's why I'm here. :-) It LinuxBIOS were to add support for Freeze drives it would be another advantage over other BIOSes. Am I right in thinking that LinuxBIOS itself knows nothing about ATA and that's left to FILO? Is that the only payload that deals with ATA? (I'm also going to lobby the Grub people for those of us that don't have BIOS support for ATA Freeze.) Cheers, Ralph.

2 5

[LinuxBIOS] http://wiki.linuxbios.org/ not found.
by Ken Fuchs 21 May '05

21 May '05

When I try to access http://wiki.linuxbios.org/ I get wiki.linuxbios.org is not found. http://www.linuxbios.org/ works fine. It would be nice if any access within the linuxbios.org domain responds with something more useful than <host>.linuxbios.org is not found. Sincerely, Ken Fuchs <kfuchs(a)winternet.com>

1 0

[LinuxBIOS] I"ve updated the dns for www.linuxbios.org
by Ronald G. Minnich 20 May '05

20 May '05

let's see if it works in 24 hours. ron

6 21

[LinuxBIOS] Bug in pnp_set_drq()?
by Steven J. Magnani 20 May '05

20 May '05

I ran across the following code in src/devices/pnp_device.c: void pnp_set_drq(device_t dev, unsigned drq, unsigned index) { /* Index == 0x74 */ pnp_write_config(dev, index, drq & 0xff); } static void pnp_set_resource(device_t dev, struct resource *resource) { ... /* Now store the resource */ if (resource->flags & IORESOURCE_IO) { pnp_set_iobase(dev, resource->index, resource->base); } else if (resource->flags & IORESOURCE_DRQ) { pnp_set_drq(dev, resource->index, resource->base); } ... } The declaration of pnp_set_drq() looks backwards to me. Shouldn't it be void pnp_set_drq(device_t dev, unsigned index, unsigned drq) to match the way it's being called? Steve Magnani Digital Design Corporation www.digidescorp.com

2 1

Re: Fwd: [LinuxBIOS] still no luck on smartcore-p5
by Kjell Svensson 20 May '05

20 May '05

Hi again, I just tried the romimage - It didn't work! Well, the LinuxBIOS booted and everything looked OK up until the same point as I have seen before from my builds; elfboot is started, but the payload seems completely dead... :-( Since I saw the payload in the romimage was etherboot, I also hooked up the ethernet and started sniffing it with ethereal, but no packets were ever sent on the ethernet. I have also checked that nothing comes out on the VGA console. My conclusion is that the Etherboot payload either never is reached, or crashes at an early stage. Well, I guess this anyway gives me lots of hints by ruling out all the doubts I had about my config and build process; now I guess there must be something different between our Smartcore-P5 based hardwares... Could I please ask you to check what cardtype/revision you're using? My HW config looks as follows: DigitalLogic MSM-P5SEN, V3.9, Rev A. It's also marked 03.04 which I guess is the manufacturing date(?) This card has a SmartCore-P5 module clocked at 166MHz. There is only one Revision label on this module, but it has no revision mark on it... The MSM-P5SEN variant comes without VGA cirquitry, but I have also tried LinuxBIOS on the VGA-equipped variant we have around here with the same result. The onboard Flash is a Winbond 29C020CP (i.e 256kB), but LinuxBIOS boots equally well also from 128kB and 512kB flashes I've tried in the socket. The card has one SDRAM slot, which we have equipped with a 128MB large module. Looking for simple answers; could you possibly be using a different size (larger) RAM, and could the elfboot for this platform have some code fragments not checking the detected RAM size so that it relocates the payload out inito the void? -- Cheers. /Kjell Quoting Kjell Svensson <lists(a)endian.se>: > > > > Begin forwarded message: > > > From: "Ronald G. Minnich" <rminnich(a)lanl.gov> > > Date: 19 maj 2005 16:45:16 MET > > To: Kjell Svensson <lists(a)endian.se> > > Subject: Re: [LinuxBIOS] still no luck on smartcore-p5 > > > > > > > > no guarantees, but this might be it. > > > > it's a 512KB image. What size rom do you have? > > > > ron

3 3

[LinuxBIOS] RE: Intel 82801 southbridge NMI configuration
by Steven J. Magnani 20 May '05

20 May '05

A correction to the corrected code, for the record...the outb() parameters were reversed... #include <arch/io.h> static void lpc_init(struct device *dev) { ... /* Set up NMI on errors */ byte = inb(0x61); byte &= ~(1 << 3); /* IOCHK# NMI Enable */ byte &= ~(1 << 2); /* PCI SERR# Enable */ outb(byte, 0x61); byte = inb(0x70); nmi_option = NMI_OFF; get_option(&nmi_option, "nmi"); if (nmi_option) { byte &= ~(1 << 7); /* set NMI */ outb(byte, 0x70); } ... } --Steve

1 0

[LinuxBIOS] Intel 82801 southbridge NMI configuration
by Steven J. Magnani 20 May '05

20 May '05

It's me again. Further down in the 82801{er | dbm} LPC initialization code, there is a block that configures NMI handling: static void lpc_init(struct device *dev) { ... /* Set up NMI on errors */ byte = pci_read_config8(dev, 0x61); byte |= (1 << 3); /* IOCHK# NMI Enable */ byte |= (1 << 6); /* PCI SERR# Enable */ pci_write_config8(dev, 0x61, byte); byte = pci_read_config8(dev, 0x70); nmi_option = NMI_OFF; get_option(&nmi_option, "nmi"); if (nmi_option) { byte |= (1 << 7); /* set NMI */ pci_write_config8(dev, 0x70, byte); } ... } >From the ICH-5 ('ER) documentation, it looks to me like this is meant to be accessing NMI_SC and NMI_EN, the NMI Status and Control and NMI Enable registers, which are at 0x61 and 0x70 in processor I/O space, not PCI configuration space. So inb()/outb() should be used instead of pci_read_config8()/pci_write_config8(). If these are the correct registers, SERR# enable is controlled by bit 2, not bit 6. Also it looks like the code does the opposite of what was intended, enabling NMIs when it should be disabling them, and vice versa. This is because Intel defines the NMI bits used above with reverse polarity...set to 1 to DISable, 0 to ENable. So the code should read instead as: #include <arch/io.h> static void lpc_init(struct device *dev) { ... /* Set up NMI on errors */ byte = inb(0x61); byte &= ~(1 << 3); /* IOCHK# NMI Enable */ byte &= ~(1 << 2); /* PCI SERR# Enable */ outb(0x61, byte); byte = inb(0x70); nmi_option = NMI_OFF; get_option(&nmi_option, "nmi"); if (nmi_option) { byte &= ~(1 << 7); /* set NMI */ outb(0x70, byte); } ... } It this looks right, I'm willing to attempt folding this change into the source (never used arch before...), but I have no way to test that it does anything other than compile. Regards, Steve Magnani Digital Design Corporation www.digidescorp.com

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot