Hello @ all,
I have searched the MailingList for Epia, and there is another poster which have the same problem as I have.
A slow boot Epia-M, which needs about 10 seconds for the first messages over the com port.
Somebody means, it could be a problem at the northbridge, but has have no solution :(
There is a second thing in the post, which compares to me.
It seems the poster has the same RAM, as I have. Only the size differs. My RAM is a Single Sided 2100/3200 256MB with Samsung Chips.
Could the RAM the reason for the slow boot. I think the first thing to initialize is the RAM. Furthermore, the RAM is direct connected to the NB.
Chris
On 12/20/05, Christian Sühs chris@suehsi.de wrote:
A slow boot Epia-M, which needs about 10 seconds for the first messages over the com port.
Could the RAM the reason for the slow boot. I think the first thing to initialize is the RAM. Furthermore, the RAM is direct connected to the NB.
Ram dosen't make any sense. There are log messages that occur way before the RAM is initialized. What log level are you using?
-- Richard A. Smith
Ram dosen't make any sense. There are log messages that occur way before the RAM is initialized. What log level are you using?
MAXIMUM_CONSOLE_LOGLEVEL=8 DEFAULT_CONSOLE_LOGLEVEL=8
regards chris
On 12/20/05, Christian Sühs chris@suehsi.de wrote:
Ram dosen't make any sense. There are log messages that occur way before the RAM is initialized. What log level are you using?
MAXIMUM_CONSOLE_LOGLEVEL=8 DEFAULT_CONSOLE_LOGLEVEL=8
Chage it to 9. 9 is printk_spew
However I just looked at the epia-m auto.c main() and the serial port is not enabled until _after_ enable_smbus(). So something in your smbus may be hanging things up until it times out.
Try this:
in epia-m/auto.c comment out line 124, enable_smbus() and re-run. With loglevel 9 you should get the "In auto.c main()" message pretty quick. If that works then try moveing enable_smbus() to after the serial init.
If that crashes or hangs then you will have to leave it alone and debug code prior to main() and find out where its looping to cause the pause.
Look at southbridge/via/vt8235/vt8235_early_serial.c to see how to send messages out the serial port.
-- Richard A. Smith
MAXIMUM_CONSOLE_LOGLEVEL=8 DEFAULT_CONSOLE_LOGLEVEL=8
Chage it to 9. 9 is printk_spew
However I just looked at the epia-m auto.c main() and the serial port is not enabled until _after_ enable_smbus(). So something in your smbus may be hanging things up until it times out.
Try this:
in epia-m/auto.c comment out line 124, enable_smbus() and re-run. With loglevel 9 you should get the "In auto.c main()" message pretty quick. If that works then try moveing enable_smbus() to after the serial init.
If that crashes or hangs then you will have to leave it alone and debug code prior to main() and find out where its looping to cause the pause.
Ok, first I have commented out enable_smbus(), for that there are unreadable characters at the console and it takes the same time --> the false way
Then I recognized the lines above in auto.c, which disable the Firewire stuff, but The Epia-ML does not have Firewire, ok it is the same chipset and the firewire is integrated in the chip, but voila it works.
I have commented out line 119-123 and all works fine on high speed :D Is there a better way?
And now, the next problem.
It is possible to get the vesafb on boottime. Because, there is no longer a bootsplash :(
Stefan means, I need an CLE266 fb kerneldriver and it should work, but via offered a kernel modul, only
Know anybody a kernel fb driver for that chipset.
chris
* Christian Sühs chris@suehsi.de [051220 20:34]:
Then I recognized the lines above in auto.c, which disable the Firewire stuff, but The Epia-ML does not have Firewire, ok it is the same chipset and the firewire is integrated in the chip, but voila it works.
I have commented out line 119-123 and all works fine on high speed :D Is there a better way?
is this in the mainboard specific code? then we should have a new mainboard directory for the ML.
It is possible to get the vesafb on boottime. Because, there is no longer a bootsplash :(
Stefan means, I need an CLE266 fb kerneldriver and it should work, but via offered a kernel modul, only
Where can that module be found? You won't easily be able to use the vesa framebuffer, because linuxbios always sets a text mode instead of a graphics mode (and the vesafb driver does bios calls in some circumstances, at least on x86, but that can easily be patched)
LinuxBIOS should offer a way of getting the machine right into graphics mode and provide the framebuffer address and depth in the linuxbios table. ;) I say, drop text mode (as an option) and go framebuffer. This allows using two graphics cards on the bios level since we don't need to cope with concurrent mapping of legacy bios areas anymore.
Stefan
Then I recognized the lines above in auto.c, which disable the Firewire stuff, but The Epia-ML does not have Firewire, ok it is the same chipset and the firewire is integrated in the chip, but voila it works.
I have commented out line 119-123 and all works fine on high speed :D Is there a better way?
So If I get this right then the call to pci_locate_device() was causing the delay? I guess looping through every bus, dev, function searching for a device could take a while.
Probally the best thing to do is to create a mainboard/via/epia-ml directory. I bet that won't be the only thing thats different.
-- Richard A. Smith
It is possible to get the vesafb on boottime. Because, there is no longer a bootsplash :(
Stefan means, I need an CLE266 fb kerneldriver and it should work, but via offered a kernel modul, only
Where can that module be found?
The sources for CLE266 Unichrome integrated graphics
Kernel 2.4.x and 2.6.x
http://www.viaarena.com/Driver/linux-fbdev-kernel-src_20050726.tgz
There are some other sources available for different chipsets.
You won't easily be able to use the vesa
framebuffer, because linuxbios always sets a text mode instead of a graphics mode (and the vesafb driver does bios calls in some circumstances, at least on x86, but that can easily be patched)
LinuxBIOS should offer a way of getting the machine right into graphics mode and provide the framebuffer address and depth in the linuxbios table. ;) I say, drop text mode (as an option) and go framebuffer. This allows using two graphics cards on the bios level since we don't need to cope with concurrent mapping of legacy bios areas anymore.
Great idea :D
Stefan
* Christian Sühs chris@suehsi.de [051220 21:21]:
The sources for CLE266 Unichrome integrated graphics
Kernel 2.4.x and 2.6.x
http://www.viaarena.com/Driver/linux-fbdev-kernel-src_20050726.tgz
that looks like it would do it. You have to change it so it compiles into the kernel though. Not too complicated.
You'll also have to remove the explicit check for vesafb from the bootsplash code.. but that you can try once you have via-fb working..
Stefan
Richard Smith schrieb:
Then I recognized the lines above in auto.c, which disable the Firewire stuff, but The Epia-ML does not have Firewire, ok it is the same chipset and the firewire is integrated in the chip, but voila it works.
I have commented out line 119-123 and all works fine on high speed :D Is there a better way?
So If I get this right then the call to pci_locate_device() was causing the delay? I guess looping through every bus, dev, function searching for a device could take a while.
Probally the best thing to do is to create a mainboard/via/epia-ml directory. I bet that won't be the only thing thats different.
Well, problem is, that via distributed same mainboards with optional features, too.
I think the MII is the best example, you can get it, with or without CF Connector and so on
Other things are, with or without LVDS Port, FDC, Firewire and something else.
-- Richard A. Smith
-
Christian Sühs -
Richard Smith -
Stefan Reinauer