coreboot

coreboot@coreboot.org

11 participants
39714 discussions

RE: Etherboot and Linuxbios
by YhLu 04 Jan '05

04 Jan '05

Try 5.2.6 at first. YH -----Original Message----- From: Gin [mailto:ginlin@nexcom.com.tw] Sent: Sunday, January 02, 2005 9:49 PM To: linuxbios(a)clustermatic.org Subject: Etherboot and Linuxbios Etherboot version used: 5.3.11 I am trying to build a Etherboot image to work with Linuxbios but got a compile error. There are couple undefined references to some functions due to the settings in the Config file. I commented out the PCBIOS option, and define the following. -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE -DPXE_IMAGE -DPXE_EXPORT p.s The undefined reference is due to the undefined PCBIOS. _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

thread here carring a payload
by hisheirs＠bellsouth.net 30 Dec '04

30 Dec '04

mr admin .. the following page is being used to deliver W32.Netsky.P@mm!enc just thought you should know

1 0

Re: off-topic: PIC and ETRAX [was: Memtest+]
by Peter Stuge 30 Dec '04

30 Dec '04

On Thu, Dec 30, 2004 at 02:25:47PM -0500, Dave Aubin wrote: > Nice read Peter, thank you for the info:) No problem! > Would be nice to use some voltage reference differencing > Instead of using a Max 232, but the Max is probably a cleaner > approach. The MAX232 is pretty common for connecting both PIC and AVR devices to RS-232 equipment. It just needs a few external capacitors, which is nice. > A nerdy aside, I heard the 18F4550 and 18F2550 can run up to 12MIPs > from a 4MHz crystal, they've got a whopping 16K of flash, and they > have a Full-Speed USB v2.0 hardware. Yep. And 2kb RAM. Check out the data sheet page 11 and chapter 2. http://ww1.microchip.com/downloads/en/DeviceDoc/39632b.pdf > Now if I could only run Linux on a PIC;) Linux? That's for the ETRAX, made by Axis. Check out http://developer.axis.com/ Everything-is-included Linux chip with 10/100 and both NOR and NAND flash for boot as well as storage. They've ported the GNU toolchain too. I'm still waiting for some project where I can use the MCM and end up with a few extra boards. :) //Peter

2 1

off-topic part 2: PIC and ETRAX [was: Memtest+]
by Dave Aubin 30 Dec '04

30 Dec '04

Again Peter, very nice:) I will give you one more tid bit as it consumes less power than the Axis, but still runs Linux and is quite small:) Check out: http://www.brightstareng.com/ They have entire set ups on a form factor less than a credit card Running Linux:) Although it is still not a PIC, it is very good For PIC type needs. Thanks again, Dave:) -----Original Message----- From: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Peter Stuge Sent: Thursday, December 30, 2004 2:54 PM To: LinuxBIOS Subject: Re: off-topic: PIC and ETRAX [was: Memtest+] On Thu, Dec 30, 2004 at 02:25:47PM -0500, Dave Aubin wrote: > Nice read Peter, thank you for the info:) No problem! > Would be nice to use some voltage reference differencing Instead of > using a Max 232, but the Max is probably a cleaner approach. The MAX232 is pretty common for connecting both PIC and AVR devices to RS-232 equipment. It just needs a few external capacitors, which is nice. > A nerdy aside, I heard the 18F4550 and 18F2550 can run up to 12MIPs > from a 4MHz crystal, they've got a whopping 16K of flash, and they > have a Full-Speed USB v2.0 hardware. Yep. And 2kb RAM. Check out the data sheet page 11 and chapter 2. http://ww1.microchip.com/downloads/en/DeviceDoc/39632b.pdf > Now if I could only run Linux on a PIC;) Linux? That's for the ETRAX, made by Axis. Check out http://developer.axis.com/ Everything-is-included Linux chip with 10/100 and both NOR and NAND flash for boot as well as storage. They've ported the GNU toolchain too. I'm still waiting for some project where I can use the MCM and end up with a few extra boards. :) //Peter _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

RE: Memtest+
by Dave Aubin 30 Dec '04

30 Dec '04

Nice read Peter, thank you for the info:) Would be nice to use some voltage reference differencing Instead of using a Max 232, but the Max is probably a cleaner approach. A nerdy aside, I heard the 18F4550 and 18F2550 can run up to 12MIPs from a 4MHz crystal, they've got a whopping 16K of flash, and they have a Full-Speed USB v2.0 hardware. Now if I could only run Linux on a PIC;) Thanks, Dave -----Original Message----- From: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Peter Stuge Sent: Thursday, December 30, 2004 1:57 PM To: LinuxBIOS Subject: Re: Memtest+ On Wed, Dec 29, 2004 at 04:58:57PM -0500, Dave Aubin wrote: > Has no one else hit this? One idea I have being a PIC lover is To > use some LED's on the mother board and make a serial protocol Over the > LED's, much like a software UART for a PIC. > Anyone have an input on this? That will work just fine, but watch out for running the "GPIO serial bus" too fast for the PIC. (With GPIO I'm referring to pins driving the LEDs on the target system, not a PIC GPIO port.) If simplex is fun enough, you could use a single GPIO pin and connect that to RX on the PIC, connect TX on the PIC to a MAX232 and plug that into a regular serial port on a PC running a terminal emulator. All the PIC has to do then is read from RCREG and send everything back out through TXREG. Any PIC with a USART in async mode should do for this. For duplex (etherboot/filo menu) you may need a separate GPIO pin for flow control, the usual serial start/stop bit handshake may not be very reliable without a hardware UART on the target system. The easy solution is to use a synchronous serial interface instead; add a clock signal driven by the target. This also overcomes any problems caused by the PIC baud rate generator being controllable only with relatively low precision. The 16F87x series have both an MSSP and a USART; the MSSP could be used in SPI Slave mode for duplex communication with the target system, and the USART for talking to the PC running the terminal emulator. One thing to keep in mind is that SPI always transmits data in both directions, this means that the serial port wont be 8-bit clean unless you make a small protocol to indicate when data actually is available, this wastes twice the bandwidth, but may still be good enough. A USB device with a 16C745 or possibly 18F2550 if they can be sourced is tempting, but that also requires writing some kind of driver for the USB device, or figuring out how an existing USB<->serial adapter works and reimplementing that. Too much work. Plus the 16C7x5 only do low-speed USB. Hope it works out though! //Peter _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

