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
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
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)
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
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
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
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
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
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
