coreboot December 2004

coreboot@coreboot.org

33 participants
95 discussions

Does linux kernel parse linuxbios table?
by Liu Tao 13 Jan '05

13 Jan '05

Hello Eric, I searched the linux kernel mail archive and found your patch for x86 boot linuxbios support, but I didn't find the linuxbios table parse code in linux-2.6.8.1, does linux kernel still parse the linuxbios table now? Regards, Liu Tao

3 2

flash rom utility
by Gin 09 Jan '05

09 Jan '05

Is there a flash rom utility I can use to flash linuxbios to my EEPROM? Currently I am WICE to do it. But I can't depend on a hardware device to update bios. gin

3 6

low level shell
by Bryan E. Chafy 06 Jan '05

06 Jan '05

Apologies if this is a redundant contribution. None of my pc motherboards have JTAG or HW debug capabilites. And constantly (hot)flashing, changing ram init code, then (hot)flashing again gets old really fast. Looking around, I couldnt find any debug tools that would operate at basically the reset vector level. I thought this was the goal of openbios, but I got lost in all the jibberish about 4th and firmware standards. So I set out to make a small interactive low level shell with the goal of providing at least some tools to aid in board/memory bringup and debugging. This was nontrivial given the system limitations, however I got a few things to work. Attached is llshell.inc (for linuxbios1, Ive not tried any of the new stuff yet) and llshell_linux (for running/testing inside of linux). It's written entirely in asm and can run in a memoryless early stage (say at the beginning of ram_set_registers or points afterword). List of commands: beep -- pc speaker beep rst (or RST) -- reset out(b,w,l) <val> <port> -- raw out val at port in(b,w,l) <port> -- show raw port value jmp <address> -- jmp to address (llshell addr is in eax) call <address> -- funcion call (assumes a working stack) cli -- clear interrupts sti -- enable interrupts push <value> -- push value onto stack pop -- pop from stack and display wm(b,w,l) <addr> <val> -- write mem dm <addr> <lines> -- dump mem mcp <src> <dst> <size> -- mem copy mpat <pat> <dst> <size> -- mem pattern memt <begin> <end> -- memory test pcir(b,w,l) <loc> -- pci read config pciw(b,w,l) <loc> <val> -- pci write config dl <addr> <size> -- memory download (display xor cheksum at completion) cram <addr> <size> -- enable cache to be ram (experimental) baud <val> -- change baudrate (not yet implemented) exit -- exit shell All values in hex (0x prefixing ok)

7 10

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

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2004