Re: Memtest+
by Peter Stuge 30 Dec '04

30 Dec '04

On Wed, Dec 29, 2004 at 04:58:57PM -0500, Dave Aubin wrote: > Has no one else hit this? One idea I have being a PIC lover is > To use some LED's on the mother board and make a serial protocol > Over the LED's, much like a software UART for a PIC. > Anyone have an input on this? That will work just fine, but watch out for running the "GPIO serial bus" too fast for the PIC. (With GPIO I'm referring to pins driving the LEDs on the target system, not a PIC GPIO port.) If simplex is fun enough, you could use a single GPIO pin and connect that to RX on the PIC, connect TX on the PIC to a MAX232 and plug that into a regular serial port on a PC running a terminal emulator. All the PIC has to do then is read from RCREG and send everything back out through TXREG. Any PIC with a USART in async mode should do for this. For duplex (etherboot/filo menu) you may need a separate GPIO pin for flow control, the usual serial start/stop bit handshake may not be very reliable without a hardware UART on the target system. The easy solution is to use a synchronous serial interface instead; add a clock signal driven by the target. This also overcomes any problems caused by the PIC baud rate generator being controllable only with relatively low precision. The 16F87x series have both an MSSP and a USART; the MSSP could be used in SPI Slave mode for duplex communication with the target system, and the USART for talking to the PC running the terminal emulator. One thing to keep in mind is that SPI always transmits data in both directions, this means that the serial port wont be 8-bit clean unless you make a small protocol to indicate when data actually is available, this wastes twice the bandwidth, but may still be good enough. A USB device with a 16C745 or possibly 18F2550 if they can be sourced is tempting, but that also requires writing some kind of driver for the USB device, or figuring out how an existing USB<->serial adapter works and reimplementing that. Too much work. Plus the 16C7x5 only do low-speed USB. Hope it works out though! //Peter

1 0

RE: Memtest+
by Dave Aubin 29 Dec '04

29 Dec '04

Hi, Home groan motherboard that does not have a serial connection Due to cost concerns. So using the serial line is out of the Question. Has no one else hit this? One idea I have being a PIC lover is To use some LED's on the mother board and make a serial protocol Over the LED's, much like a software UART for a PIC. Anyone have an input on this? Thanks, Dave -----Original Message----- From: YhLu [mailto:YhLu@tyan.com] Sent: Wednesday, December 29, 2004 5:06 PM To: Dave Aubin; LinuxBIOS Subject: RE: Memtest+ What's you motherboard... If you are using btext_console, then you may need to add bcontext console calling in memtest+, Please refer btext in Etherboot.... YH -----Original Message----- From: Dave Aubin [mailto:daubin@actuality-systems.com] Sent: Wednesday, December 29, 2004 12:27 PM To: LinuxBIOS Subject: Memtest+ Hi, I'm trying to get memtest+ to fly on our system. Problem is That I don't have a console on my system. I have USB and a video card, But the video card bios isn't run since I run linuxbios. Can anyone please give me a hint as to how they've done it? Thanks, Dave _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

RE: Memtest+
by YhLu 29 Dec '04

29 Dec '04

What's you motherboard... If you are using btext_console, then you may need to add bcontext console calling in memtest+, Please refer btext in Etherboot.... YH -----Original Message----- From: Dave Aubin [mailto:daubin@actuality-systems.com] Sent: Wednesday, December 29, 2004 12:27 PM To: LinuxBIOS Subject: Memtest+ Hi, I'm trying to get memtest+ to fly on our system. Problem is That I don't have a console on my system. I have USB and a video card, But the video card bios isn't run since I run linuxbios. Can anyone please give me a hint as to how they've done it? Thanks, Dave _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

Memtest+
by Dave Aubin 29 Dec '04

29 Dec '04

Hi, I'm trying to get memtest+ to fly on our system. Problem is That I don't have a console on my system. I have USB and a video card, But the video card bios isn't run since I run linuxbios. Can anyone please give me a hint as to how they've done it? Thanks, Dave

1 0

RE: vgabios.c and vgachip.h removed
by Li-Ta Lo 29 Dec '04

29 Dec '04

On Mon, 2004-12-27 at 21:04, Yinghai Lu wrote: > Ollie, > > It seems that there some allocate resource for vga...stuff, and main focus > is to fix the mem io to some range and enable the io for vga. > > For the first one, I suggest you to create one driver for the VGA device, > and it could override the read_resource of pci_read_resource to return fixed > mem resource. > > Then the MB Config.lb could include the "driver ....." > I am doing that now. I just haven't committed that part yet. BTW, I don't think the current compute_allocate_resource can handle the legacy vga mem resource (0xA0000-0xBFFFF) by modifying the read_resource() of either the VGA device or K8 NB. I always got strange allocation (like resources allocated near 1MB for other devices). I guess the current K8/northbridge.c is the best thing I can get. Ollie

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