coreboot

coreboot@coreboot.org

10 participants
39710 discussions

SST39SF040
by Xavier Pegenaute 24 Nov '03

24 Nov '03

Hi, any one know why is not useful the SST39SF040 ? i'm using epia-m and it works fine with SST39SF020 but with the other one the computer is dead. I saw the technical papers and speak in the same way with 020 and 040 then it should be the same? or may be i don't know to read this papers :-) Xavi.

4 6

V2 dependency problems
by Dave Ashley 22 Nov '03

22 Nov '03

The auto.c file has #includes for things like raminit.c. If I change the auto.c file and rebuild, the changes "take". If I change raminit.c, the changes don't take. I have to touch the auto.c to get it to work. Does everyone have this problem? I do cd targets ; ./buildtarget via/epiam (Above done only once) Then to rebuild make -C via/epiam/epiam One other note that I kind of recall being discussed. I cloned the vt8231 directory to make the vt8235 directory, but a lot of the separate pci devices that are inside both devices are identical. Isn't there some way of separating out the support code for the individual components maybe based on the pci device id's? This would avoid code duplication. Like the southbridge/via/vt8231 directory would be the toplevel file that would glue together all the separate components. It would be a list of what individual drivers to include + no redundancy. Maybe there could be another area like components/via/1106-0571 One thing that would be convenient though is devices that are almost exactly the same but have different pci device id's. CVS doesn't like symlinks though. You'd like the handler code to support all equivalent devices. So maybe having the directory name based on the pci id is no good. Maybe instead components/via/ide/id.h components/via/ide/handler.c The id.h file would list the pci device id's the handler supports. Just some thoughts. -Dave

1 0

VIA EPIA MII
by Niki Waibel 22 Nov '03

22 Nov '03

seems to be almost the same as the epia-m + Onboard CardBus / CompactFlash... http://www.viaembedded.com/product/epia_MII_spec.jsp?motherboardId=202 Processor - VIA C3/ VIA Eden ESP processor Chipset - VIA CLE266 North Bridge - VIA VT8235 South Bridge System Memory - 1 DDR266 DIMM socket - Up to 1GB memory size VGA - Integrated VIA Unichrome 2D/3D graphics with MPEG-2 Accelerator, motion compensation and duo-view support niki

1 0

[announce] LinuxBIOS on AMD64
by Stefan Reinauer 22 Nov '03

22 Nov '03

Hi, I wrote a paper on LinuxBIOS on the AMD64 platform that covers some aspects on the following topics: * image configuration * porting LinuxBIOS to new AMD64 motherboards * debugging and tweaking hints * some internals The document is available at http://www.openbios.org/docs/LinuxBIOS-AMD64.pdf I am very glad to announce that this document is released under the GPL, so please go ahead and use it, spread it, change it. But please do submit your changes back so everybody can benefit. I suggest putting the document in the freebios2 documentation subdirectory, if nobody objects. (What is the preferred file format for that? TeX? The document was initially created using OpenOffice 1.1 8) Don't hesitate to make suggestions on improvement, report typos, badly written english, or whatever comes to your mind when reading the paper. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development

3 8

V2 epia-m link to tarball
by Dave Ashley 21 Nov '03

21 Nov '03

I got the interrupts working as per Ron's advice, also pulled the irq fixup stuff out of the vt8235 source and stuck it in with mainboard.c. I made a tarball of the changes, it can be downloaded here: http://www.xdr.com/dash/linuxbios I'll update that directory as I make changes. I think the vt8623 code is pretty much finished except I need to turn on VGA. The vt8235 tree is basically a clone of the vt8231 tree with all occurances of 8231 changed to 8235, and the PCI ID's changed. This probably needs some major rework (trying to initialize devices that aren't there + not initializing devices that are there. However I'm at a state where I can boot the system on the bios and get into linux. DDR init is the same as V1 for now. I'm planning on getting vga up and hopefully the vga bios. Once that is functional I'll be pretty close to where I was on V1. Then I'll try to get the smbus going to access the spd registers. Then hopefully someone else can take it from there and do the actual ddr configuration from spd (I hope). -Dave

