What's the current status of LinuxBIOS on plain EPIA boards? It seems to be very unclear. The "Supported motherboards" Wiki page lists it, but has a lot of "???". The build tutorial page -- like all the others -- links to nothing. The FreeBIOS howto says it doesn't have VGA support, though that is of course two years out of date.
When I build it, the generated BIOS image is 256k -- which doesn't leave space to prepend a VGA BIOS. So is the status of LinuxBIOS on these boards the same as it was with FreeBIOS 2 years ago?
Thanks -Alex Mauer "hawke"
Alex L. Mauer wrote:
What's the current status of LinuxBIOS on plain EPIA boards? It seems to be very unclear. The "Supported motherboards" Wiki page lists it, but has a lot of "???". The build tutorial page -- like all the others -- links to nothing. The FreeBIOS howto says it doesn't have VGA support, though that is of course two years out of date.
nobody has had time to fix it, and we've had no requests. Some commit busted it when people tried to upgrade it for later EPIAs -- sorry.
I'm sorry, I don't think it works.
thanks
ron
Ronald G Minnich wrote:
nobody has had time to fix it, and we've had no requests. Some commit busted it when people tried to upgrade it for later EPIAs -- sorry.
Well, that's OK -- it's free software after all. But I guess this could be considered to be a request, then. If/when someone gets the time, even updating the status to indicate that it doesn't work would be nice; fixing/creating the VGA support would be much appreciated as well.
-Alex Mauer "hawke"
On 4/30/06, Alex L. Mauer hawke@hawkesnest.net wrote:
Ronald G Minnich wrote:
nobody has had time to fix it, and we've had no requests. Some commit busted it when people tried to upgrade it for later EPIAs -- sorry.
Well, that's OK -- it's free software after all. But I guess this could be considered to be a request, then. If/when someone gets the time, even updating the status to indicate that it doesn't work would be nice; fixing/creating the VGA support would be much appreciated as well.
What happens wne you boot with the current version? Don't try any vga just do serial to start with.
Richard Smith wrote:
What happens wne you boot with the current version? Don't try any vga just do serial to start with.
Well, if I boot LB alone, I get the following (at debug level 9):
[line noise?]
LinuxBIOS-1.1.8.0Normal Mon May 8 23:51:16 CDT 2006 starting... 87 is the comm register SMBus controller enabled vt8601 init starting 00000000 is the north 1106 0601 0120d4 is the computed timing NOP PRECHARGE DUMMY READS CBR MRS NORMAL set ref. rate enable multi-page open Slot 00 is SDRAM 08000000 bytes x2 0100 is the chip size 000e is the MA type Slot 01 is SDRAM 08000000 bytes x2 0100 is the chip size 000e is the MA type Slot 02 is empty Slot 03 is empty vt8601 done Copying LinuxBIOS to ram. Jumping to LinuxBIOS.
....But if I boot from the normal BIOS, and then do a soft reset, it actually works...almost. A transcript of that (not attaching as it's about 16k) is available at http://web.hawkesnest.net/users/hawke/minicom.cap.txt
interesting portion: it loads Linux (Ubuntu), and gets to:
* Loading hardware drivers... [ 30.094223] Unable to handle kernel paging request at virtual address 89000005 [ 30.118509] printing eip: [ 30.127570] c0120468 [ 30.134920] *pde = 00000000 [ 30.144278] Oops: 0002 [#1] [ 30.153623] PREEMPT [ 30.161026] Modules linked in: evdev ext3 jbd dm_mod raid1 md_mod ide_generic uhci_hcd usbcore ide_cd cdrom ide_disk via82cxxx generic processor fbcon tileblit font bitblit softcursor capability commoncap [ 30.222441] CPU: 0 [ 30.222446] EIP: 0060:[<c0120468>] Not tainted VLI [ 30.222454] EFLAGS: 00010086 (2.6.15-22-386) [ 30.262820] EIP is at do_setitimer+0x98/0x6c0 [ 30.277328] eax: 00000000 ebx: deca0000 ecx: de8724c0 edx: 00000000 [ 30.299826] esi: de8724c0 edi: deca1fa8 ebp: df22f030 esp: deca1f2c [ 30.322318] ds: 007b es: 007b ss: 0068 [ 30.335957] Process udevd (pid: 2741, threadinfo=deca0000 task=df22f030) [ 30.357457] Stack: 00000000 00000000 df1feb7c deca0000 c17b5850 b7e14080 c0150e05 df607560 [ 30.385794] deca7cd4 b7e14080 c17b5850 df1feb7c 00000000 00000000 df607560 de8724c0 [ 30.414057] deca7cd4 c0116a36 df607560 000000b4 00000003 08089d78 deca0000 c0125b62 [ 30.442320] Call Trace: [ 30.451297] [<c0150e05>] __handle_mm_fault+0xa5/0x210 [ 30.468488] [<c0116a36>] do_page_fault+0x216/0x61a [ 30.484823] [<c0125b62>] sys_alarm+0x32/0x70 [ 30.499452] [<c0103089>] syscall_call+0x7/0xb [ 30.514367] Code: 04 00 00 83 c0 40 50 e8 57 4e 00 00 59 5e 85 c0 78 c1 8b 8d 6c 04 00 00 89 4c 24 3c 8b 7c 24 64 8b 07 8b 57 04 3d 54 c3 20 00 0f <87> 1d 05 00 00 89 c6 31 ff 89 54 24 0c 89 d0 c1 f8 1f 89 44 24 [ 30.580230] <6>note: udevd[2741] exited with preempt_count 1 [ 32.620544] parport_pc: VIA 686A/8231 detected [ 32.635539] parport_pc: probing current configuration [ 32.652379] parport_pc: Current parallel port base: 0x378 [ 32.670341] parport_pc: VIA parallel port disabled in BIOS [ 32.688650] parport: PnPBIOS parport detected. [ 32.703766] pnp: Device 00:10 disabled. [ 32.759075] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 32.794165] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 32.940348] irda_init() [ 32.948760] NET: Registered protocol family 23 [ 33.192448] Linux agpgart interface v0.101 (c) Dave Jones [ 33.219506] agpgart: Detected VIA Apollo ProMedia/PLE133Ta chipset [line noise?] 23:51:25 CDT 2006 starting...
and then it looks like it resets several times, and finally appears to give up.
Let me know what if any additional info would be helpful.
-Alex Mauer "hawke"
some commit totally busted memory timings on non-M. I have not had time to even think about it.
thanks
ron
On 5/9/06, Ronald G Minnich rminnich@lanl.gov wrote:
some commit totally busted memory timings on non-M. I have not had time to even think about it.
Attached is the svn log for mods to vt8601 raminit.c. Try pulling some of these old versions and see if you can find one that works. Then you can diff it and we can see what changed.
Looking at the code I see many #defines that set memory speed and CL timing. You should check those out and see if they match your board.
-- Richard A. Smith
Richard Smith wrote:
On 5/9/06, Ronald G Minnich rminnich@lanl.gov wrote:
some commit totally busted memory timings on non-M. I have not had time to even think about it.
Attached is the svn log for mods to vt8601 raminit.c. Try pulling some of these old versions and see if you can find one that works.
OK.
First I tried pulling those revisions of the entire tree.
r1954 and earlier, romcc wouldn't compile. r1619 and earlier, buildtarget failed on the config files.
So I tried just pulling src/northbridge/via/vt8601/raminit.c in from each of those revisions.
None of them got past the jump to LinuxBIOS.
Tonight I'll try versions between 1619 and current with romcc from the current version but all else being their own versions.
On 5/10/06, Alex Mauer hawke@hawkesnest.net wrote:
So I tried just pulling src/northbridge/via/vt8601/raminit.c in from each of those revisions.
Have you looked at the #defines in raminit.c? I see serveral that you may need to verify are set the right way for you board.
-- Richard A. Smith
Alex Mauer wrote:
So I tried just pulling src/northbridge/via/vt8601/raminit.c in from each of those revisions.
None of them got past the jump to LinuxBIOS.
Alright, more info now. I worked with Richard Smith for awhile, and did the following using the latest BIOS available. (my #defines were set at reasonably conservative settings, and were fine for my board)
Enabled a call to ram_check.
Got the LB northbridge RAM configuration to be the same as it is for the factory BIOS, to the extent possible, based on the datasheet for the vt8601a and output of 'lspci -xxx'
Results from the ram_check seem to show that the ram is not being properly intialized and/or refreshed. I checked an area from 0x20000 through 0x21000. As the ram check progresses, it starts out reading values 0x0002ffcc, then gradually drops until it reads 0x00020000 and finally 0x00000000.
At this point I'm rather stuck.
Ron (or anyone else, really), do you have a chance to look at this and/or advise me on things I can do/try in order to get this working again? I can provide output from my test system, and am happy to test as needed.
Thanks much
-Alex Mauer "hawke"
At this point I'm rather stuck.
Ron (or anyone else, really), do you have a chance to look at this and/or advise me on things I can do/try in order to get this working again?
I'll chime in here that we have pulled lots of different raminits from past revs and replaced the one in the current rev but no success.
We have also reviewed the data sheet and as far as static config goes we are set the same as the factory northbridge. So its must be some sort of magic method during the init.
One thing we haven't done is tested a complete tree build from some of the older revs. Mostly because the older trees don't seem to build for Alex.
If anyone has a rev that they really think will work then we can pull it and figure out why it won't build on Alex's system or perhaps build it on a system that works and then send it to him for testing.
have you guys tried building from the old arch repo?
I would not forward-port code. Do a build using an entire old tree.
ron
Alex Mauer wrote:
Ron (or anyone else, really), do you have a chance to look at this and/or advise me on things I can do/try in order to get this working again? I can provide output from my test system, and am happy to test as needed.
Go to linuxbios v1, find the epia. Figure out the hard-codes I used for DRAM. Use them for v2 epia non-m, and see how it goes.
That chipset was rather buggy. It was a nightmare to get it to work.
ron