Hello all guys here.
Finally, the very foolish guy in Tokyo has succeeded to run LX2 on my EPIA M/B. Thank you all. Thanks for all helps. Thank you!!!.
But, of course, there are problems and questions.
--------------- first, the biggest issue is, DIMMs are really picky. The M/B is natively picky, I mean, even with Award BIOS, it is picky. but the problem is much more serious with LX2. I tested with two EPIA M/B and 5 DIMMs which all are confirmed to work well with Award BIOS. And the result is too much great. Only one combination worked in these 10 combinations. Guys, can you help?
I think that one solution is hard coding the params of mem in a BIOS image. But, how?
-------------- The second issue is, booting time. It is very fast before a kernel loaded, but after this, there are three glitches. I know at least two of them are not LX2 issue, but I hope any advice.
1. Just after "Jumping to entry point...". Probably this waiting is caused by "Uncompressing Linux kernel", but it is much slower than normal booting. Takes about 2 sec.
2. "Console: colour dummy device 80x25 <---- here. Memory: 128128k/131072k available" This comes from memory checking? It takes about 1 sec.
3. IDE recognizing. I added "ide0=0x1f0,0x3f6,14 ide1=noprobe", but it takes about 2 secs.
--------------- The third issue is, VGA. I read the FreeVGA paper. Yes, it seems great. But such complicated technology is really necessary? For example, this guy succeeded to use normal VGA bios, although I failed. http://www.carbotpc.com/linux/index.html Or, just using Xfree86 driver doesnt work?
--- Okajima, Jun. Tokyo, Japan.
On Sun, 2005-07-24 at 12:33 +0900, Jun OKAJIMA wrote:
Hello all guys here.
Finally, the very foolish guy in Tokyo has succeeded to run LX2 on my EPIA M/B. Thank you all. Thanks for all helps. Thank you!!!.
But, of course, there are problems and questions.
first, the biggest issue is, DIMMs are really picky. The M/B is natively picky, I mean, even with Award BIOS, it is picky. but the problem is much more serious with LX2. I tested with two EPIA M/B and 5 DIMMs which all are confirmed to work well with Award BIOS. And the result is too much great. Only one combination worked in these 10 combinations. Guys, can you help?
I think that one solution is hard coding the params of mem in a BIOS image. But, how?
The documentation from VIA is simply crap. Nobody actually really know the correct value to program to the memory controller.
The second issue is, booting time. It is very fast before a kernel loaded, but after this, there are three glitches. I know at least two of them are not LX2 issue, but I hope any advice.
- Just after "Jumping to entry point...".
Probably this waiting is caused by "Uncompressing Linux kernel", but it is much slower than normal booting. Takes about 2 sec.
- "Console: colour dummy device 80x25 <---- here. Memory: 128128k/131072k available"
This comes from memory checking? It takes about 1 sec.
The cache is not enable at all due to some mistake in the mainboard Config.lb. I think I have a correct one but I was busy doing porting to some other mainboard and didn't have time to test it. I will try to do it next week.
- IDE recognizing. I added "ide0=0x1f0,0x3f6,14 ide1=noprobe", but it takes about 2 secs.
The third issue is, VGA. I read the FreeVGA paper. Yes, it seems great. But such complicated technology is really necessary?
I am afraid we have to do it this way. It is probably the only way we can get VGA working without any vendor support.
For example, this guy succeeded to use normal VGA bios, although I failed. http://www.carbotpc.com/linux/index.html
I think this one uses the old "switch back to 16-bit mode and back" technology. It is actually much more complicated than an emulator.
You can try to add VGA support by yourself. Please take a look at arima/hdama and tyan/*. There is one problem you have to solve, the VGA BIOS on EPIA makes some BIOS call back to the system BIOS, you have to emulate this in the emulator (see pcibios.c).
Or, just using Xfree86 driver doesnt work?
No. The Xfree86 driver is too stupid to do a full hardware initialization.
I think that one solution is hard coding the params of mem in a BIOS image. But, how?
The documentation from VIA is simply crap. Nobody actually really know the correct value to program to the memory controller.
Sorry, My explanation was wrong. I tested many combination of M/B and DIMMs. And found most of then dont work at all, but a little of them work rarelly. I mean, some combination work but VERY unstable. For example, work once in 100 times reset.
So, My idea is, for this kind of very unstable combination, do like this. 1. add a func outputting params to console. 2. try, try, try. push reset, push reset and hope to run. 3. If it works as it happens, hard code this param to the src. 4. hope runs stably.
How about this way?
The third issue is, VGA. I read the FreeVGA paper. Yes, it seems great. But such complicated technology is really necessary?
I am afraid we have to do it this way. It is probably the only way we can get VGA working without any vendor support.
For example, this guy succeeded to use normal VGA bios, although I failed. http://www.carbotpc.com/linux/index.html
I think this one uses the old "switch back to 16-bit mode and back" technology. It is actually much more complicated than an emulator.
You can try to add VGA support by yourself. Please take a look at arima/hdama and tyan/*. There is one problem you have to solve, the VGA BIOS on EPIA makes some BIOS call back to the system BIOS, you have to emulate this in the emulator (see pcibios.c).
Umm.. Then, how about porting LX1 VGA code to LX2? In my EPIA M/B, LX1 VGA init seems to work.
--- Okajima, Jun. Tokyo, Japan.
On Sun, 2005-07-24 at 23:52 +0900, Jun OKAJIMA wrote:
I think that one solution is hard coding the params of mem in a BIOS image. But, how?
The documentation from VIA is simply crap. Nobody actually really know the correct value to program to the memory controller.
Sorry, My explanation was wrong. I tested many combination of M/B and DIMMs. And found most of then dont work at all, but a little of them work rarelly. I mean, some combination work but VERY unstable. For example, work once in 100 times reset.
So, My idea is, for this kind of very unstable combination, do like this.
- add a func outputting params to console.
- try, try, try. push reset, push reset and hope to run.
- If it works as it happens, hard code this param to the src.
- hope runs stably.
How about this way?
You can try it but the current implementation in the SVN tree is probably the best thing we can get.
The chipset is really a headache, even adding some console output in the DRAM init phase will crash the system.
If you do have a lot of time and MB/DIMM, you can try to boot with factory BIOS and compare the northbridge register value to figure out any relation between these values and the DIMM configuration.
The third issue is, VGA. I read the FreeVGA paper. Yes, it seems great. But such complicated technology is really necessary?
I am afraid we have to do it this way. It is probably the only way we can get VGA working without any vendor support.
For example, this guy succeeded to use normal VGA bios, although I failed. http://www.carbotpc.com/linux/index.html
I think this one uses the old "switch back to 16-bit mode and back" technology. It is actually much more complicated than an emulator.
You can try to add VGA support by yourself. Please take a look at arima/hdama and tyan/*. There is one problem you have to solve, the VGA BIOS on EPIA makes some BIOS call back to the system BIOS, you have to emulate this in the emulator (see pcibios.c).
Umm.. Then, how about porting LX1 VGA code to LX2? In my EPIA M/B, LX1 VGA init seems to work.
I don't think we are going to do that. The reason we are using the emulator is to eliminate the mode switch inside LB.
--- Okajima, Jun. Tokyo, Japan.
On Sun, 24 Jul 2005, Li-Ta Lo wrote:
I don't think we are going to do that. The reason we are using the emulator is to eliminate the mode switch inside LB.
the mode switch is DANGEROUS. Yes, maybe you can get one or two cards to work, but you are counting on all card BIOSes doing sane things, and many of them do not. The emulator approach is the only really safe way to bring up VGA.
Besides, it's usually much faster ...
ron
Li-Ta Lo wrote:
The documentation from VIA is simply crap. Nobody actually really know the correct value to program to the memory controller.
Are you referring to the VIA doc's here: http://www.via.com.tw/en/resources/download-center/chipsets/
or the NDA versions?
Ask VIA for the NDA versions, they are quite detailed in memory controller operation and setup. VIA has been very open with data sheets, they have even released all the specs. for the 3D graphics controllers and libraries.
-Bari
On Sun, 2005-07-24 at 12:40 -0500, Bari Ari wrote:
Li-Ta Lo wrote:
The documentation from VIA is simply crap. Nobody actually really know the correct value to program to the memory controller.
Are you referring to the VIA doc's here: http://www.via.com.tw/en/resources/download-center/chipsets/
or the NDA versions?
I think we got the NDA version (that's before I became part of the we). The documentation related to DRAM init is totally nonsense from my point of view, it just doesn't work if you program according to the spec.
Ask VIA for the NDA versions, they are quite detailed in memory controller operation and setup. VIA has been very open with data sheets, they have even released all the specs. for the 3D graphics controllers and libraries.
On Sun, 24 Jul 2005, Li-Ta Lo wrote:
I think we got the NDA version (that's before I became part of the we). The documentation related to DRAM init is totally nonsense from my point of view, it just doesn't work if you program according to the spec.
The docs I have for the 8601 were nda, are now the open docs. If you follow the docs, the chip will lock up.
ron
-
Bari Ari -
Jun OKAJIMA -
Li-Ta Lo -
Ronald G. Minnich