1 0

Re: v2 epia-m progress
by Dave Ashley 21 Nov '03

21 Nov '03

>use the v2 epia port as a model on how to set up interrupts. Can you point me in the right direction? What I've done so far is go into src/mainboard/via/epiam (cloned from epia) I regenerated irq_tables.c by flashing with award bios, booting up the board, then running the getpir.c utility from version1 (note this utility isn't present in version 2). It is still calling the 8231 code. Is the interrupt stuff in with the southbridge? Or is it the northbridge? -Dave

2 1

v2 epia-m progress
by Dave Ashley 21 Nov '03

21 Nov '03

I did a quick hack to enable the DDR memory just like v1's epia-m hack. The northbridge.c just has a single function sizeram() which I implemented to just return as if there is 64M of memory. I commented out the attempts to init the smbus + sdram, and let everything proceed. It got to the etherboot payload, requested a bootfile, loaded it, launched linux, and initialized linux quite well, then crapped out trying to do network activity. It is obviously an interrupt problem, packets are coming out of the box but it can't receive them. This is very encouraging after about 3 hours or so. I haven't really done any initialization of either the north or south bridge, just the hack to initialize the DDR memory. I converted the asm code to 'C' but it is still hardcoded as opposed to reading the SPD contents. This was actually a surprise, I was expecting it to fail further along in linuxbios and suddenly all these linux messages were coming out. -Dave

2 1

V2 epia-m support
by Dave Ashley 21 Nov '03

21 Nov '03

I've embarked on adding epia-m support to v2 of linuxbios. I am at the point where I have debug messages coming out the serial port. My plan of attack is to clone the epia code but rename everything epiam, and add support for the proper north + south bridges and mainboard init code. Which means porting these components from v1: vt8623 northbridge vt8235 southbridge vt1211 superio device Currently to get serial output working I grabbed the vt1211 serial init code and just shoved it into the auto.c of the epiam for now, calling it enable_vt1211_serial... Modified the default 19200 baud to 115200 baud (but I actually get 57600 baud). If anyone can offer any warnings or advice it would be helpful. I may get called off this project at any time though... -Dave

2 1

EPIA-M 600 Cannot start
by Dmitry Borisov 21 Nov '03

21 Nov '03

My respect to all. I've got problem trying to burn linuxbios into EPIA-M 600. Config file attached if it could help. When I burn image and restart mb, it does not say anything to the serial. Even single character. Here is the output from flash_rom utility: SST39SF020A found at physical address: 0xfffc0000 Part is SST39SF020A Programming Page: 0063 at address: 0x0003f000 Sorry, that's pretty much I have from linuxbios to share. I wonder if anyone having EPIA-M 600 could send me the correct config file and correct romimage as well or let me know when I'm wrong. Appreciate your help, Dmitry/

2 3

Re: V1 trouble with gcc 3.2.3 SOLUTION!!!
by Dave Ashley 21 Nov '03

21 Nov '03

Aside from the = vs == bug which probably wasn't too damaging, the problem was caused because the newer compiler doesn't use as many registers in its code, specifically the EBX register. So at the start of the do_vgabios() function it doesn't bother to push EBX on the stack to preserve it. However code higher up that calls this function had stored something in EBX, which the call to the vgabios happily trashes. The fix is to push ebx within the real_mode_switch_call_vga function: /* save the stack */ "push %ebx\n" "mov %esp, __stack\n" ... " mov %ax, %ss \n" " mov __stack, %esp\n" "pop %ebx\n" ); It won't hurt to push other registers like %esi for example. In fact why not push all the registers just to be safe... This is a pretty subtle bug, people should understand what was wrong and how the fix works. -Dave

3 2

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