Thanks for the code.
I put usbdevice_direct.c in lib/, and call it from usb2_init in
"No device in debug port"
Waiting for cable, hope to get that cable next Tuesday.
Will create usbdebug_direct_console.c in console/ for linuxbios_ram
also usbdebug_direct_serial.c in pc80/ for cache_as_ram.c
I see the epia is "Broken". No wonder I could never get it to work
properly. Is anyone ever going to get this to work? What's broken anyhow?
I know the processor is missing the CMOV instruction.
Shaddam Corrino IV wrote:
> I had a closer look at this i815 platform
> it contains :
> SST49LF004A, which seems to be 512KiB flash
> Unfortunatelly, it seems that the above flash is soldered to the MBO :-(
This is the case with the D815EEA, but other motherboards (probably not
from intel) may have removable flash. I'm not really concerned with
this, I ordered an extra plcc socket and a couple flash chips for this
board when I ordered the flash chips for the athlon, and I don't think
I'll have any problem with the sodiering process. If you've never used a
sodiering iron before though, you might want to see if you can find
someone to do it for you.
> Does it mean there's no way I can use the system for L/B or is there
> some inexpensive way to correct this deficiency?
> Not sure if that's a good price, but you can get complete 1 GHZ i815
> systems (ie ready for use desktop) here for about $65.
That's about what I paid for mine, just for the 1ghz cpu and mobo, then
another $40 for 512mb PC133 and an asus P2-99 (440zx), and case/power
supply/hard drive/cdrom from my collection. I've been following the
discussion about i855 support, and that honestly has me concerned. This,
if i remember right, was the first (well, second, but afaik it's just
i810+graphics) desktop chipset intel made after ending the 440 line, so
I don't know how good the docs will be (ie did intel decide to go into
lockdown yet or no?), and if they suck royally, I probably won't bother
messing around with this.
Oops, forgot to cc the mailing list!
since the romcc builtin preprocessor silently eats lines of code,
can we just use the gcc preprocessor (cpp) before calling romcc as
Is there a reason romcc has its own preprocessor?
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info(a)coresystems.de • http://www.coresystems.de/
From: ebiederm(a)xmission.com [mailto:email@example.com]
Sent: Friday, December 01, 2006 1:15 PM
Peter Stuge <stuge-linuxbios(a)cdy.org> writes:
>> On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote:
>>> Well, earlyprintk will not work, as you need PCI up and running.
>> Not all of it though. LinuxBIOS will probably do just enough PCI
>> setup to talk to the EHCI controller and use the debug port _very_
>> soon after power on.
>Right. For LinuxBIOS not a problem for earlyprintk in the kernel
>somethings might need to be refactored. The challenge in the kernel
>is we don't know at build to how to do a pci_read_config...
Otherwise printk will come too late, and will not get output before pci
bus ops is set.
>The other hard part early in the kernel is the fact that the
>bar is memory mapped I/O. Which means it will need to get mapped
>into the kernels page tables.
several entries to map 0xfc000000 ( PCI IO mem range) in page table in