coreboot

coreboot@coreboot.org

39717 discussions

[LinuxBIOS] 16 MBit BIOS chips
by Carl-Daniel Hailfinger 20 Jan '06

20 Jan '06

Hi, I just saw the ST M50FW016 (a 16 Mbit FWH BIOS chip) and wanted to use it for LinuxBIOS development. However, it is only (public) available in a TSOP40 package, while most mainboard BIOS chips have a PLCC32 package. Looking at the data sheet, it seems it should be reasonably easy to build a PLCC32/TSOP40 adaptor with a TSOP40 ZIF socket. Another chance would be to find somebody who orders a large enough quantity of the PLCC32 version (that is available only "on demand"). Has somebody tried or is planning to build such an adaptor? Advantages: * With a ZIF socket, you can't break anything * It would remove the need for the BIOS savior * 16 MBit is HUGE So... anybody interested? Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

[LinuxBIOS] via epia status
by Ronald G Minnich 19 Jan '06

19 Jan '06

ok, I have a filo that is working, and linux is up ... with cache off and, apparently, no enet interrupts (or interrupts of any kind? not sure yet) ron

2 2

[LinuxBIOS] changing how ldscript is made
by Ronald G Minnich 19 Jan '06

19 Jan '06

currently, the default makefile generates this for ldscript.ld [rminnich@q fallback]$ more ../normal/ldscript.ld INCLUDE ldoptions INCLUDE /home/rminnich/src/LinuxBIOSv2/src/arch/i386/init/ldscript.lb INCLUDE /home/rminnich/src/LinuxBIOSv2/src//cpu/x86/16bit/entry16.lds INCLUDE /home/rminnich/src/LinuxBIOSv2/src//cpu/x86/32bit/entry32.lds INCLUDE /home/rminnich/src/LinuxBIOSv2/src//cpu/x86/32bit/reset32.lds INCLUDE /home/rminnich/src/LinuxBIOSv2/src//arch/i386/lib/id.lds I find this intensely annoying, and there is no reason for it. I can just as easily have the makefile do the include via 'cat', and then you can see what the ldscript actually looks like. All the dependencies still work fine as well. I just tested this here. Any objection if I change the makefile so that you get something like this: HAVE_MOVNTI = 0; CONFIG_USE_INIT = 0; HAVE_FALLBACK_BOOT = 1; ROM_IMAGE_SIZE = 0x10000; PAYLOAD_SIZE = 0x10000; _ROMBASE = 0xffff0000; _RESET = 0xffff0000; . . . TARGET(binary) INPUT(linuxbios_ram.rom) SECTIONS { . . . SECTIONS { . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start); .id (.): { *(.id) } } so you can actually see the script? If not, I'll put this in the issue tracker. ron

2 1

Re: [LinuxBIOS] Serverworks HT1000/HT2000?
by Lu, Yinghai 19 Jan '06

19 Jan '06

I have finished the porting last year. And we are working on paper work with broadcom. I guess the code could to be released to public tree next a few days. YH ________________________________ From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Alan Mimms Sent: Wednesday, January 18, 2006 12:59 PM To: linuxbios(a)openbios.org Subject: [LinuxBIOS] Serverworks HT1000/HT2000? I noticed a bunch of motherboard vendors are starting to ship with products based on Serverworks (Broadcom) HT1000 and HT2000 chips. Does anyone have a project in progress to support these chips in LinuxBIOS at this point? If not, is the reason due to some limitation Serverworks has on its support in GPLed BIOS code? What about the following generation of parts from Serverworks? Thanks. Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center 1322 North Whitman Lane Liberty Lake, Washington 99019 v: 509-343-3524 f: 509-343-3501

1 0

[LinuxBIOS] Serverworks HT1000/HT2000?
by Alan Mimms 18 Jan '06

18 Jan '06

I noticed a bunch of motherboard vendors are starting to ship with products based on Serverworks (Broadcom) HT1000 and HT2000 chips. Does anyone have a project in progress to support these chips in LinuxBIOS at this point? If not, is the reason due to some limitation Serverworks has on its support in GPLed BIOS code? What about the following generation of parts from Serverworks? Thanks. Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center 1322 North Whitman Lane Liberty Lake, Washington 99019 v: 509-343-3524 f: 509-343-3501

1 0

[LinuxBIOS] trying to load a linux-tiny kernel on epia
by Ronald G Minnich 18 Jan '06

18 Jan '06

I build a linux-tiny with serial console and do this: mkelfImage --command-line="console=ttyS0,19200 " arch/i386/boot/bzImage /tmp/linux.elf Build the image, boot, get this: 33:stream_init() - rom_stream: 0xfff80000 - 0xfffeffff Found ELF candiate at offset 0 header_offset is 0 Try to load at offset 0x0 n_type: 00000001 n_name(8): ELFBoot n_desc(6): Linux n_type: 00000002 n_name(8): ELFBoot n_desc(76): 2.6.9-tiny1tiny (rminnich(a)q.cc6 malloc Enter, size 20, free_mem_ptr 0001829c malloc 0x0001829c n_type: 00000003 n_name(8): ELFBoot n_desc(2): h. Dropping non PT_LOAD segment malloc Enter, size 32, free_mem_ptr 000182b0 malloc 0x000182b0 New segment addr 0x10000 size 0x121c4 offset 0x148 filesize 0x116c (cleaned up) New segment addr 0x10000 size 0x121c4 offset 0x148 filesize 0x116c lb: [0x0000000000004000, 0x000000000001c000) segment: [0x0000000000010000, 0x000000000001116c, 0x00000000000221c4) malloc Enter, size 32, free_mem_ptr 000182d0 malloc 0x000182d0 late: [0x000000000001c000, 0x000000000001c000, 0x00000000000221c4) bounce: [0x000000000ffdc000, 0x000000000ffdd16c, 0x000000000ffe8000) malloc Enter, size 32, free_mem_ptr 000182f0 malloc 0x000182f0 New segment addr 0x91000 size 0x70 offset 0x12b4 filesize 0x0 (cleaned up) New segment addr 0x91000 size 0x70 offset 0x12b4 filesize 0x0 lb: [0x0000000000004000, 0x000000000001c000) malloc Enter, size 32, free_mem_ptr 00018310 malloc 0x00018310 New segment addr 0x100000 size 0x700000 offset 0x12b4 filesize 0x618bc (cleaned up) New segment addr 0x100000 size 0x700000 offset 0x12b4 filesize 0x6c lb: [0x0000000000004000, 0x000000000001c000) Loading Segment: addr: 0x000000000ffdc000 memsz: 0x000000000000c000 filesz: 0x0c [ 0x000000000ffdc000, 000000000ffdd16c, 0x000000000ffe8000) <- 0000000000000148 Clearing Segment: addr: 0x000000000ffdd16c memsz: 0x000000000000ae94 Loading Segment: addr: 0x0000000000091000 memsz: 0x0000000000000070 filesz: 0x00 [ 0x0000000000091000, 0000000000091000, 0x0000000000091070) <- 00000000000012b4 Clearing Segment: addr: 0x0000000000091000 memsz: 0x0000000000000070 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 filesz: 0x0c [ 0x0000000000100000, 00000000001618bc, 0x0000000000800000) <- 00000000000012b4 Clearing Segment: addr: 0x00000000001618bc memsz: 0x000000000069e744 Loading Segment: addr: 0x000000000001c000 memsz: 0x00000000000061c4 filesz: 0x00 [ 0x000000000001c000, 000000000001c000, 0x00000000000221c4) <- 0000000000062b70 Clearing Segment: addr: 0x000000000001c000 memsz: 0x00000000000061c4 Loaded segments verified segments closed down stream Jumping to boot code at 0x10000 entry = 0x00010000 lb_start = 0x00004000 lb_size = 0x00018000 adjust = 0x0ffe4000 buffer = 0x0ffd0000 elf_boot_notes = 0x00011aa0 adjusted_boot_notes = 0x0fff5aa0 Firmware type: LinuxBIOS and that's it. Seems all the segments load, but then ... no dice. EARLY_PRINTK is enabled. OK, anyone beat me to doing this? What have you seen? thanks ron

1 0

[LinuxBIOS] confirmed: via epia IDE now broken
by Ronald G Minnich 18 Jan '06

18 Jan '06

somewhere, somebody busted something somehow. anybody wanna guess? boot: hda1:/vmlinuz-normal initrd=hda1:/initrd-normal.gz root=/dev/ram0 consol0 ide_probe: ide_probe: drive 0 ide_probe: ide_probe: base 0x0xnide_bus_floating: reg 0x1f7 status 0x50 ide_software_reset: Waiting for ide0 to become ready for reset... ok IDE time out No drive detected on IDE channel 0 That base 0x0 look suspicious to me. I'm looking at this now. Except for this problem, epia is working ok, though I have not (re) tested vga yet. I see a LOT of issue tracker stuff from yhlu (12 items!) in chatting or testing. Can we get these cleaned up please? Also, what's the state of jason schildt's issue 30, 'testing'? APIC cluster auto-probing? Stepan? There are almost 20 items 1 month old! Please, folks, let's get this stuff put to bed. There's more work to be done, and this kind of old issue just drags us down. thanks ron

2 2

[LinuxBIOS] setting up COM1: a subtle point
by Ronald G Minnich 18 Jan '06

18 Jan '06

I see that (*probably my fault*?) there was a register "com1" = "{1}" in the Config.lb for via/epia. This is actually a bad idea, since you can't control the baud rate. What you want to do is this: register "com1" = "{TTYS0_BAUD}" ron

1 0

[LinuxBIOS] via/epia
by Ronald G Minnich 17 Jan '06

17 Jan '06

OK, I had to remove the AGP entry from Config.lb (*why*) Now, at some point, part way through, the baud rate pops to 115200 from 19200. Any guesses here? Somebody mess with baud rate and not tell us? Finally, IDE no longer works. ron

1 0

Re: [LinuxBIOS] failure to execute via/epia with rev 2158
by Lu, Yinghai 17 Jan '06

17 Jan '06

You may need to remove the Device pci 0.1 on end # AGP bridge YH

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