Hmm... Let me back up a step. I'm apparently answering a question you're not asking. Your problem is that you want to disable the internal video (and PCI header) and use external, right? Is that it?
-- Steve G.
Steve Goodrich (Steven.Goodrich@amd.com) Advanced Micro Devices, Inc.
-----Original Message----- From: Richard Smith [mailto:smithbone@gmail.com] Sent: Thursday, April 27, 2006 4:11 PM To: Goodrich,Steven Cc: LinuxBIOS Subject: Re: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
On 4/27/06, Goodrich,Steven steven.goodrich@amd.com wrote:
We have an older board (from before I came to be with AMD) which was
built with a GXm, CS5530, and NSC 97317 SIO. I can pull preferred register settings from a document if that would help.
Yes those would probally help..
Our preferred settings for this platform were:
BC_XMAP_1 = 0x1300C060 BC_XMAP_2 = 0x09999999 BC_XMAP_3 = 0x99****99 (* = don't care)
Or perhpaps just confuse things more. 9's in XMAP2 is PCI accessable, No Cache, No Write, Read.
I'm not sure how you would load the shadow copy of the bios into this range with write disabled . Until we started setting the write bit for these ranges the emulator was getting all 0xFFs for its data.
Are you loading an SMM handler on this platform?
Dosen't look like it. Is that a big problem? I know for the gx2 it's a big issue since it dosen't have PCI config space without it. But this part seems to have PCI config method #1 without SMM.
-- Richard A. Smith
* Goodrich,Steven steven.goodrich@amd.com [060428 01:06]:
Hmm... Let me back up a step. I'm apparently answering a question you're not asking. Your problem is that you want to disable the internal video (and PCI header) and use external, right? Is that it?
The second problem we are facing is when initializing VGA we are executing the option roms in an emulator to keep things encapsulated. When we do this in userspace, the whole process takes round about 3s whereas in LinuxBIOS the same emulator (x86emu as used in X.org) needs 90s.
Two theories: - caching of the C segment is messed up - timing is messed up
Stefan
this in userspace, the whole process takes round about 3s whereas in LinuxBIOS the same emulator (x86emu as used in X.org) needs 90s.
This is actually something that I've wanted to look at but not had the time. The emulator in LB is from the same parent as X.org but its not the same at all. Our base revision is quite old.
Yes I know we fixed a lot bugs in our tree but the fact remains that I can take the X.org setup in a multi-card, multi-head enviroment and it will post the 2nd card in almost every card I've tried. Our user space emu has nowhere near that level of success.
I think an upstream sync or at least a diff with the current emu in X.org would be a good idea. I'ts been on my list of stuff to do. But time, money.. yada yada.
-- Richard A. Smith
* Richard Smith smithbone@gmail.com [060428 17:49]:
This is actually something that I've wanted to look at but not had the time. The emulator in LB is from the same parent as X.org but its not the same at all. Our base revision is quite old.
The base revision should be 0.8 iirc, so its the latest one released from scitechsoft. (BTW, does anyone know why scitech put it to "obsolete"?)
There are some patches in our tree that are potentially missing in the X.org tree and a lot more patches are missing the other way round.
Yes I know we fixed a lot bugs in our tree but the fact remains that I can take the X.org setup in a multi-card, multi-head enviroment and it will post the 2nd card in almost every card I've tried. Our user space emu has nowhere near that level of success.
Yes, the bios emulation in our setup is absolutely minimal, most stuff is commented out. So we really only emulate the PCI interrupt 1a. No surprise lots of cards don't work that work in X..
I think an upstream sync or at least a diff with the current emu in X.org would be a good idea. I'ts been on my list of stuff to do. But time, money.. yada yada.
Yes, it has on mine, and on Egbert's (Egbert Eich from the FreeDesktop project, CCed) as well.. I already set up a development repository for that a couple of years ago, but we never got to work on that any further.
Another thing is still we should go vm86 mode instead of x86 emulation. X.org does the same and they're successful with it.
Stefan
Stefan Reinauer wrote:
Yes, the bios emulation in our setup is absolutely minimal, most stuff is commented out. So we really only emulate the PCI interrupt 1a. No surprise lots of cards don't work that work in X..
guys, what cards don't work. We had a huge stack of cards here that all worked fine.
Another thing is still we should go vm86 mode instead of x86 emulation. X.org does the same and they're successful with it.
That won't work well on a non-x86, right?
ron
Yes, the bios emulation in our setup is absolutely minimal, most stuff is commented out. So we really only emulate the PCI interrupt 1a. No surprise lots of cards don't work that work in X..
guys, what cards don't work. We had a huge stack of cards here that all worked fine.
Hmm.. Perhaps my info is out of date. I'll have to go back through my stack of cards and re-try.
-- Richard A. Smith
On Fri, 2006-04-28 at 19:26 +0200, Stefan Reinauer wrote:
Another thing is still we should go vm86 mode instead of x86 emulation. X.org does the same and they're successful with it.
Not available for K8 64-bit mode.
Li-Ta Lo wrote:
On Fri, 2006-04-28 at 19:26 +0200, Stefan Reinauer wrote:
Another thing is still we should go vm86 mode instead of x86 emulation. X.org does the same and they're successful with it.
Not available for K8 64-bit mode.
yeah, vm86 mode overall is, from my point of view, a step backwards. We chose emulation after a lot of trials with other ideas.
So, maybe X works well with lots of cards, but I need to be convinced that the problems we're seeing are real emulator problems, not hardware setup problems. I'm not convinced we know what is going on here.
ron
On 4/28/06, Ronald G Minnich rminnich@lanl.gov wrote:
So, maybe X works well with lots of cards, but I need to be convinced that the problems we're seeing are real emulator problems, not hardware setup problems. I'm not convinced we know what is going on here.
I know for a fact I don't know whats going on. *grin*
I'm not suggesting that its an emulator problem and not a configuration problem. I'm just trying to go through all the variables.
-- Richard A. Smith
There is a little question for me, is this a normal output?
Why is the run_bios_int called three times? Remember, on LB I have three calls, too. What is done after these calls. It seems that there are no differences between the second and the third one.
There is a ip (initial point) flag for testbios. Is there someting else for the inTree one.
Is testbios faster with given ip.
chris
QLC-> ./testbios --abseg /dev/mem -s 32768 aw512n.bin running file aw512n.bin No base specified. defaulting to 0xc0000 No initial code segment specified. defaulting to 0xc000 No initial instruction pointer specified. defaulting to 0x0003 updating int vector 0x10 updating int vector 0x10 updating int vector 0x42 updating int vector 0x42 updating int vector 0x43 updating int vector 0x43 updating int vector 0x1f updating int vector 0x1f updating int vector 0x1d updating int vector 0x1d updating int vector 0x1d updating int vector 0x1d updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 int10 vector at c41b4 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 run_bios_int: INT 10 CS:IP = c000:41b4 updating int vector 0x43 updating int vector 0x43 updating int vector 0x43 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 int10 vector at c41b4 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 run_bios_int: INT 10 CS:IP = c000:41b4 updating int vector 0x43 updating int vector 0x43 updating int vector 0x43 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 int10 vector at c41b4 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 updating int vector 0x10 run_bios_int: INT 10 CS:IP = c000:41b4 updating int vector 0x43 updating int vector 0x43 updating int vector 0x1d updating int vector 0x1d QLC->
Dear List!
I've managed out, the dumping from linux with the working BIOS is not a good way in this case, it reports 32kByte BIOS ROM however it's 36kbyte in the real world:) just extract it from the BIOS.
I still cannot boot, no message at all FILO loads and immediatelly restarts the system (After jumping to the entry point), Etherboot hangs. Please help!
recommend you do NO VGA until this board works. Stick with serial for now.
ron
* Christian Sühs chris@suehsi.de [060429 23:36]:
Why is the run_bios_int called three times?
Your graphics card option rom tries to output 3 lines of text, most likely. See Ralph Brown's Interrupt List on INT 10h.
It seems that there are no differences between the second and the third one.
It's the same subroutine within the graphics card option rom, yes.
There is a ip (initial point) flag for testbios. Is there someting else for the inTree one.
It's "instruction pointer".
Is testbios faster with given ip.
No, the correct IP is automatically chosen. This is only needed for non-PCI option roms. Specifying something else than the default will not even work.
Stefan
Christian Sühs wrote:
There is a little question for me, is this a normal output?
looks ok to me.
Why is the run_bios_int called three times?
the interrupt was called three times, I think. run_bios_int IIRC just means "this bios int was called, service it".
Remember, on LB I have three calls, too. What is done after these calls. It seems that there are no differences between the second and the third one.
There is a ip (initial point) flag for testbios. Is there someting else for the inTree one.
no, because PCI ROMS dictate the initial IP.
I only added that option years ago when I was still trying to figure out how this all worked.
Is testbios faster with given ip.
no.
thanks
ron
I think an upstream sync or at least a diff with the current emu in X.org would be a good idea. I'ts been on my list of stuff to do. But time, money.. yada yada.
I think it is not really hard to include the diff. I have had a look into the newer code and if I see that right, there are not so much changes.
I have also seen, that the LB inTree version differs to the X.org one. i.e. the ops2c is much smaller then the orginal. I think there are many functions, which you have commented out, right?
However, I will try it. Two file versions later, the ops.c had have a great change, to support special VGA Bioses, but I'm not sure if that will help for my problems.
First I will change all diffs to the functions, which are in the intree x86emu.
After that I try the new stuff and report what happens :D
chris.
Maybe, we are in luck. If it will work, I can try to get run the emulator on my epia m.
-- Richard A. Smith
* Christian Sühs chris@suehsi.de [060430 13:40]:
I have also seen, that the LB inTree version differs to the X.org one. i.e. the ops2c is much smaller then the orginal.
Yes, someone refactored x86emu a while ago and made it a lot smaller, so that it would easily fit into a normal size bios together with the rest of LinuxBIOS and the payload(s)
I think there are many functions, which you have commented out, right?
Only in the int callback emulation. The x86emu part itself is complete.
However, I will try it. Two file versions later, the ops.c had have a great change, to support special VGA Bioses, but I'm not sure if that will help for my problems.
Cool! It probably makes sense to use a really old version of XFree86/X.org and look at the changes rather than diffing the files 1:1..
Stefan.
Stefan Reinauer schrieb:
- Christian Sühs chris@suehsi.de [060430 13:40]:
I have also seen, that the LB inTree version differs to the X.org one.
Sorry, I have looked to the xfree86 one :D but this one has its last update 10 month ago, the X.org version seems to be older. (last update 23months)
Cool! It probably makes sense to use a really old version of XFree86/X.org and look at the changes rather than diffing the files 1:1..
Yeah, but I can't get a point to start :D I'm not sure what we need.
The inTree stuff based on X.org?
chris
Stefan.
Cool! It probably makes sense to use a really old version of XFree86/X.org and look at the changes rather than diffing the files 1:1..
Yeah, but I can't get a point to start :D I'm not sure what we need.
Now you know why I haven't done it yet. Its a little more than just a diff of the trees.
The inTree stuff based on X.org?
The in-tree stuf is based on the ./util/vgabios stuff which came from xfree86 long ago. The X.org fork should not be that much different than the xfree86 stuff. The stuff in-tree has the directory structure cleaned up so its more sane.
Rather than diff the in-tree to the X.org or xfree86 I would start by diffing the stuff in util/vgabios/x86emu first. That will let you see what has been introduced into the X* stuff. I would then fork a copy of vgabios and test all the updates. Then when you understand what changes were made you can try to roll them into the in-tree.
Speak of all this my question still stand about IO to the timer. Is this intercepted or bare metal? From what I see all IO is passed directly on to the hardware.
In V1 I had a vga bios that did not do very well with the large jump in timer reads caused by the emulator. It made the delay routine sit and spin for long periods of time. I had the source to the bios so I was able to fix it there rather than in the emulator.
The symptoms were similar to what Chris is seeing.
Chris, please disable all your current emu debug stuff and then apply this patch and send the output. This should show the timer IO accesses but not all the other stuff to keep the noise level down.
Yeah, but I can't get a point to start :D I'm not sure what we need.
Now you know why I haven't done it yet. Its a little more than just a diff of the trees.
;)
The inTree stuff based on X.org?
The in-tree stuf is based on the ./util/vgabios stuff which came from xfree86 long ago. The X.org fork should not be that much different than the xfree86 stuff. The stuff in-tree has the directory structure cleaned up so its more sane.
Yeah, the X.org version based on an older xfree86 one.
Rather than diff the in-tree to the X.org or xfree86 I would start by diffing the stuff in util/vgabios/x86emu first. That will let you see what has been introduced into the X* stuff. I would then fork a copy of vgabios and test all the updates. Then when you understand what changes were made you can try to roll them into the in-tree.
I was a little confused about some functions, which are not declared in the header files and also not present in the orginal :D However, than I have found the calls somewhere in the LB stuff :D Furthermore, it seems that somebody has changed a few diffs to the inTree version, but not all.
The rest of changes are not very interessting. i.e in ops.c all functions are static, now.
Chris, please disable all your current emu debug stuff and then apply this patch and send the output. This should show the timer IO accesses but not all the other stuff to keep the noise level down
Thanks, I will try this today.
chris
Chris, please disable all your current emu debug stuff and then apply this patch and send the output. This should show the timer IO accesses but not all the other stuff to keep the noise level down .
Sorry, but there is no more output with the applied patch.
chris
Christian Sühs schrieb:
Chris, please disable all your current emu debug stuff and then apply this patch and send the output. This should show the timer IO accesses but not all the other stuff to keep the noise level down .
Sorry, but there is no more output with the applied patch.
chris
I have forgotten to post the results for changing BC_XMAP_1 values.
BC_XMAP_2 / 3 are set to 0x77777777
first I have tried the AMD preffered values: The emulatur is entered, machine seems to hang. There is no more output after entering.
After that I have enabled the whole video RAM section A0000 - BFFFF as read/write/cache 0x07070067: I have also the long delay by vga initializing, but after upcoming there are only unreadable characters on the screen.
Now I also think, that there is a problem with the emu and my board.
chris
* Christian Sühs chris@suehsi.de [060501 13:21]:
After that I have enabled the whole video RAM section A0000 - BFFFF as read/write/cache 0x07070067:
I would assume that the video ram must not be cacheable! It doesn't get written to very much by the bios anyways (except probably the int10 calls)
I have also the long delay by vga initializing, but after upcoming there are only unreadable characters on the screen.
Yes, cacheable video memory does not work. When the CPU caches things there the VGA controller only sees half of what it is supposed to see.
S.
On 5/1/06, Christian Sühs chris@suehsi.de wrote:
Chris, please disable all your current emu debug stuff and then apply this patch and send the output. This should show the timer IO accesses but not all the other stuff to keep the noise level down .
Sorry, but there is no more output with the applied patch.
Hmmm... That seems doubtful. Did I screw up the patch somehow? If you look back through some of your debug logs do you see any IO to ports 0x40-0x43 or 0x50-53?
-- Richard A. Smith
Hmmm... That seems doubtful. Did I screw up the patch somehow? If
The patch looks ok ;)
you look back through some of your debug logs do you see any IO to ports 0x40-0x43 or 0x50-53?
I'm not sure, but I have had a run with enabled printk in sys.c
result is attached.
Currently I don't know what happens on the commented lines, but the rest is fast. Only on the commented lines it stops and takes the long delays.
after the first call on c000:4d4d about 20s after the second call on c000:4d4d about 30s, short flickering jump to c000:5506 nothing for about 40s, console comes up.
Why c000, I think it should be c0000??
chris
Furthermore there are differents to the Userspace run.
-- Richard A. Smith
copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes entering emulator c000:80 updating int vector 0x10 c000:84 updating int vector 0x10 c000:8a updating int vector 0x42 c000:90 updating int vector 0x42 c000:96 updating int vector 0x43 c000:9a updating int vector 0x43 c000:a0 updating int vector 0x1f c000:a4 updating int vector 0x1f c000:17b updating int vector 0x1d c000:181 updating int vector 0x1d c000:18d updating int vector 0x1d c000:198 updating int vector 0x1d c000:32d updating int vector 0x10 c000:32d updating int vector 0x10 found int10 vector at c41b4 // screen switched to on c000:32d updating int vector 0x10 c000:32d updating int vector 0x10 c000:32d updating int vector 0x10 c000:32d updating int vector 0x10 c000:32d updating int vector 0x10 c000:32d updating int vector 0x10 c000:4d49 updating int vector 0x43 c000:4d4d updating int vector 0x43 // after here it takes 20s to the next updating c000:5506 updating int vector 0x43 c000:144a updating int vector 0x10 c000:144a updating int vector 0x10 found int10 vector at c41b4 c000:144a updating int vector 0x10 c000:144a updating int vector 0x10 c000:144a updating int vector 0x10 c000:144a updating int vector 0x10 c000:144a updating int vector 0x10 c000:144a updating int vector 0x10 c000:4d49 updating int vector 0x43 c000:4d4d updating int vector 0x43 // after here it takes about 30s to the next updating c000:5506 updating int vector 0x43 // screen flickers short, it takes about 30s for next c000:25d updating int vector 0x10 c000:25d updating int vector 0x10 found int10 vector at c41b4 c000:25d updating int vector 0x10 c000:25d updating int vector 0x10 c000:25d updating int vector 0x10 c000:25d updating int vector 0x10 c000:25d updating int vector 0x10 c000:25d updating int vector 0x10 c000:4d49 updating int vector 0x43 c000:4d4d updating int vector 0x43 c000:4f16 updating int vector 0x1d c000:4f16 updating int vector 0x1d halt_sys: file /root/src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4392 halted PCI: 00:12.0 init cs5530: southbridge_init
I'm not sure, but I have had a run with enabled printk in sys.c
result is attached.
Comment out the if() sections on the IO and just leave the printks (enable the 32 bit IO prints as well) and send it to me. The log is generates will be huge so send it to me direct. No need to clutter the list.
Currently I don't know what happens on the commented lines, but the rest is fast. Only on the commented lines it stops and takes the long delays.
I'm going to try and match up your commented lines with what IO is happening at that time and perhaps generate a clue.
Why c000, I think it should be c0000??
No its correct.
16-bit 0xc000:0000 = 32-bit 0xc0000
-- Richard A. Smith
Comment out the if() sections on the IO and just leave the printks (enable the 32 bit IO prints as well) and send it to me. The log is generates will be huge so send it to me direct. No need to clutter the list.
No way,
with to much debug, the system hangs after a few lines. The same for the emu debug.
What is the interessting stuff? I can try one debug line for a run and merge the stuff together.
chris
On 5/1/06, Christian Sühs chris@suehsi.de wrote:
Comment out the if() sections on the IO and just leave the printks (enable the 32 bit IO prints as well) and send it to me. The log is generates will be huge so send it to me direct. No need to clutter the list.
No way,
with to much debug, the system hangs after a few lines. The same for the emu debug.
So enableing the printks causes the emulator to hang. Interesting. This seems to suggest there may be some sort of subtle timing problem. With the printks it should run painfully slow but it should not hang? printk generate IO to the serial port. I wonder if that is some how messing it up.
What happens if you change the printks into a long delay? say like udelay(1500) or udelay(3000)?
What is the interessting stuff?
Thats part of the problem. I don't know whats interesting yet.
I can try one debug line for a run and merge the stuff together.
I suppose you could use the if() blocks and just grab ranges. But when you get into the legacy vga range it will spew.
-- Richard A. Smith
So enableing the printks causes the emulator to hang. Interesting. This seems to suggest there may be some sort of subtle timing problem. With the printks it should run painfully slow but it should not hang? printk generate IO to the serial port. I wonder if that is some how messing it up.
Could it be a interrupt problem between the vga device and the serial port ?
This board is highly integrated, and after a successful boot, I have got sometimes a kernel panic with a non-syncing interrupt handler. Furthermore the vga device is located with interrupt 0 under lspci.
Ok, it is theory only :D
chris
copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes entering emulator inb(0x03cf) = 0x00 inb(0x03cf) = 0x00 inb(0x03cf) = 0x88 i
So its crashing 'inside' of a printk. 0x3cf is a VGA index register.
Could it be a interrupt problem between the vga device and the serial port ?
LinuxBIOS serial debug output is PIO. No interrupts.
Did you disable the SMI interrupt trap for access to VGA registers? That may be getting fired and tripping things up.
-- Richard A. Smith
Richard Smith wrote:
Did you disable the SMI interrupt trap for access to VGA registers? That may be getting fired and tripping things up.
Man, this is a weird one.
Disabling SMI on this thing can be touchy. Steve?
ron
On 5/2/06, Ronald G Minnich rminnich@lanl.gov wrote:
Richard Smith wrote:
Did you disable the SMI interrupt trap for access to VGA registers? That may be getting fired and tripping things up.
Man, this is a weird one.
Disabling SMI on this thing can be touchy. Steve?
I think we are ok. There is no SMM in the whole system. The GX1 actually has real PCI config space registers. And since he has an external VGA VSA isn't necessary to do any of the VGA stuff. But Steve's previous mail on _completely_ disabling the internal VGA of the cs5530 also mentioned that for an external setup some SMM trap needs to be disabled.
I just went back and re-read steve's mail:
If the F4 Video Configuration trap bit (F0, Index 42h, bit 1) is set,
the system will generate >SMIs when trying to access the PCI header registers. This should be clear for a non-SMM >system.
So he was talking about PCI acceses not generic IO accesses. Not what I was thinking.
What I was thinking of was the power mangement traps on the the IO access. But I just looked at the datasheet and they default to disabled. So unless we are turning them on I don't think they are enabled.
So its crashing 'inside' of a printk. 0x3cf is a VGA index register.
Well, I think so. Many logs looks like the one above. The first character is printed. Than nothing no more.
Man, this just smells like some sort of interrupt problem. Can we have printk do a cli() and disable all interrupts when it runs?
-- Richard A. Smith
I think we are ok. There is no SMM in the whole system. The GX1 actually has real PCI config space registers. And since he has an external VGA VSA isn't necessary to do any of the VGA stuff. But Steve's previous mail on _completely_ disabling the internal VGA of the cs5530 also mentioned that for an external setup some SMM trap needs to be disabled.
Can you have a second look to the cpu_setup section under /src/cpu/amd/model_gx1
I have read this again and again, but for me it seems there are some false writings to the registers.
However, the datasheet says, that the SMM bit can only be set, if CCR3 is 0 or the CPU is in SMI mode.
If I'm right, this bit is not correct set, doesn't matter default is 00 and so there should be no SMM.
Later CCR3 is set to 0x14 in that case there is a try to set a reserved bit. I'm not sure what happens in those case.
Also there is a third write to CCR3 0xf8 for that write the SUSP_SSM_EN bit is set to 1 whatever this means ;)
Datasheet page 50 - 56
So its crashing 'inside' of a printk. 0x3cf is a VGA index register.
Well, I think so. Many logs looks like the one above. The first character is printed. Than nothing no more.
Man, this just smells like some sort of interrupt problem. Can we have printk do a cli() and disable all interrupts when it runs?
I hope somebody has the answer.
-- Richard A. Smith
the cs5530 also mentioned that for an external setup some SMM trap needs to be disabled.
Can you have a second look to the cpu_setup section under /src/cpu/amd/model_gx1
I have read this again and again, but for me it seems there are some false writings to the registers.
However, the datasheet says, that the SMM bit can only be set, if CCR3 is 0 or the CPU is in SMI mode.
If I'm right, this bit is not correct set, doesn't matter default is 00 and so there should be no SMM.
Later CCR3 is set to 0x14 in that case there is a try to set a reserved bit. I'm not sure what happens in those case.
Also there is a third write to CCR3 0xf8 for that write the SUSP_SSM_EN bit is set to 1 whatever this means ;)
Datasheet page 50 - 56
I'll let Steve comment on all this before I try to wrap my head around it.
-- Richard A. Smith
Richard Smith schrieb:
copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes entering emulator inb(0x03cf) = 0x00 inb(0x03cf) = 0x00 inb(0x03cf) = 0x88 i
So its crashing 'inside' of a printk. 0x3cf is a VGA index register.
Well, I think so. Many logs looks like the one above. The first character is printed. Than nothing no more.
Could it be a interrupt problem between the vga device and the serial port ?
LinuxBIOS serial debug output is PIO. No interrupts.
:D Ok, ok ;)
Did you disable the SMI interrupt trap for access to VGA registers?
Good question, there is a write to the CPU config registers. It is commented with "No SMI".
That may be getting fired and tripping things up.
Fine :)
chris
Christian Sühs wrote:
Richard Smith schrieb:
copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes entering emulator inb(0x03cf) = 0x00 inb(0x03cf) = 0x00 inb(0x03cf) = 0x88 i
So its crashing 'inside' of a printk. 0x3cf is a VGA index register.
Well, I think so. Many logs looks like the one above. The first character is printed. Than nothing no more.
Is the fifo enabled on this uart? if it is, then the output can be kind of non-deterministic.
ron
Well, I think so. Many logs looks like the one above. The first character is printed. Than nothing no more.
This happens only with enabled printks.
Is the fifo enabled on this uart? if it is, then the output can be kind of non-deterministic.
Where is this done? I have a look to the superIO stuff.
chris
ron
* Christian Sühs chris@suehsi.de [060502 18:36]:
inb(0x03cf) = 0x00 inb(0x03cf) = 0x88 i
So its crashing 'inside' of a printk. 0x3cf is a VGA index register.
Well, I think so. Many logs looks like the one above. The first character is printed. Than nothing no more.
again, because I fear the thread is getting too big to get everything with full attention almost:
The hand is pretty likely caused by a race or something in the graphics card bios caused by the delays of the serial output.
So while the serial interface (which has a buffer of at least 16 bytes) is still sending at a certain baud rate, the program is already further when the machine hangs and prevents the UART FIFO to be transferred completely. This is rather common when debugging such stuff over serial.
To get back to the issues: What are we trying to solve exactly?
- the 90s delay during VGA init. - anything else?
We have a lot of good suggestions in this thread but I think we need to get focus again and go smaller steps.
Stefan
So while the serial interface (which has a buffer of at least 16 bytes) is still sending at a certain baud rate, the program is already further
I looked at the serial code and the FIFO is enabled but bypassed. The code waits for the transmit done flag after each byte and that is only set when both the FIFO and TX reg are empty.
-- Richard A. Smith
To get back to the issues: What are we trying to solve exactly?
- the 90s delay during VGA init.
- anything else?
yeah,
copying LB to RAM seems to be very slow ?! after boot, uncompressing the kernel is much slower as under factory bios.
I think the RAM is not proper init.
The filesystem is for any reason readonly after a boot?! Not under factory.
chris
* Christian Sühs chris@suehsi.de [060503 11:04]:
To get back to the issues: What are we trying to solve exactly?
- the 90s delay during VGA init.
- anything else?
copying LB to RAM seems to be very slow ?! after boot, uncompressing the kernel is much slower as under factory bios.
How many megabytes in how many seconds? is it compressed?
The filesystem is for any reason readonly after a boot?! Not under factory.
readonly root filesystem is the default. Maybe the boot parameters of your "other" boot loader contain "rw" ?
Stefan
- the 90s delay during VGA init.
- anything else?
copying LB to RAM seems to be very slow ?!
takes about 3 - 4 seconds for the 256k image
after boot, uncompressing the kernel is much slower as under factory bios.
How many megabytes in how many seconds? is it compressed?
Its done in 8 - 9 seconds. kernel is 700k big. Well, it is a bzImage and should be compressed.
The filesystem is for any reason readonly after a boot?! Not under factory.
readonly root filesystem is the default. Maybe the boot parameters of your "other" boot loader contain "rw" ?
Waaaah, yeah I have forgotten to insert "rw" parameter for the commandline in filo.
Thanks for the hint.
chris
LinuxBIOS-1.1.8.0Fallback Wed May 3 13:49:54 CEST 2006 starting... Setting up default parameters for memory Sizing memory Probing for DIMM0 Found DIMM0 Page Size: 00001000 Component Banks: 4 Module Banks: 1 DIMM size: 04000000 Probing for DIMM1 MC_BANK_CFG = 00701420 Copying LinuxBIOS to ram.
// copying is done in 3-4 seconds for 256k
Jumping to LinuxBIOS. LinuxBIOS-1.1.8.0Fallback Wed May 3 13:49:54 CEST 2006 booting... . . . Found Linux version 2.4.22 (root@linux) #11 Sat Apr 22 18:51:23 CEST 2006 bzImage. Loading kernel... ok Loading initrd... ok Jumping to entry point...
// I'm not sure, vga console says on this point "uncompressing the kernel" // is done in 8-9 seconds kernel is 700k big // under factory this is done much faster (1-2s)
Linux version 2.4.22 (root@linux) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #11 Sat Apr 22 18:51:23 CEST 2006
* Christian Sühs chris@suehsi.de [060503 14:17]:
copying LB to RAM seems to be very slow ?!
takes about 3 - 4 seconds for the 256k image
after boot, uncompressing the kernel is much slower as under factory bios.
How many megabytes in how many seconds? is it compressed?
Its done in 8 - 9 seconds. kernel is 700k big. Well, it is a bzImage and should be compressed.
Ok, all this sounds as if all memory as such is either not cacheable or cache is deactivated.
Questions to solve:
* Are there mechanisms specific to the GX1 that are not required on other systems to enable cache?
* Are the MTRRs set correctly?
* Does this occur on other GX1 boards as well, but was not detected so far?
* If yes, whats the difference to LinuxBIOSv1 here, because I seem to remember we did not have such a problem back then.
Stefan
Ok, all this sounds as if all memory as such is either not cacheable or cache is deactivated.
Questions to solve:
- Are there mechanisms specific to the GX1 that are not required on other systems to enable cache?
I'm not sure, but this cpu works for many functions not on the normal way.
- Are the MTRRs set correctly?
MTRR seems not present for this CPU
- Does this occur on other GX1 boards as well, but was not detected so far?
I don't know ;)
- If yes, whats the difference to LinuxBIOSv1 here, because I seem to remember we did not have such a problem back then.
I have catched the Kernel output for both Bioses (attachement)
There are some differents for the memory configuration.
Have a look
Stefan
// LinuxBios boot
Linux version 2.4.22 (root@linux) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #11 Sat Apr 22 18:51:23 CEST 2006 BIOS-provided physical RAM map: BIOS-e820: 0000000000000738 - 00000000000a0000 (usable) BIOS-e820: 0000000000100000 - 0000000003c00000 (usable) 60MB LOWMEM available. hm, page 00000000 reserved twice. // what does it mean On node 0 totalpages: 15360 zone(0): 4096 pages. zone(1): 11264 pages. zone(2): 0 pages. DMI not present. // Why not ? Kernel command line: ramdisk_size=13000 rw root=/dev/ram0 max_loop=16 console=tty0 console=ttyS0,115200 LABEL=FB video=vesa:ywrap,mtrr vga=0x317 splash=silent MEDIA=hd CONFIG=False Initializing CPU#0 Working around Cyrix MediaGX virtual DMA bugs. Detected 233.864 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 466.94 BogoMIPS Memory: 54912k/61440k available (919k kernel code, 6140k reserved, 258k data, 248k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) //this is a quarter as for FB Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Working around Cyrix MediaGX virtual DMA bugs. CPU: NSC Geode(TM) Integrated Processor by National Semi stepping 01 Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: none PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0 PCI: Fixup for MediaGX/Geode Slave Disconnect Boundary (0x41=0x10)
// Factory Bios boot
Linux version 2.4.22 (root@linux) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #11 Sat Apr 22 18:51:23 CEST 2006 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000004000000 (usable) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 64MB LOWMEM available. On node 0 totalpages: 16384 zone(0): 4096 pages. zone(1): 12288 pages. zone(2): 0 pages. Kernel command line: initrd=initrd.gz ramdisk_size=13000 rw root=/dev/ram0 max_loop=16 LABEL=FB splash=silent MEDIA=hd CONFIG=False BOOT_IMAGE=vmlinuz console=tty0 console=ttyS0,115200 Initializing CPU#0 Working around Cyrix MediaGX virtual DMA bugs. Detected 233.865 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 466.94 BogoMIPS Memory: 58956k/65536k available (919k kernel code, 6192k reserved, 258k data, 248k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Working around Cyrix MediaGX virtual DMA bugs. CPU: NSC Geode(TM) Integrated Processor by National Semi stepping 01 Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: none PCI: PCI BIOS revision 2.10 entry at 0xfadf0, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found
* Christian Sühs chris@suehsi.de [060503 15:21]:
- If yes, whats the difference to LinuxBIOSv1 here, because I seem to remember we did not have such a problem back then.
I have catched the Kernel output for both Bioses (attachement)
There are some differents for the memory configuration.
Ok, one thing is you can change this: #define FRAMEBUFFERK 4096 to #define FRAMEBUFFERK 0 in
src/northbridge/amd/gx1/northbridge.c. But this will do nothing but gain you the 4 Megabytes of RAM that are normally reserved for the onchip vga (which you dont use anyways)
hm, page 00000000 reserved twice. // what does it mean
good question. Anyone?
DMI not present. // Why not ?
Because its not needed. We dont do DMI but we have a mechanism called the "LinuxBIOS table"
LinuxBIOS:
PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0 PCI: Fixup for MediaGX/Geode Slave Disconnect Boundary (0x41=0x10)
factory:
PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0
... Ok. other attempt.
Boot up with LinuxBIOS and boot up with factory bios, and do
lspci -xxx > pcioutput.txt
as root. Then send the two files to this list.
Stefan
... Ok. other attempt.
Boot up with LinuxBIOS and boot up with factory bios, and do
lspci -xxx > pcioutput.txt
Ok, here are the two files.
chris
// Factory Bios
00:00.0 0600: 1078:0001 00: 78 10 01 00 07 00 80 02 00 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 1e 14 00 c1 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:09.0 0300: 10ea:5000 (rev 02) 00: ea 10 00 50 07 00 00 02 02 00 00 03 08 20 80 00 10: 00 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 80 02 00 70 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:12.0 0601: 1078:0100 00: 78 10 00 01 1f 00 80 02 00 00 01 06 04 40 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 81 50 ce 45 01 00 00 00 00 00 00 00 00 00 00 00 50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00 60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00 90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 b0: 00 00 00 00 0c 00 00 00 40 11 9c 12 00 00 00 00 c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:12.1 0680: 1078:0101 00: 78 10 01 01 02 00 80 02 00 00 80 06 00 00 00 00 10: 00 20 01 40 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00 60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00 90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 b0: 00 00 00 00 0c 00 00 00 41 20 2e 12 00 00 00 00 c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:12.2 0101: 1078:0102 00: 78 10 02 01 05 00 80 02 00 80 01 01 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00 60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00 90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 b0: 00 00 00 00 0c 00 00 00 42 04 12 12 00 00 00 00 c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:12.3 0401: 1078:0103 00: 78 10 03 01 06 00 80 02 00 00 01 04 00 00 00 00 10: 00 10 01 40 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00 60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00 90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 b0: 00 00 00 00 0c 00 00 00 43 01 00 12 00 00 00 00 c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:13.0 0c03: 0e11:a0f8 (rev 06) 00: 11 0e f8 a0 07 00 80 02 06 10 03 0c 08 20 00 00 10: 00 30 00 d2 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 11 0e f8 a0 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 50 40: 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
// LinuxBios
00:00.0 0600: 1078:0001 00: 78 10 01 00 47 01 80 83 00 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 1e 14 00 c1 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:09.0 0300: 10ea:5000 (rev 02) 00: ea 10 00 50 03 00 00 02 02 00 00 03 10 40 80 00 10: 00 00 00 fd 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 80 02 00 70 30: 00 00 fc ff 00 00 00 00 00 00 00 00 00 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:12.0 0601: 1078:0100 00: 78 10 00 01 5f 01 80 02 00 00 01 06 04 40 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 89 10 ac 03 01 00 00 00 00 00 00 00 00 00 00 00 50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 0c 00 00 00 fd 4a e9 12 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:12.1 0680: 1078:0101 00: 78 10 01 01 00 00 80 02 00 00 80 06 00 00 00 00 10: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 0c 00 00 00 fe 11 b4 12 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:12.2 0101: 1078:0102 00: 78 10 02 01 05 00 80 02 00 80 01 01 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 0c 00 00 00 ff 28 00 12 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:12.3 0401: 1078:0103 00: 78 10 03 01 00 00 80 02 00 00 01 04 00 00 00 00 10: 00 01 00 10 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 0c 00 00 00 ff 02 b0 12 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:12.4 0300: 1078:0104 00: 78 10 04 01 00 00 80 02 00 00 00 03 00 00 00 00 10: 00 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 0c 00 00 00 00 01 9c 12 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:13.0 0c03: 0e11:a0f8 (rev 06) 00: 11 0e f8 a0 42 01 80 82 06 10 03 0c 00 40 00 00 10: 00 00 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 11 0e f8 a0 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 50 40: 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
LinuxBIOS:
PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0 PCI: Fixup for MediaGX/Geode Slave Disconnect Boundary (0x41=0x10)
factory:
PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0
I have found some stuff about this fixup.
It solves a problem with master PCI transfers
without this fixup the transfer is lowered from 70MB/s to 25MB/s.
Ok, that could be solve some problems, but what about the copying and uncompressig stuff. I think there is the pci bus not affected.
However, we should try to set this bit and seen what happens.
chris
Christian Sühs wrote:
However, we should try to set this bit and seen what happens.
ok, I have set 41h in northbridge.c to 0x10 but the problems are the same as before
very slow vga ;) slow boottime
so the question is, is there a range descriptor hidden somewhere that is controlling this. There are such registers in GX2 AND SC520 AND ....
it's common in this embedded stuff. What are we missing? Where are the docs on this chip. I can try to read them.
ron
it's common in this embedded stuff. What are we missing? Where are the docs on this chip. I can try to read them.
here is the datasheet for the gx1
http://www.routerboard.com/PDF/gx1.pdf
ron
so the question is, is there a range descriptor hidden somewhere that is controlling this. There are such registers in GX2 AND SC520 AND ....
it's common in this embedded stuff. What are we missing? Where are the docs on this chip. I can try to read them.
Anybody know if the tools on the AMD developer site can read all the setup registers in the gx1 and dump them out? From looking at the data sheet a lot of the stuff we probably need to be diffing vs factory won't show up in an lspci -xxx.
-- Richard A. Smith
Richard Smith schrieb:
so the question is, is there a range descriptor hidden somewhere that is controlling this. There are such registers in GX2 AND SC520 AND ....
it's common in this embedded stuff. What are we missing? Where are the docs on this chip. I can try to read them.
Anybody know if the tools on the AMD developer site can read all the setup registers in the gx1 and dump them out? From looking at the data sheet a lot of the stuff we probably need to be diffing vs factory won't show up in an lspci -xxx.
-- Richard A. Smith
I'm not sure, did you recieve that ?
As I say. The main settings done by LB to the cpu register are ok. There is nothing, what seems to be wrong, but look here.
-// LinuxBios +// Factory Bios
00:00.0 0600: 1078:0001 -00: 78 10 01 00 47 01 80 83 00 00 00 06 00 00 00 00 +00: 78 10 01 00 07 00 80 02 00 00 00 06 00 00 00 00
^^^^^ ^^^^^ ^^^^^ ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ VID DID PCI Device default valuesPCI Command is different and Device Status differs
PCI Command (default 0007h set by factory) LB enables two additional functions for the PCI Command registers.
- Processor checks for parity errors
- SERR# enabled (is used for a special SERR driver ?!)
Device Status (default 0280h (RO) set by factory) If I understand that right, the differences here results of the enabled Parity Error checks. This register is to read out those errors and is cleard by a R/W on this register.
Check for errors means a lowered perfomance, right?? Unfortunatly, I can't find the sections in the LB Code, were this is done.
I can't find the section, were these registers are set in LB Later I found them too in the other devices on the bus, like 00:12.0
One of those is busmastering iirc.
Busmaster for the northbridge is enabled in both cases.
chris
Christian Sühs schrieb:
However, we should try to set this bit and seen what happens.
ok, I have set 41h in northbridge.c to 0x10 but the problems are the same as before
very slow vga ;) slow boottime
Oh, I forgot. The kernel fixup message is not longer shown.
chris
// I'm not sure, vga console says on this point "uncompressing the kernel" // is done in 8-9 seconds kernel is 700k big // under factory this is done much faster (1-2s)
Linux version 2.4.22 (root@linux) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #11 Sat Apr 22 18:51:23 CEST 2006
All of this slow if probally some sort of caching issue like Ron has been saying all along.
-- Richard A. Smith
Richard Smith schrieb:
// I'm not sure, vga console says on this point "uncompressing the kernel" // is done in 8-9 seconds kernel is 700k big // under factory this is done much faster (1-2s)
Linux version 2.4.22 (root@linux) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #11 Sat Apr 22 18:51:23 CEST 2006
All of this slow if probally some sort of caching issue like Ron has been saying all along.
Yeah, I have compared the whole kernel boot time for both. (after jump to entry point)
Factory bios is 15seconds faster as LB.
factory = 23s LinuxBios = 38s
chris
On Wed, 3 May 2006, Christian Sühs wrote:
- the 90s delay during VGA init.
- anything else?
copying LB to RAM seems to be very slow ?!
takes about 3 - 4 seconds for the 256k image
after boot, uncompressing the kernel is much slower as under factory bios.
How many megabytes in how many seconds? is it compressed?
Its done in 8 - 9 seconds. kernel is 700k big. Well, it is a bzImage and should be compressed.
The filesystem is for any reason readonly after a boot?! Not under factory.
readonly root filesystem is the default. Maybe the boot parameters of your "other" boot loader contain "rw" ?
Waaaah, yeah I have forgotten to insert "rw" parameter for the commandline in filo.
in linux, the root is first mounted read only. the boot process does a file system check and if no errors then remounts rw.
russ
Stefan Reinauer wrote:
- Christian Sühs chris@suehsi.de [060503 11:04]:
To get back to the issues: What are we trying to solve exactly?
- the 90s delay during VGA init.
- anything else?
copying LB to RAM seems to be very slow ?! after boot, uncompressing the kernel is much slower as under factory bios.
How many megabytes in how many seconds? is it compressed?
There is a caching, MTRR, or special register problem here. That's got to be happening.
ron
On 5/3/06, Christian Sühs chris@suehsi.de wrote:
To get back to the issues: What are we trying to solve exactly?
- the 90s delay during VGA init.
- anything else?
I'm currently trying to understand 2 issues the 90 second in-tree emu delay and why the in-tree emu dies when a long delay is inserted in between IO statements.
-- Richard A. Smith
Richard Smith schrieb:
On 5/3/06, Christian Sühs chris@suehsi.de wrote:
To get back to the issues: What are we trying to solve exactly?
- the 90s delay during VGA init.
- anything else?
I'm currently trying to understand 2 issues the 90 second in-tree emu delay and why the in-tree emu dies when a long delay is inserted in between IO statements.
We are not sure, if it dies. I havn't tried this yet. Because with udelay(250) it tooks about 5 minutes to completly init the vga.
It could be that a udelay of 500 increase this time to 10 minutes or more.
The printfs for the user space emu i.e takes a time of 500 and that for each of them. Remember I have captured 5MB of 0xff. This are I guess 300.000 lines or more, before I stopped this test. Compute this with 500us.
But I think there is no sense to test it.
Failing of the printks for the inTree emu seems to be an other problem.
chris
-- Richard A. Smith
On 5/3/06, Christian Sühs chris@suehsi.de wrote:
The printfs for the user space emu i.e takes a time of 500 and that for each of them. Remember I have captured 5MB of 0xff. This are I guess 300.000 lines or more, before I stopped this test. Compute this with 500us.
But I think there is no sense to test it.
Ah.. Ok. I understand now.
-- Richard A. Smith
* Richard Smith smithbone@gmail.com [060502 16:21]:
inb(0x03cf) = 0x00 inb(0x03cf) = 0x00 inb(0x03cf) = 0x88 i
So its crashing 'inside' of a printk. 0x3cf is a VGA index register.
coincidence. The printk is probably "long" done but the serial port did not send it all out yet. I've seen this in quite some cases.
No way,
with to much debug, the system hangs after a few lines. The same for the emu debug.
What is the interessting stuff? I can try one debug line for a run
As I say, I get only 2 - 3 lines, than it hangs :( but it should be possible to fetch the interessting IO on an other way. I will try that tomorrow.
n8
chris
and merge the stuff together.
chris
Richard Smith schrieb:
What is the interessting stuff? I can try one debug line for a run
As I say, I get only 2 - 3 lines, than it hangs :
Post up the output then.
-- Richard A. Smith
Yesterday, I have only done x_inb and x_inw here is the output for both.
first is the u8 function. No more output, nothing happens.
second the u16 function. before the system hangs for the u16 output the screen goes to ON
Now I will insert delays, for a run.
chris
copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes entering emulator inb(0x03cf) = 0x00 inb(0x03cf) = 0x00 inb(0x03cf) = 0x88 i
copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes entering emulator inw(0x03ce) = 0x0157 inw(0x03c4) = 0x0001 i
Now I will insert delays, for a run.
Ok, first I have insert one udelay(1500) call for the u8 function. the system gets the first int10 vector and the screen switches to ON. After that nor more happens.
Than I have insert delay(1500) for all u8-u32 functions. The result is the same as before, the first int10 vector switches the screen ON.
as I say, the problem is after the first int10 and between the second and third call.
chris
On 5/2/06, Christian Sühs chris@suehsi.de wrote:
as I say, the problem is after the first int10 and between the second and third call.
Thats much later than when it hangs with a printk right?
Try decreasing the delay until you find the smallest delay that does not hang.
-- Richard A. Smith
Richard Smith schrieb:
On 5/2/06, Christian Sühs chris@suehsi.de wrote:
as I say, the problem is after the first int10 and between the second and third call.
Thats much later than when it hangs with a printk right?
Sure, If I remember right, I have never seen an int10 vector before the system hangs with printk.
Try decreasing the delay until you find the smallest delay that does not hang.
Ok, I will try 500, if that runs 1000 and so on.
chris
-- Richard A. Smith
Try decreasing the delay until you find the smallest delay that does not hang.
Ok, I will try 500, if that runs 1000 and so on.
udelay(250) for all functions work. But VGA needs 3-4 minutes to come up ;)
Before, I have had a run with 500, but it seems I havn't wait long enough. :D I'm not sure but I think 500 should work to in 7-8 minutes.
chris
On 5/2/06, Christian Sühs chris@suehsi.de wrote:
udelay(250) for all functions work. But VGA needs 3-4 minutes to come up ;)
That seems to suggest that it is some sort of time thing. Both printk and udelay do similar IO operations. A couple of writes to set things up and then loads of reads waiting on it to happen.
Its not dying due to the fact that there is additional IO happening or you should have been able to get down to udelay(0) and it still hang.
Man.. like Ron says this is wierd..
So how can we get more debug info out of this system? Our primary debug method dies.
You can run this under the user mode emulator with the IO prints enabled it works right?
Can you do that and look at what IO its doing when it starts up?. Probally don't need more than the first 50 lines or so. Maybe we can exclude printing on IO port ranges that cause problems.
All I want to see it how it accesses the timer. Add my original if(port < 0x53) stuff to the usermode emu and send that to me as well.
-- Richard A. Smith
So how can we get more debug info out of this system? Our primary debug method dies.
You can run this under the user mode emulator with the IO prints enabled it works right?
It don't work :D
I can't believe that, whit enabled orginal printfs it don't work. Whit disabled ones it work normally.
the output is attached. I have tried it twice, under LB and factory Bios.
now I will do a run with your patch. But I think I get no output.
chris
Can you do that and look at what IO its doing when it starts up?. Probally don't need more than the first 50 lines or so. Maybe we can exclude printing on IO port ranges that cause problems.
./testbios -s 32768 --abseg /dev/mem aw512n.bin -d 0x48 running file aw512n.bin No base specified. defaulting to 0xc0000 No initial code segment specified. defaulting to 0xc000 No initial instruction pointer specified. defaulting to 0x0003 Loading ax with BusDevFn = 48 updating int vector 0x10 updating int vector 0x10 updating int vector 0x42 updating int vector 0x42 updating int vector 0x43 updating int vector 0x43 updating int vector 0x1f updating int vector 0x1f outb(0x18, 0x46e8) outb(0x01, 0x0102) outb(0x08, 0x46e8) outw(0x04f8, 0x03ce) outw(0x00fb, 0x03ce) outw(0x80bb, 0x03ce) outw(0x80ba, 0x03ce) outw(0x52b2, 0x03ce) outw(0x50b3, 0x03ce) outb(0xb9, 0x03ce) inb(0x03cf) = 0xff outw(0xffb9, 0x03ce) outw(0x7fb9, 0x03ce) outb(0x70, 0x03ce) inb(0x03cf) = 0xff outw(0x1b70, 0x03ce) outw(0xa871, 0x03ce) outw(0x80b5, 0x03ce) outb(0xbe, 0x03ce) inb(0x03cf) = 0xff outw(0x7fbe, 0x03ce) outw(0x8097, 0x03ce) outw(0x031f, 0x03d4) outw(0x0157, 0x03ce) inw(0x03ce) = 0xffff outw(0x0057, 0x03ce) outw(0x0100, 0x03c4) outw(0x0001, 0x03c4) outw(0x0302, 0x03c4) outw(0x0003, 0x03c4) outw(0x0204, 0x03c4) outb(0x01, 0x03c4) inw(0x03c4) = 0xffff outw(0xffff, 0x03c4) outb(0x67, 0x03c2) outw(0x0300, 0x03c4) outb(0x11, 0x03d4) inb(0x03d5) = 0xff outw(0x7f11, 0x03d4) outw(0x5f00, 0x03d4) outw(0x4f01, 0x03d4) outw(0x5002, 0x03d4) outw(0x8203, 0x03d4) outw(0x5504, 0x03d4) outw(0x8105, 0x03d4) outw(0xbf06, 0x03d4) outw(0x1f07, 0x03d4) outw(0x0008, 0x03d4) outw(0x4f09, 0x03d4) outw(0x0d0a, 0x03d4) outw(0x0e0b, 0x03d4) outw(0x000c, 0x03d4) outw(0x000d, 0x03d4) outw(0x000e, 0x03d4) outw(0x000f, 0x03d4) outw(0x9c10, 0x03d4) outw(0x8e11, 0x03d4) outw(0x8f12, 0x03d4) outw(0x2813, 0x03d4) outw(0x1f14, 0x03d4) outw(0x9615, 0x03d4) outw(0xb916, 0x03d4) outw(0xa317, 0x03d4) outw(0xff18, 0x03d4) inb(0x03da) = 0xff outb(0x00, 0x03c0) outb(0x00, 0x03c0) outb(0x01, 0x03c0) outb(0x01, 0x03c0) outb(0x02, 0x03c0) outb(0x02, 0x03c0) outb(0x03, 0x03c0) outb(0x03, 0x03c0) outb(0x04, 0x03c0) outb(0x04, 0x03c0) outb(0x05, 0x03c0) outb(0x05, 0x03c0) outb(0x06, 0x03c0) outb(0x14, 0x03c0) outb(0x07, 0x03c0) outb(0x07, 0x03c0) outb(0x08, 0x03c0) outb(0x38, 0x03c0) outb(0x09, 0x03c0) outb(0x39, 0x03c0) outb(0x0a, 0x03c0) outb(0x3a, 0x03c0) outb(0x0b, 0x03c0) outb(0x3b, 0x03c0) outb(0x0c, 0x03c0) outb(0x3c, 0x03c0) outb(0x0d, 0x03c0) outb(0x3d, 0x03c0) outb(0x0e, 0x03c0) outb(0x3e, 0x03c0) outb(0x0f, 0x03c0) outb(0x3f, 0x03c0) outb(0x10, 0x03c0) outb(0x0c, 0x03c0) outb(0x11, 0x03c0) outb(0x00, 0x03c0) outb(0x12, 0x03c0) outb(0x0f, 0x03c0) outb(0x13, 0x03c0) outb(0x08, 0x03c0) outb(0x14, 0x03c0) outb(0x00, 0x03c0) outw(0x0000, 0x03ce) outw(0x0001, 0x03ce) outw(0x0002, 0x03ce) outw(0x0003, 0x03ce) outw(0x0004, 0x03ce) outw(0x1005, 0x03ce) outw(0x0e06, 0x03ce) outw(0x0007, 0x03ce) outw(0xff08, 0x03ce) outw(0x0010, 0x03ce) outw(0x0011, 0x03ce) outw(0x0014, 0x03ce) outw(0x0015, 0x03ce) outw(0x0031, 0x03ce) outw(0x0032, 0x03ce) outw(0x0033, 0x03ce) outw(0x0056, 0x03ce) outw(0x0058, 0x03ce) outw(0x0059, 0x03ce) outw(0x005a, 0x03ce) outw(0x0057, 0x03ce) outw(0x0077, 0x03ce) outw(0x003c, 0x03ce) outw(0x205c, 0x03ce) outb(0x90, 0x03ce) inb(0x03cf) = 0xff outw(0xfe90, 0x03ce) outb(0x72, 0x03ce) inw(0x03ce) = 0xffff outw(0xb7ff, 0x03ce) outb(0x56, 0x03ce) inw(0x03ce) = 0xffff outw(0x0456, 0x03ce) inb(0x03c6) = 0xff outb(0xed, 0x03c6) outw(0xffff, 0x03ce) outb(0x73, 0x03ce) inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff inb(0x0080) = 0x92 inb(0x03cf) = 0xff outb(0x01, 0x03c4) inw(0x03c4) = 0xffff outw(0xdfff, 0x03c4) outw(0x0100, 0x03c4) outw(0x0300, 0x03c4) outw(0x0012, 0x03ce) outw(0x0016, 0x03ce) outw(0x0050, 0x03ce) outw(0x0051, 0x03ce) outw(0x0052, 0x03ce) outw(0x0053, 0x03ce) outw(0x0054, 0x03ce) outw(0x0055, 0x03ce) outw(0x3073, 0x03ce) outw(0x1b74, 0x03ce) outw(0x1e75, 0x03ce) outw(0x0076, 0x03ce) outw(0x0078, 0x03ce) outw(0x3079, 0x03ce) outw(0xc87a, 0x03ce) outw(0x01bf, 0x03ce) inb(0x03da) = 0xff inb(0x03da) = 0xff inb(0x03da) = 0xff inb(0x03da) = 0xff
// after her always the same inb line
* Christian Sühs chris@suehsi.de [060502 21:07]:
outw(0x0052, 0x03ce) outw(0x0053, 0x03ce) outw(0x0054, 0x03ce) outw(0x0055, 0x03ce) outw(0x3073, 0x03ce) outw(0x1b74, 0x03ce) outw(0x1e75, 0x03ce) outw(0x0076, 0x03ce) outw(0x0078, 0x03ce) outw(0x3079, 0x03ce) outw(0xc87a, 0x03ce) outw(0x01bf, 0x03ce)
thats the graphics index register
inb(0x03da) = 0xff inb(0x03da) = 0xff inb(0x03da) = 0xff inb(0x03da) = 0xff
// after her always the same inb line
it waits for a vertical blank interrupt which never happens. At this point it probably expects the video to become light.
Stefan
outw(0x3079, 0x03ce) outw(0xc87a, 0x03ce) outw(0x01bf, 0x03ce)
thats the graphics index register
inb(0x03da) = 0xff inb(0x03da) = 0xff inb(0x03da) = 0xff inb(0x03da) = 0xff
// after her always the same inb line
it waits for a vertical blank interrupt which never happens. At this point it probably expects the video to become light.
ok, this is a wrong log, but for the right logs it is the same. There is the delay after the first int10 at c000:xxxxx with the same output.
And yes, after the first run_bios_int the screen switches from standby to on.
But what means never happens? It happens after 20s without debug under LB or immediatly without debug under testbios. After that it takes the second run with longer delay.
What causes the vertical blank interrupt?
chris
Stefan
* Christian Sühs chris@suehsi.de [060502 23:12]:
inb(0x03da) = 0xff inb(0x03da) = 0xff inb(0x03da) = 0xff inb(0x03da) = 0xff
// after her always the same inb line
it waits for a vertical blank interrupt which never happens. At this point it probably expects the video to become light.
But what means never happens? It happens after 20s without debug under LB or immediatly without debug under testbios. After that it takes the second run with longer delay.
Ah, sorry, I thought when you enable the output of inb(0x03da) = 0xff it would not come to an end but print always the same inb line.
So it works when you enable above debug and wait long enough?
What causes the vertical blank interrupt?
When the ray moves from the end of the screen to the beginning there's a time frame which can safely be used to update the screen without any flickering, thats the vertical blank. Its actually not an interrupt because in above example the bios polls for that event rather than getting an interrupt when its there.
When the ray moves from the end of the screen to the beginning there's a time frame which can safely be used to update the screen without any flickering, thats the vertical blank. Its actually not an interrupt because in above example the bios polls for that event rather than getting an interrupt when its there.
Is that bit latched or is it a direct indication of the state of the CRTC. If its not latched then due to the reduced speed of the emulator we could miss the bit. But that dosen't really explain why the in-tree has the 90 second and the usermode dosen't.
Could the size compression on the in tree emu affect the speed that much?
-- Richard A. Smith
Ah, sorry, I thought when you enable the output of inb(0x03da) = 0xff it would not come to an end but print always the same inb line.
I'm not sure, as I say. Yesterday I have wait about one cigarette length and captured 5MB of (0x03da) = 0xff ;) before stopping the test. But the screen comes not completly up.
But think about the udelay(xxx) tests with the inTree emu, with a time of 250 for each function and I guess the inb function is called most, I have to wait about 5 minutes for a complete initialization.
I think the printf stuff takes a longer time ( like 500us) that means that a whole run takes for example 10 minutes or longer.
So it works when you enable above debug and wait long enough?
It could, but I don't know it. I will try it again and wait longer without capturing the output.
chris
On 5/3/06, Christian Sühs chris@suehsi.de wrote:
I'm not sure, as I say. Yesterday I have wait about one cigarette length and captured 5MB of (0x03da) = 0xff ;) before stopping the test. But the screen comes not completly up.
So you sent me that log? If you did then resend and give it a different subject.
I think the printf stuff takes a longer time ( like 500us) that means that a whole run takes for example 10 minutes or longer.
The printk stuff will take 87us per character sent. With the strings we are sending that works out to about 1.1 mS. Thats why I wanted to start with udelay(1500) as a replacement.
So it works when you enable above debug and wait long enough?
It could, but I don't know it. I will try it again and wait longer without capturing the output.
I missed the result of this test.
-- Richard A. Smith
how about we take a different approach here. How big is your flash?
ron
Ronald G Minnich schrieb:
how about we take a different approach here. How big is your flash?
ron
256k. I will have a look for a greater one in my boxes.
chris
Ok,
with your help, currently I get almost the same bootloog as under factory bios. The main initializing of the board, seems to be ok.
But you know, that there are two big problems for me and the board.
First:
The whole boottime is slow. Lb is 15s slower as the factory bios in kernel booting.
1. copying LB to RAM seems slow. 2. copying kernel and intitrd.gz to RAM seems slow 3. uncompressing kernel seems slow.
All operations to or in RAM seems to be 3 times slower as under factory.
Second: VGA initialization is very very slow ;)
I have compared all register settings for the CPU with the datasheet. For me the settings are ok. The RAM is detected right. CPU is set with the right values.
The only thing I can't see, are the settings for the refresh cycles and clock stuff for the RAM?! I will try to debug these settings.
Richard, Ron and Stefan means, that there are problems with the caching stuff.
However, currently I think there is a problem with the internal X-Bus or Memory refresh settings.
I hope somebody have an answer for this problems.
Also there is one last question for me. lspci shows no interrupts for the vga and usb device, both are set to 0. How can I set them. I this done with the irq_table?
chris
However, currently I think there is a problem with the internal X-Bus or Memory refresh settings.
detected memory seetings are also ok.
chris
* Christian Sühs chris@suehsi.de [060504 14:09]:
However, currently I think there is a problem with the internal X-Bus or Memory refresh settings.
detected memory seetings are also ok.
north bridge configuration is pretty much the same.
I would check the 5530/5535 sheets for the differences below..
-// LinuxBios +// Factory Bios
00:00.0 0600: 1078:0001 -00: 78 10 01 00 47 01 80 83 00 00 00 06 00 00 00 00 +00: 78 10 01 00 07 00 80 02 00 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
One of those is busmastering iirc.
wheras the "Kahlua Legacy" is very different..
00:12.0 0601: 1078:0100 -00: 78 10 00 01 5f 01 80 02 00 00 01 06 04 40 80 00 +00: 78 10 00 01 1f 00 80 02 00 00 01 06 04 40 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -40: 89 10 ac 03 01 00 00 00 00 00 00 00 00 00 00 00 +40: 81 50 ce 45 01 00 00 00 00 00 00 00 00 00 00 00 -50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00 +50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00 -60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00 -90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00 -a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 -b0: 00 00 00 00 0c 00 00 00 fd 4a e9 12 00 00 00 00 +b0: 00 00 00 00 0c 00 00 00 40 11 9c 12 00 00 00 00 -c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
So is the SMI configuration:
00:12.2 0101: 1078:0102 00: 78 10 02 01 05 00 80 02 00 80 01 01 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -20: 01 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +20: 01 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00 +50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00 -60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00 -90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00 -a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 -b0: 00 00 00 00 0c 00 00 00 ff 28 00 12 00 00 00 00 +b0: 00 00 00 00 0c 00 00 00 42 04 12 12 00 00 00 00 -c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
wheras the "Kahlua Legacy" is very different..
00:12.0 0601: 1078:0100 -00: 78 10 00 01 5f 01 80 02 00 00 01 06 04 40 80 00 +00: 78 10 00 01 1f 00 80 02 00 00 01 06 04 40 80 00
^^^^^
PCI Command register (default 000Fh) Factory bios adds here Memory write and Invalidate for the 5530 LB enables additional Parity check and SERR as for the gx1. Could be that this is done automatically, besides the settings before to the gx1
rest are default values
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -40: 89 10 ac 03 01 00 00 00 00 00 00 00 00 00 00 00 +40: 81 50 ce 45 01 00 00 00 00 00 00 00 00 00 00 00
^^ ^^ ^^ ^^ LB uses default for index 40 (89h) Factory disables the PCI slave write buffer
LB uses default for index 41 (10h) Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)
42 ( default ACh) usb settings
LB uses default for index 43 (03h) Factory disables PCI retry cycles and set a special PIN configuration bit.
rest is default
-50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00 +50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00
PIT / ISA CLK / ISA ROM
-60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^^ is reserved
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00
Power Managment Purpose/IRQ/Video/VGA timer
-90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00 -a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 -b0: 00 00 00 00 0c 00 00 00 fd 4a e9 12 00 00 00 00 +b0: 00 00 00 00 0c 00 00 00 40 11 9c 12 00 00 00 00
user defined Pin settings and and and
-c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Christian Sühs wrote:
wheras the "Kahlua Legacy" is very different..
00:12.0 0601: 1078:0100 -00: 78 10 00 01 5f 01 80 02 00 00 01 06 04 40 80 00 +00: 78 10 00 01 1f 00 80 02 00 00 01 06 04 40 80 00
^^^^^PCI Command register (default 000Fh) Factory bios adds here Memory write and Invalidate for the 5530 LB enables additional Parity check and SERR as for the gx1. Could be that this is done automatically, besides the settings before to the gx1
rest are default values
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -40: 89 10 ac 03 01 00 00 00 00 00 00 00 00 00 00 00 +40: 81 50 ce 45 01 00 00 00 00 00 00 00 00 00 00 00
^^ ^^ ^^ ^^LB uses default for index 40 (89h) Factory disables the PCI slave write buffer
LB uses default for index 41 (10h) Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)
oh boy. I HOPE we don't need the SMI support just to run the IDE hardware! we didn't need this before on GX1.
ron
* Ronald G Minnich rminnich@lanl.gov [060505 15:16]:
LB uses default for index 41 (10h) Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)
oh boy. I HOPE we don't need the SMI support just to run the IDE hardware! we didn't need this before on GX1.
I bet they use that to implement memory mapped ide flash or something like that..
One second... Could we do bios based transparent hard disk encryption this way? That would be kind of cool ;-))
Stefan
Stefan Reinauer wrote:
- Ronald G Minnich rminnich@lanl.gov [060505 15:16]:
LB uses default for index 41 (10h) Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)
oh boy. I HOPE we don't need the SMI support just to run the IDE hardware! we didn't need this before on GX1.
I bet they use that to implement memory mapped ide flash or something like that..
One second... Could we do bios based transparent hard disk encryption this way? That would be kind of cool ;-))
Stefan
I am told that this type of thing might go into EFI. You don't get direct access to your disk. Looking at the EFI docs, it seems you could do it ... you no longer get access to raw hardware. OW!
ron
* Ronald G Minnich rminnich@lanl.gov [060505 15:31]:
One second... Could we do bios based transparent hard disk encryption this way? That would be kind of cool ;-))
Stefan
I am told that this type of thing might go into EFI. You don't get direct access to your disk. Looking at the EFI docs, it seems you could do it ... you no longer get access to raw hardware. OW!
With Vanderpool and Pacifica this should be fairly easy.
The fact that stuff like this is possible (maybe even with SMI) is not the scary part. The scary part is we might never get control over any piece of hardware again.
Talking about EFI, has anyone been able to get into the UEFI group as announced on the LinuxBIOS summit last year?
Stefan
Stefan Reinauer schrieb:
- Ronald G Minnich rminnich@lanl.gov [060505 15:31]:
One second... Could we do bios based transparent hard disk encryption this way? That would be kind of cool ;-))
I am told that this type of thing might go into EFI. You don't get direct access to your disk. Looking at the EFI docs, it seems you could do it ... you no longer get access to raw hardware. OW!
With Vanderpool and Pacifica this should be fairly easy.
The fact that stuff like this is possible (maybe even with SMI) is not the scary part. The scary part is we might never get control over any piece of hardware again.
But LinuxBIOS would suddenly become a lot more attractive if it was the only way to get real access to the hardware. Unless somebody decides to run that scary software below LinuxBIOS. I believe with BIOS-embedded-in- chipset like the Xbox has we really might be stuck.
Regards, Carl-Daniel
Stefan Reinauer wrote:
Talking about EFI, has anyone been able to get into the UEFI group as announced on the LinuxBIOS summit last year?
I've talked to UEFI about this. I think the fact is that most UEFI participants are not that interested in seeing an open source UEFI. I don't know if they're opposed, but I don't think they see any reason for it.
AMD is, of course, one of the exceptions.
Look at the vendors and you can see why they might not care about open source BIOSes.
ron
^^ ^^ ^^ ^^LB uses default for index 40 (89h) Factory disables the PCI slave write buffer
LB uses default for index 41 (10h) Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)
oh boy. I HOPE we don't need the SMI support just to run the IDE hardware! we didn't need this before on GX1.
IDE works fine, a little bit slower as under factory. What about the parity checks, could that be the reason for lowered performance for the whole system ?
chris
ron
Christian Sühs wrote:
IDE works fine, a little bit slower as under factory. What about the parity checks, could that be the reason for lowered performance for the whole system ?
I doubt it. I still think there is a memory control register somewhere that is not set right, so caching is not happening.
I have been able in the past to use lmbench memory diags to locate this type of thing. I realize you have done an awful lot, but could we ask you to do one more thing? lmbench under factory and under linuxbios? If caching is not happening, it will be very obvious under lmbench.
thanks
ron
First:
The whole boottime is slow. Lb is 15s slower as the factory bios in kernel booting.
- copying LB to RAM seems slow.
- copying kernel and intitrd.gz to RAM seems slow
- uncompressing kernel seems slow.
All operations to or in RAM seems to be 3 times slower as under factory.
Can somebody have a look to the gx1 datasheet on page 42 - 50.
I'm not sure, but CR0 (Control Register 0) is set to 60000010h after a hardware reset. That means, that the 16K L1 Cache is disabled !?
I can't see any code in LB which enables L1 cache on cpu init.
Could somebody compare this.
chris
On Mon, May 08, 2006 at 07:27:07PM +0200, Christian Sühs wrote:
Can somebody have a look to the gx1 datasheet on page 42 - 50.
I'm not sure, but CR0 (Control Register 0) is set to 60000010h after a hardware reset. That means, that the 16K L1 Cache is disabled !?
Yep.
I can't see any code in LB which enables L1 cache on cpu init.
Could somebody compare this.
Hmm.
--8<-- include/cpu/x86/cache.h static inline void enable_cache(void) { unsigned long cr0; cr0 = read_cr0(); cr0 &= 0x9fffffff; write_cr0(cr0); } -->8--
--8<-- cpu/x86/cache/cache.c void x86_enable_cache(void) { post_code(0x60); printk_info("Enabling cache\n"); enable_cache(); } -->8--
--8<-- cpu/amd/model_gx1/model_gx1_init.c static void model_gx1_init(device_t dev) { #if 0 gx1_cpu_setup(); gx1_gx_setup(); #endif /* Turn on caching if we haven't already */ x86_enable_cache();
/* Enable the local cpu apics */ setup_lapic(); };
..
static struct device_operations cpu_dev_ops = { .init = model_gx1_init, };
-->8--
--8<-- cpu/amd/model_gx1/Config.lb dir /cpu/x86/cache driver model_gx1_init.o -->8--
--8<-- Message-ID: 43A551D8.5060208@suehsi.de (Dec 2005) Initializing CPU #0 CPU: vendor Centaur device 698 Enabling cache -->8--
That email is the only one I found from you to the list where Enabling cache occurs. Check your serial output to see if it's still there, as it should be.
//Peter
Peter Stuge schrieb:
On Mon, May 08, 2006 at 07:27:07PM +0200, Christian Sühs wrote:
Can somebody have a look to the gx1 datasheet on page 42 - 50.
I'm not sure, but CR0 (Control Register 0) is set to 60000010h after a hardware reset. That means, that the 16K L1 Cache is disabled !?
Yep.
I can't see any code in LB which enables L1 cache on cpu init.
Could somebody compare this.
Hmm.
--8<-- include/cpu/x86/cache.h static inline void enable_cache(void) { unsigned long cr0; cr0 = read_cr0(); cr0 &= 0x9fffffff; write_cr0(cr0); } -->8--
Well, I have seen that code, but what about the registers. Is cache enabling a standard x86 prozedur?
--8<-- cpu/amd/model_gx1/Config.lb dir /cpu/x86/cache driver model_gx1_init.o -->8--
--8<-- Message-ID: 43A551D8.5060208@suehsi.de (Dec 2005) Initializing CPU #0 CPU: vendor Centaur device 698 Enabling cache
That is my epia M Board ;) Currently we talk about MB3036 from Allwell.
-->8--
That email is the only one I found from you to the list where Enabling cache occurs. Check your serial output to see if it's still there, as it should be.
Ok, I will have a look. thanks
chris
//Peter
Enabling cache occurs. Check your serial output to see if it's still there, as it should be.
Ok, I will have a look. thanks
Enable Caching is debugged with printk_info. Therefore it should shown under LogLevel 8
But I can't see this stuff in the current log file. Furthermore, I have never seen this message :(
What happens here?!
What could be the reasons for failing?
chris
ÿ
LinuxBIOS-1.1.8.0Fallback Wed May 10 05:57:02 CEST 2006 starting... Setting up default parameters for memory MC_MEM_CNTRL1 = 92162000 Sizing memory Probing for DIMM0 Found DIMM0 Page Size: 00001000 Component Banks: 4 Module Banks: 1 DIMM size: 04000000 Probing for DIMM1 MC_BANK_CFG = 00701420 MC_MEM_CNTRL1 = 92162000 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8.0Fallback Wed May 10 05:57:02 CEST 2006 booting... end 61ae1378, start 0 32-bit delta 346 calibrate_tsc 32-bit result is 346 clocks_per_usec: 346 Enumerating buses... scan_static_bus for Root Device Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [1078/0001] ops PCI: 00:00.0 [1078/0001] enabled PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: 00:09.0 [10ea/5000] enabled PCI: devfn 0x49, bad id 0xffffffff PCI: devfn 0x4a, bad id 0xffffffff PCI: devfn 0x4b, bad id 0xffffffff PCI: devfn 0x4c, bad id 0xffffffff PCI: devfn 0x4d, bad id 0xffffffff PCI: devfn 0x4e, bad id 0xffffffff PCI: devfn 0x4f, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: 00:12.0 [1078/0100] bus ops southbridge_enable: dev is 00021b00 PCI: 00:12.0 [1078/0100] enabled PCI: 00:12.1 [1078/0101] disabled PCI: 00:12.2 [1078/0102] ops cs5530_ide: ide_enable PCI: 00:12.2 [1078/0102] enabled PCI: 00:12.3 [1078/0103] disabled PCI: 00:12.4 [1078/0104] disabled PCI: devfn 0x95, bad id 0xffffffff PCI: devfn 0x96, bad id 0xffffffff PCI: devfn 0x97, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0002a000 malloc 0x0002a000 PCI: 00:13.0 [0e11/a0f8] enabled PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff scan_static_bus for PCI: 00:12.0 PNP: 002e.0 enabled PNP: 002e.1 enabled PNP: 002e.2 enabled PNP: 002e.3 disabled PNP: 002e.4 enabled PNP: 002e.5 enabled PNP: 002e.6 enabled PNP: 002e.7 enabled PNP: 002e.8 enabled scan_static_bus for PCI: 00:12.0 done PCI: pci_scan_bus returning with max=00 scan_static_bus for Root Device done done Allocating resources... Reading resources... Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 northbridge.c:pci_domain_read_resources() PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:12.2 20 * [0x00000400 - 0x0000047f] io Root Device compute_allocate_io: base: 00000480 size: 00000080 align: 7 gran: 0 done Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:09.0 10 * [0x00000000 - 0x00ffffff] mem PCI: 00:13.0 10 * [0x01000000 - 0x01000fff] mem Root Device compute_allocate_mem: base: 01001000 size: 01001000 align: 24 gran: 0 done Done reading resources. Allocating VGA resource PCI: 00:09.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000080 align: 7 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:12.2 20 * [0x00001000 - 0x0000107f] io Root Device compute_allocate_io: base: 00001080 size: 00000080 align: 7 gran: 0 done Root Device compute_allocate_mem: base: fd000000 size: 01001000 align: 24 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:09.0 10 * [0xfd000000 - 0xfdffffff] mem PCI: 00:13.0 10 * [0xfe000000 - 0xfe000fff] mem Root Device compute_allocate_mem: base: fe001000 size: 01001000 align: 24 gran: 0 done Root Device assign_resources, bus 0 link: 0 BC_DRAM_TOP = 0x03ffffff MC_GBASE_ADD = 0x00000080 I would set ram size to 64 Mbytes PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:09.0 10 <- [0x00fd000000 - 0x00fdffffff] mem PCI: 00:09.0 30 <- [0x00fffc0000 - 0x00fffcffff] romem PCI: 00:12.2 20 <- [0x0000001000 - 0x000000107f] io PCI: 00:13.0 10 <- [0x00fe000000 - 0x00fe000fff] mem PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 cmd <- 147 PCI: 00:09.0 subsystem <- 00/00 PCI: 00:09.0 cmd <- 143 cs5530.c: cs5530_pci_dev_enable_resources() PCI: 00:12.0 cmd <- 14f PCI: 00:12.2 cmd <- 141 PCI: 00:13.0 cmd <- 142 done. Initializing devices... Root Device init PCI: 00:00.0 init northbridge: northbridge_init() PCI: 00:09.0 init rom address for PCI: 00:09.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x0031 PCI ROM Image, Vendor 10ea, Device 5000, PCI ROM Image, Class Code 030000, Code Type 00 copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes entering emulator found int10 vector at c41b4 found int10 vector at c41b4 found int10 vector at c41b4 halt_sys: file /root/src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4392 halted PCI: 00:12.0 init cs5530: southbridge_init PNP: 002e.0 init PNP: 002e.1 init PNP: 002e.2 init PNP: 002e.4 init PNP: 002e.5 init PNP: 002e.6 init PNP: 002e.7 init PNP: 002e.8 init PCI: 00:12.2 init cs5530_ide: ide_init PCI: 00:13.0 init Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 done. Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 000006c4 checksum 372e
Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3
looking at these graphs, it sort of looks like what I used to see when l1 was on, but L2 is off. factory has two bumps: one at 16k, and one at 256k.
linuxbios has a huge bump at 16k. But the results look incomplete. I have 3 graphs for factory and only one for linuxbios.
can we get all the graphs in the series? I am comparing factory2.ps and lb2.ps
ron
Enable Caching is debugged with printk_info. Therefore it should shown under LogLevel 8
But I can't see this stuff in the current log file. Furthermore, I have never seen this message :(
There is also no CPU init. Mmmmh, how is this done.
gx1_cpu_setup and gx1_gx_setup is done, because I'm able to change the BC_* registers and the other stuff.
but it seems, that the x86_enable_cache function is not called.
Sorry, currently I don't understand this.
What happens here?!
What could be the reasons for failing?
chris
but it seems, that the x86_enable_cache function is not called.
Sorry, currently I don't understand this.
What happens here?!
What could be the reasons for failing?
What about the Config.lb under the mainboard folder. Most Boards enables the apic cluster, the eaglelion/5bcm does not.
I think all devices should be init, which are set to on in the Config file.
However, the CPU is not init by LB and therefor there is no L1 cache. Can somebody have a second look to the eaglelion Config.lb under the mainboard folder. The file could be wrong.
Also it seems that the cpus normally enabled at last on other boards like the epia-m. Enabling first should be better.
chris
What about the Config.lb under the mainboard folder. Most Boards enables the apic cluster, the eaglelion/5bcm does not.
Do you have an apic?
I think all devices should be init, which are set to on in the Config file.
However, the CPU is not init by LB and therefor there is no L1 cache. Can somebody have a second look to the eaglelion Config.lb under the mainboard folder. The file could be wrong.
What boards are you comparing against?
I haven't had a chance to look at the registers you listed for the CPU datasheet. But my suggestion would be to just try them and see what happens.
-- Richard A. Smith
Richard Smith schrieb:
What about the Config.lb under the mainboard folder. Most Boards enables the apic cluster, the eaglelion/5bcm does not.
Do you have an apic?
Well I don't think so ;)
I'm not really sure what this is, i.e in the epia-m Config.lb is it enabled too, has/is the epia-m an apic?
Means apic, some boards get together in a cluster ??
I think all devices should be init, which are set to on in the Config file.
However, the CPU is not init by LB and therefor there is no L1 cache. Can somebody have a second look to the eaglelion Config.lb under the mainboard folder. The file could be wrong.
What boards are you comparing against?
It seems that almost any board has enabled apic in the Config.lb
I haven't had a chance to look at the registers you listed for the CPU datasheet. But my suggestion would be to just try them and see what happens.
Yeah, I have tried these and that, but nothing helps. Currently I think that the GX1 L1 cache is disabled. Because it seems that the CPU is not init by LinuxBios on startup.
Last, I don't know how I should set those special cpu registers.
chris
-- Richard A. Smith
Yeah, I have tried these and that, but nothing helps. Currently I think that the GX1 L1 cache is disabled. Because it seems that the CPU is not init by LinuxBios on startup.
Well, CPU is init in early state by the two *.inc files under model_gx1, but the L1 cache should be enabled later by the init prozedur, but this function is never called.
Question is, how can I set the L1 cache in early state, means set the necassary registers. Or how can I solve the not called init section for the gx1.
chris
Question is, how can I set the L1 cache in early state, means set the necassary registers.
I'm a bit bandwith restricted at the moment so I can't offer a whole lot of help..
There should be some examples of setting CPU registers in the CPU init code.
Or how can I solve the not called init section for the gx1.
Which init function is not being called and what C file is it in?
-- Richard A. Smith
Richard Smith schrieb:
Question is, how can I set the L1 cache in early state, means set the necassary registers.
I'm a bit bandwith restricted at the moment so I can't offer a whole lot of help..
:D
There should be some examples of setting CPU registers in the CPU init code.
Problem is, I couldn't find the indexes of this registers in the datasheet.
Or how can I solve the not called init section for the gx1.
Which init function is not being called and what C file is it in?
under src/cpu/amd/model_gx1 are three files: cpu_setup.inc; gx_setup.inc and model_gx1_init.c
First I have thought, that all stuff is done by the C file, but later I have recognized that the other two files initialize the cpu in early state, short after or before the RAM init is done.
The C file does exactly the same, but there are the init functions, which are not called.
If I understand these mess right, normally this function is called by device operations. i.e initializing. But these happens on enabled devices, only. cpu_dev_ops seems to be a special case.
However, the function model_gx1_init() is never called for some reason. Therefor, x86_enable_cache is not called, too.
The northbridge.c file under src/northbridge/amd/gx1 has a similiar init function, it calls the initialize_cpus() function which later calls the cpu_initialize function. But this never happens, too.
The captured serial logs have not any debug lines about cpu initializing.
chris
-- Richard A. Smith
On 5/9/06, Christian Sühs chris@suehsi.de wrote:
If I understand these mess right, normally this function is called by device operations. i.e initializing. But these happens on enabled devices, only. cpu_dev_ops seems to be a special case.
Its a maze of little passages linked only by function pointers.
But I think you are correct. I don't think x86_enable_cache() is getting called.
If you look at the northbridge.c for the gx1 you will see that initialize_cpus() is called by cpu_bus_init() which is in the cpu_bus_ops struct. But cpu_bus_ops only gets installed as the init handler in enable_dev() if the device is marked as DEVICE_PATH_APIC_CLUSTER. Looking in the static.c that my tree generates for the 5bcm I see that the gx1 northbridge is marked as DEVICE_PATH_PCI_DOMAIN which will cause the .init handler to be 0.
Apply the following patch to your tree and run in spew debug mode. This will show if initialize_cpus() is getting called or not. Perhaps its getting called by some other path that I don't see.
You can also try adding x86_enable_cache() into the northbridge_init() function but you will probally need to include the cpu/x86/cache.h file and perhaps some other header files.
-- Richard A. Smith
If you look at the northbridge.c for the gx1 you will see that initialize_cpus() is called by cpu_bus_init() which is in the cpu_bus_ops struct. But cpu_bus_ops only gets installed as the init handler in enable_dev() if the device is marked as DEVICE_PATH_APIC_CLUSTER. Looking in the static.c that my tree generates for the 5bcm I see that the gx1 northbridge is marked as DEVICE_PATH_PCI_DOMAIN which will cause the .init handler to be 0.
Apply the following patch to your tree and run in spew debug mode. This will show if initialize_cpus() is getting called or not. Perhaps its getting called by some other path that I don't see.
Thanks for the patch, here is the result.
initialize_cpus() is not called.
Currently I used an other Config.lb therefor the northbridge is init not as first. However I will modify the Config.lb back and try it again, but I think the result is the nearly the same ;)
Doesn't matter. I think the best way is to init the cpu in early state and set the registers for L1 caching before LB does the other stuff. It should be much faster as now.
chris
þ
LinuxBIOS-1.1.8.0Fallback Wed May 10 09:29:09 CEST 2006 starting... Setting up default parameters for memory Sizing memory Probing for DIMM0 Found DIMM0 Page Size: 00001000 Component Banks: 4 Module Banks: 1 DIMM size: 04000000 Probing for DIMM1 MC_BANK_CFG = 00701420 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8.0Fallback Wed May 10 09:29:09 CEST 2006 booting... end 654203d6, start 0 32-bit delta 346 calibrate_tsc 32-bit result is 346 clocks_per_usec: 346 Enumerating buses... scan_static_bus for Root Device northbridge.c:enable_dev() DEVICE_PATH_PCI_DOMAIN Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 0 malloc Enter, size 668, free_mem_ptr 0002a000 malloc 0x0002a000 PCI: 00:00.0 [1078/0001] ops PCI: 00:00.0 [1078/0001] enabled PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: 00:09.0 [10ea/5000] enabled PCI: devfn 0x49, bad id 0xffffffff PCI: devfn 0x4a, bad id 0xffffffff PCI: devfn 0x4b, bad id 0xffffffff PCI: devfn 0x4c, bad id 0xffffffff PCI: devfn 0x4d, bad id 0xffffffff PCI: devfn 0x4e, bad id 0xffffffff PCI: devfn 0x4f, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: 00:12.0 [1078/0100] bus ops southbridge_enable: dev is 00021920 PCI: 00:12.0 [1078/0100] enabled PCI: 00:12.1 [1078/0101] disabled PCI: 00:12.2 [1078/0102] ops cs5530_ide: ide_enable PCI: 00:12.2 [1078/0102] enabled PCI: 00:12.3 [1078/0103] disabled PCI: 00:12.4 [1078/0104] disabled PCI: devfn 0x95, bad id 0xffffffff PCI: devfn 0x96, bad id 0xffffffff PCI: devfn 0x97, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0002a29c malloc 0x0002a29c PCI: 00:13.0 [0e11/a0f8] enabled PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff scan_static_bus for PCI: 00:12.0 PNP: 002e.0 enabled PNP: 002e.1 enabled PNP: 002e.2 enabled PNP: 002e.3 disabled PNP: 002e.4 enabled PNP: 002e.5 enabled PNP: 002e.6 enabled PNP: 002e.7 enabled PNP: 002e.8 enabled scan_static_bus for PCI: 00:12.0 done PCI: pci_scan_bus returning with max=00 scan_static_bus for Root Device done done Allocating resources... Reading resources... Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 northbridge.c:pci_domain_read_resources() PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:12.2 20 * [0x00000400 - 0x0000047f] io Root Device compute_allocate_io: base: 00000480 size: 00000080 align: 7 gran: 0 done Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:09.0 10 * [0x00000000 - 0x00ffffff] mem PCI: 00:13.0 10 * [0x01000000 - 0x01000fff] mem Root Device compute_allocate_mem: base: 01001000 size: 01001000 align: 24 gran: 0 done Done reading resources. Allocating VGA resource PCI: 00:09.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000080 align: 7 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:12.2 20 * [0x00001000 - 0x0000107f] io Root Device compute_allocate_io: base: 00001080 size: 00000080 align: 7 gran: 0 done Root Device compute_allocate_mem: base: fd000000 size: 01001000 align: 24 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:09.0 10 * [0xfd000000 - 0xfdffffff] mem PCI: 00:13.0 10 * [0xfe000000 - 0xfe000fff] mem Root Device compute_allocate_mem: base: fe001000 size: 01001000 align: 24 gran: 0 done Root Device assign_resources, bus 0 link: 0 BC_DRAM_TOP = 0x03ffffff MC_GBASE_ADD = 0x00000080 I would set ram size to 64 Mbytes PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:09.0 10 <- [0x00fd000000 - 0x00fdffffff] mem PCI: 00:09.0 30 <- [0x00fffc0000 - 0x00fffcffff] romem PCI: 00:12.2 20 <- [0x0000001000 - 0x000000107f] io PCI: 00:13.0 10 <- [0x00fe000000 - 0x00fe000fff] mem PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 cmd <- 147 PCI: 00:09.0 subsystem <- 00/00 PCI: 00:09.0 cmd <- 143 cs5530.c: cs5530_pci_dev_enable_resources() PCI: 00:12.0 cmd <- 14f PCI: 00:12.2 cmd <- 141 PCI: 00:13.0 cmd <- 142 done. Initializing devices... Root Device init PCI: 00:09.0 init rom address for PCI: 00:09.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x0031 PCI ROM Image, Vendor 10ea, Device 5000, PCI ROM Image, Class Code 030000, Code Type 00 copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes entering emulator found int10 vector at c41b4 found int10 vector at c41b4 found int10 vector at c41b4 halt_sys: file /root/src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4392 halted PCI: 00:12.0 init cs5530: southbridge_init PNP: 002e.0 init PNP: 002e.1 init PNP: 002e.2 init PNP: 002e.4 init PNP: 002e.5 init PNP: 002e.6 init PNP: 002e.7 init PNP: 002e.8 init PCI: 00:12.2 init cs5530_ide: ide_init PCI: 00:00.0 init northbridge: northbridge_init() PCI: 00:13.0 init Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 done. Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 000006c4 checksum 2d24
Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3
Currently I used an other Config.lb therefor the northbridge is init not as first. However I will modify the Config.lb back and try it again, but I think the result is the nearly the same ;)
Ok, here is the second result with the old Config.lb the different is, that here is the device 0.0 is set to on after the PCI_DOMAIN 0 is set on.
Now it seems there are to calls to the dev_enable() function in the northbridge.c
chris
LinuxBIOS-1.1.8.0Fallback Wed May 10 10:50:45 CEST 2006 starting... Setting up default parameters for memory Sizing memory Probing for DIMM0 Found DIMM0 Page Size: 00001000 Component Banks: 4 Module Banks: 1 DIMM size: 04000000 Probing for DIMM1 MC_BANK_CFG = 00701420 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8.0Fallback Wed May 10 10:50:45 CEST 2006 booting... end 759a5d6e, start 0 32-bit delta 349 calibrate_tsc 32-bit result is 349 clocks_per_usec: 349 Enumerating buses... scan_static_bus for Root Device northbridge.c:enable_dev() DEVICE_PATH_PCI_DOMAIN Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 0 northbridge.c:enable_dev() device path type 2 PCI: 00:00.0 [1078/0001] ops PCI: 00:00.0 [1078/0001] enabled PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: 00:09.0 [10ea/5000] enabled PCI: devfn 0x49, bad id 0xffffffff PCI: devfn 0x4a, bad id 0xffffffff PCI: devfn 0x4b, bad id 0xffffffff PCI: devfn 0x4c, bad id 0xffffffff PCI: devfn 0x4d, bad id 0xffffffff PCI: devfn 0x4e, bad id 0xffffffff PCI: devfn 0x4f, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: 00:12.0 [1078/0100] bus ops southbridge_enable: dev is 00021bc0 PCI: 00:12.0 [1078/0100] enabled PCI: 00:12.1 [1078/0101] disabled PCI: 00:12.2 [1078/0102] ops cs5530_ide: ide_enable PCI: 00:12.2 [1078/0102] enabled PCI: 00:12.3 [1078/0103] disabled PCI: 00:12.4 [1078/0104] disabled PCI: devfn 0x95, bad id 0xffffffff PCI: devfn 0x96, bad id 0xffffffff PCI: devfn 0x97, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0002a000 malloc 0x0002a000 PCI: 00:13.0 [0e11/a0f8] enabled PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff scan_static_bus for PCI: 00:12.0 PNP: 002e.0 enabled PNP: 002e.1 enabled PNP: 002e.2 enabled PNP: 002e.3 disabled PNP: 002e.4 enabled PNP: 002e.5 enabled PNP: 002e.6 enabled PNP: 002e.7 enabled PNP: 002e.8 enabled scan_static_bus for PCI: 00:12.0 done PCI: pci_scan_bus returning with max=00 scan_static_bus for Root Device done done Allocating resources... Reading resources... Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 northbridge.c:pci_domain_read_resources() PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:12.2 20 * [0x00000400 - 0x0000047f] io Root Device compute_allocate_io: base: 00000480 size: 00000080 align: 7 gran: 0 done Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:09.0 10 * [0x00000000 - 0x00ffffff] mem PCI: 00:13.0 10 * [0x01000000 - 0x01000fff] mem Root Device compute_allocate_mem: base: 01001000 size: 01001000 align: 24 gran: 0 done Done reading resources. Allocating VGA resource PCI: 00:09.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000080 align: 7 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:12.2 20 * [0x00001000 - 0x0000107f] io Root Device compute_allocate_io: base: 00001080 size: 00000080 align: 7 gran: 0 done Root Device compute_allocate_mem: base: fd000000 size: 01001000 align: 24 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:09.0 10 * [0xfd000000 - 0xfdffffff] mem PCI: 00:13.0 10 * [0xfe000000 - 0xfe000fff] mem Root Device compute_allocate_mem: base: fe001000 size: 01001000 align: 24 gran: 0 done Root Device assign_resources, bus 0 link: 0 BC_DRAM_TOP = 0x03ffffff MC_GBASE_ADD = 0x00000080 I would set ram size to 64 Mbytes PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:09.0 10 <- [0x00fd000000 - 0x00fdffffff] mem PCI: 00:09.0 30 <- [0x00fffc0000 - 0x00fffcffff] romem PCI: 00:12.2 20 <- [0x0000001000 - 0x000000107f] io PCI: 00:13.0 10 <- [0x00fe000000 - 0x00fe000fff] mem PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 cmd <- 147 PCI: 00:09.0 subsystem <- 00/00 PCI: 00:09.0 cmd <- 143 cs5530.c: cs5530_pci_dev_enable_resources() PCI: 00:12.0 cmd <- 14f PCI: 00:12.2 cmd <- 141 PCI: 00:13.0 cmd <- 142 done. Initializing devices... Root Device init PCI: 00:00.0 init northbridge: northbridge_init() PCI: 00:09.0 init rom address for PCI: 00:09.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x0031 PCI ROM Image, Vendor 10ea, Device 5000, PCI ROM Image, Class Code 030000, Code Type 00 copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes entering emulator found int10 vector at c41b4 found int10 vector at c41b4 found int10 vector at c41b4 halt_sys: file /root/src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4392 halted PCI: 00:12.0 init cs5530: southbridge_init PNP: 002e.0 init PNP: 002e.1 init PNP: 002e.2 init PNP: 002e.4 init PNP: 002e.5 init PNP: 002e.6 init PNP: 002e.7 init PNP: 002e.8 init PCI: 00:12.2 init cs5530_ide: ide_init PCI: 00:13.0 init Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 done. Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 000006c4 checksum 3b32
Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3
Doesn't matter. I think the best way is to init the cpu in early state and set the registers for L1 caching before LB does the other stuff. It should be much faster as now.
Try the attached patch and see if it helps
-- Richard A. Smith
Try the attached patch and see if it helps
shit, that didn't work. Now the RAM is not proper detected and LB fails on start by jumping to.
should it be addl or andl, 0x9fffffff ??
However I have tried both and for both cases it fails.
I think is it not possible to easy write to cr0, I will try the patch later in the code after enabling these registers.
chris
-- Richard A. Smit h
On Wed, May 10, 2006 at 07:04:14PM +0200, Christian Sühs wrote:
should it be addl or andl, 0x9fffffff ??
andl, intent is to clear bits 2,1 in the top nibble.
However I have tried both and for both cases it fails.
I think is it not possible to easy write to cr0, I will try the patch later in the code after enabling these registers.
Hmm, cr0 should always be available..
//Peter
Peter Stuge schrieb:
On Wed, May 10, 2006 at 07:04:14PM +0200, Christian Sühs wrote:
should it be addl or andl, 0x9fffffff ??
andl, intent is to clear bits 2,1 in the top nibble.
However I have tried both and for both cases it fails.
I think is it not possible to easy write to cr0, I will try the patch later in the code after enabling these registers.
Hmm, cr0 should always be available..
//Peter
Could be the patch wrong?
In cache.h the enable_cache function looks different.
there is a "asm volatile" for read/write operation. movl %%cr0, %0 movl %0, %%cr0
I mean the double "%%"
chris
there is a "asm volatile" for read/write operation. movl %%cr0, %0 movl %0, %%cr0
I mean the double "%%"
Thats because it's used in a .c file. I did it in straight assembly in an .inc file
-- Richard A. Smith
On 5/10/06, Christian Sühs chris@suehsi.de wrote:
Try the attached patch and see if it helps
shit, that didn't work. Now the RAM is not proper detected and LB fails on start by jumping to.
After I sent that I wondered to myself what that would do. That enables the cache before the RAM is initialized. Thats probally the reason that its not done that way already.
Ok so here's a new northbridge.c patch reverse the previous one and apply. This will call cache_enable() in northbridge_init().
Its a hack but should be ok for our test.
-- Richard A. Smith
Its a hack but should be ok for our test.
Woooooooooooow, LB boots like a rocket ;)
Ok, now it is much faster as before. The vga initialization is done in ca. 9s. copying initrd and the kernel and also uncompressing the kernel is like under factory bios.
The only thing which is slow, is to copy LB in the RAM.
The perfect sulotion seems to be enabling the L1 cache in the early state of LB.
9s for vga is not fast, but I think we would find the reason for that. if there is any.
chris
-- Richard A. Smit h
The perfect sulotion seems to be enabling the L1 cache in the early state of LB.
9s for vga is not fast, but I think we would find the reason for that. if there is any.
Ok, There are a few questions for me exspecially for the cr0 register.
as I say default is 60000010h
for that default the CPU is in real Mode. If I understand that right, it is a 16bit machine ?!
More, in the Config.lb under the motherboard folder is following line in the Setup RAM Section.
mainboardint cpu/x86/fpu/enable_fpu.inc
that file does something on register cr0, but for the GX1 in cr0 is nothing about fpu?!
question:
what do this line
andl $~(1<<2), %eax /* found in enable_fpu.inc */
can anybody explain this in easy words ;) which bits are set in that case.
chris
* Christian Sühs chris@suehsi.de [060511 14:51]:
Ok, There are a few questions for me exspecially for the cr0 register.
as I say default is 60000010h
for that default the CPU is in real Mode. If I understand that right, it is a 16bit machine ?!
yes, the x86 architecture is a drilled 16bit architecture with 32bit and nowadays 64bit plugged on top. When the CPU is powered on, it still comes up in 16bit mode.
One of the many delicacies of LinuxBIOS is that it enters protected mode (32bit mode) after only 17(!) CPU instructions.
mainboardint cpu/x86/fpu/enable_fpu.inc
This enables the FPU so the romcc generated code can use the FPU registers for spilling.
that file does something on register cr0, but for the GX1 in cr0 is nothing about fpu?!
I would assume it is there anyways, or the FPU is always enabled for the GX1?
andl $~(1<<2), %eax /* found in enable_fpu.inc */
this clears bit 1.
1<<2 is the value with only bit 2 set. The decimal value is 4
$~(x) inverts the value of x, so the result is a value with all bits set except bit 2.
the and operator sets all bits in eax that are - already set in eax - set in the value you provide so since only 1 bit is cleared in the value, the expression clears that one bit in eax.
can anybody explain this in easy words ;) which bits are set in that case.
in easy words: none. bit 2 is cleared though.
To set bits you would OR/ORL them into a value. Rather simple bitwise arithmetics.
set bit 5:
orl $(1<<5), %eax
NOTE: bits are counted from 0 here. So bit 2 is the third least significant bit.
Hoe this helps..
Stefan
One of the many delicacies of LinuxBIOS is that it enters protected mode (32bit mode) after only 17(!) CPU instructions.
Ok, were is it done in LB is entering protected mode a standard procedur of LB.
I.e. the GX1 have to set bit 0 on CR0 to 1
that file does something on register cr0, but for the GX1 in cr0 is nothing about fpu?!
I would assume it is there anyways, or the FPU is always enabled for the GX1?
Maybe, I have to read the datasheet for FPU
can anybody explain this in easy words ;) which bits are set in that case.
in easy words: none. bit 2 is cleared though.
Thanks for the leson ;)
Ok, for the GX1 the EM is set to 0; Emulate Processor Extension, if EM = 1 all flaoting point instructions causes a DNA fault 7
Seems that the FPU is always enabled.
chris
Stefan
Christian Sühs schrieb:
One of the many delicacies of LinuxBIOS is that it enters protected mode (32bit mode) after only 17(!) CPU instructions.
Ok, were is it done in LB is entering protected mode a standard procedur of LB.
I.e. the GX1 have to set bit 0 on CR0 to 1
Oh, I have found that stuff :D And I'm confused now.
It seems, I have to write my own entry16.inc code for the gx1. The default entry16.inc should enable the cache for example, but there are written false values to the cr0 register.
in easy words: none. bit 2 is cleared though.
Thanks for the leson ;)
Ok, for the GX1 the EM is set to 0; Emulate Processor Extension, if EM = 1 all flaoting point instructions causes a DNA fault 7
This is done twice for the gx1. First in entry16.inc Later with enable_fpu.inc
Is it posible to remove the line from the Config.lb for the fpu?
chris
* Christian Sühs chris@suehsi.de [060511 15:54]:
It seems, I have to write my own entry16.inc code for the gx1. The default entry16.inc should enable the cache for example, but there are written false values to the cr0 register.
no. very very unlikely. Just write the correct values in auto.c is enough.
Ok, for the GX1 the EM is set to 0; Emulate Processor Extension, if EM = 1 all flaoting point instructions causes a DNA fault 7
This is done twice for the gx1. First in entry16.inc Later with enable_fpu.inc
Is it posible to remove the line from the Config.lb for the fpu?
Possibly possible, if the gx1 does all that.. But this will not take more than a couple cycles, so the difference in size and time is not measurable without quite some effort.
Stefan Reinauer schrieb:
- Christian Sühs chris@suehsi.de [060511 15:54]:
It seems, I have to write my own entry16.inc code for the gx1. The default entry16.inc should enable the cache for example, but there are written false values to the cr0 register.
no. very very unlikely. Just write the correct values in auto.c is enough.
Ok, ok ;)
now I have start with own folders for allwell/stb3036 under targets and mainboard.
Is there a recommended way to use/call own functions/files under LB.
Because, I have to had change settings for the cpu/amd/model_gx1 and others. You know, enabling the cache and so on.
But I think i.e enabling memory segments for vga support and so on is a good think for everybody :D
What about the emu support, is this rewritten to use any RAM?
Is it posible to remove the line from the Config.lb for the fpu?
Possibly possible, if the gx1 does all that.. But this will not take more than a couple cycles, so the difference in size and time is not measurable without quite some effort.
Yup ;)
chris
now I have start with own folders for allwell/stb3036 under targets and mainboard.
Is there a recommended way to use/call own functions/files under LB.
I don't really understand what you are trying to do?
Because, I have to had change settings for the cpu/amd/model_gx1 and others. You know, enabling the cache and so on.
That was just a hack. What really need to happen is to figure out how to make the northbridge code properly call initialize_cpus().
But I think i.e enabling memory segments for vga support and so on is a good think for everybody :D
Not really. The cluster people don't care about VGA.
What about the emu support, is this rewritten to use any RAM?
I've not seen any commit for this. Ron did you talk to ollie on this?
Richard Smith schrieb:
now I have start with own folders for allwell/stb3036 under targets and mainboard.
Is there a recommended way to use/call own functions/files under LB.
I don't really understand what you are trying to do?
Because of the differences to the eaglelion/5bcm I have create own folders for mainboard and target in the LB tree called allwell/stb3036 and allwell/stb1036 also changed some files to get proper Vendor and ID strings. So now I can make a ./buildtarget under targets to get a image for that mobo.
Because, I have to had change settings for the cpu/amd/model_gx1 and others. You know, enabling the cache and so on.
That was just a hack. What really need to happen is to figure out how to make the northbridge code properly call initialize_cpus().
I'm not sure, if we need that. because the model_gx1_init.c does the same as the cpu_setup.inc in early state to initialize the cpu.
There is only the cache_enable stuff which is not called. but as I say it would be better to do that earlier. I think that also the LB copying to RAM is faster than.
Stefan talked about the auto.c, with the new own folders, that is the only file I can touch without to make changes in the standard trees.
But I think i.e enabling memory segments for vga support and so on is a good think for everybody :D
Not really. The cluster people don't care about VGA.
Well, with own Config.lb everybody can decide to enable vga or not. I need a way, to change cpu registers for the gx1, that all people are happy. Currently you have to enable c0000 writeable/cacheable for vga support.
Means, if CONSOLE_VGA = 1 make changes to the CPU registers BC_XMAP_2 and so on.
chris
I have created my own irq_tables.c file with getpir.
But there are the same problems as with the old eaglelion/5bcm one. The only device which gets an irq is a PCI Network card.
The onboard devices (VGA; USB; Audio) gets IRQ 0 under linux. Is that normal ?
Is it possible to assign IRQs with the Config.lb file like the superIO devices?
chris
* Christian Sühs chris@suehsi.de [060516 14:39]:
I have created my own irq_tables.c file with getpir.
pirq tables of factory bios are very often incomplete or wrong. One reason is that pirq and mptable are not used by the OS when ACPI is active. (Well, talking Linux) So this is an untested (and usually unused) path.
But there are the same problems as with the old eaglelion/5bcm one. The only device which gets an irq is a PCI Network card.
The onboard devices (VGA; USB; Audio) gets IRQ 0 under linux. Is that normal ?
USB should get an IRQ, audio as well, probably. Don't think you need one for VGA? What does your factory bios say?
Is it possible to assign IRQs with the Config.lb file like the superIO devices?
Nope. you have to write support in form of mptable, pirq or ACPI to get this working.
Stefan Reinauer schrieb:
- Christian Sühs chris@suehsi.de [060516 14:39]:
I have created my own irq_tables.c file with getpir.
pirq tables of factory bios are very often incomplete or wrong. One reason is that pirq and mptable are not used by the OS when ACPI is active. (Well, talking Linux) So this is an untested (and usually unused) path.
ACPI is not enabled in the kernel. What about the bios parameters? There is a switch to enable/disable for pnp os intalled. Eventually there are differences if I run getpir in both cases? Or should I set the IRQs manually in the bios before I run getpir.
USB should get an IRQ, audio as well, probably. Don't think you need one for VGA? What does your factory bios say?
All devices gets an IRQ.
Nope. you have to write support in form of mptable, pirq or ACPI to get this working.
* Christian Sühs chris@suehsi.de [060516 16:54]:
pirq tables of factory bios are very often incomplete or wrong. One reason is that pirq and mptable are not used by the OS when ACPI is active. (Well, talking Linux) So this is an untested (and usually unused) path.
ACPI is not enabled in the kernel. What about the bios parameters? There is a switch to enable/disable for pnp os intalled. Eventually there are differences if I run getpir in both cases? Or should I set the IRQs manually in the bios before I run getpir.
Look at the hardware and write a valid pirq table.. getpir is a nice tool but it starts out by utilizing a broken piece of software, the factory bios. One entry in the pirq table for each device that gets an interrupt and for each pci slot is needed.
Most factory bios versions explicitly allocate interrupts for the existing hardware by writing to the PCI registers.
LinuxBIOS does not do that, but instead provides the information to have Linux do that.
If the interrupts are already initialized by the bios, a broken pirq table is not all too bad, except that its good for nothing except forcing the kernel into certain code paths (no joke)
Stefan
Look at the hardware and write a valid pirq table.. getpir is a nice tool but it starts out by utilizing a broken piece of software, the factory bios. One entry in the pirq table for each device that gets an interrupt and for each pci slot is needed.
Is it safe to comment not used devices i.e. the created irq table by getpir shows a line for device 8, but there is currently no device, the same for some other currently not used devices.
Also the exclusive PCI IRQs are set to 10 and 11. The Board has a combi PCI/ISA extension Slot. Can I add some IRQs like 5 and 9.
Next Question:
Device where the interrupt router lies is set to (0x12<<3)|0x00
the first seems to be wrong (0:16.0) 0x00 is the better choice. I thing "|" means "OR" I'm right?
chris
* Christian Sühs chris@suehsi.de [060516 18:54]:
Is it safe to comment not used devices i.e. the created irq table by getpir shows a line for device 8, but there is currently no device, the same for some other currently not used devices.
Yes, most likely you can just remove that entry. This might be entries for PCI slots though, so a problem might only occur when you plug in a PCI card..
Also the exclusive PCI IRQs are set to 10 and 11. The Board has a combi PCI/ISA extension Slot. Can I add some IRQs like 5 and 9.
might work, might not. This depends of many things for example on how the mainboard is wired.
Device where the interrupt router lies is set to (0x12<<3)|0x00
the first seems to be wrong (0:16.0) 0x00 is the better choice. I thing "|" means "OR" I'm right?
yes, | is OR.
You should change the device position.
NOTE: 0:16.0 might be 0x16 or 16 (0x10) - you need to find to make it work right. lspci shows hex values - this confused me quite some time when we did the opteron port..
Not necessarily the device ID though, since Linux might not support the actually used interrupt router. I think on K8 boards the IRQ router device and vendor id is still set to the k7 interrupt router (it was in the past) because the two devices were compatible and linux did only know the older part.
Stefan
Device where the interrupt router lies is set to (0x12<<3)|0x00
the first seems to be wrong (0:16.0) 0x00 is the better choice. I thing "|" means "OR" I'm right?
uups,
I think my KCalc is on the woodway ;) it says 0x12<<3 is 90h that is 10010000b
the upper five bits are the device.
1 0 0 1 0 0 0 0 ------------------ 16 8 4 2 1
should be 18 in decimal
yes, | is OR.
You should change the device position.
NOTE: 0:16.0 might be 0x16 or 16 (0x10) - you need to find to make it work right. lspci shows hex values - this confused me quite some time when we did the opteron port..
Ok, lspci shows hex. What about cat /proc/pci? Is this decimal? I will have a look with cat, because I remember that cat /proc/pci shows different device numbers.
Not necessarily the device ID though, since Linux might not support the actually used interrupt router. I think on K8 boards the IRQ router device and vendor id is still set to the k7 interrupt router (it was in the past) because the two devices were compatible and linux did only know the older part.
It seems that linux knows that router,
+++ PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0 +++
in hex.
Stefan
Christian Sühs wrote:
Is it safe to comment not used devices i.e. the created irq table by getpir shows a line for device 8, but there is currently no device, the same for some other currently not used devices.
are you sure that's not the pci slot (is there one)?
if there really are impossible devices that is a sure sign that your $PIR is bogus.
ron
the first seems to be wrong (0:16.0) 0x00 is the better choice. I thing "|" means "OR" I'm right?
bitwise or, yes.
ron
Ronald G Minnich schrieb:
Christian Sühs wrote:
Is it safe to comment not used devices i.e. the created irq table by getpir shows a line for device 8, but there is currently no device, the same for some other currently not used devices.
are you sure that's not the pci slot (is there one)?
Good question,
There is first the onboard integrated vga device on 00:9.0 the southbridge on 00:12.0 and usb on 00:13.0
than a expansion slot for pci/isa riser cards. The network card is plugged in a adaptor and shown under lspci as 00:7.0 on this slot.
if there really are impossible devices that is a sure sign that your $PIR is bogus.
Proplem is, normally the board has an integrated Network adaptor, which is not soldered in my case (optional) Should be a realtek 8139c. I guess that is a PCI device and eventually assign to 00:8.0
ron
the first seems to be wrong (0:16.0) 0x00 is the better choice. I thing "|" means "OR" I'm right?
Ok, the result is 18 in decimal. cat /proc/pci shows the southbridge with device 18, therefor it is right. I have made a mistake.
bitwise or, yes.
ron
are you sure that's not the pci slot (is there one)?
Good question,
There is first the onboard integrated vga device on 00:9.0 the southbridge on 00:12.0 and usb on 00:13.0
than a expansion slot for pci/isa riser cards. The network card is plugged in a adaptor and shown under lspci as 00:7.0 on this slot.
ok, can anybody have a look to the irq_tables.c
I have set all onboard components to slot 0x0 and assigned one link. Or is there a better way?
chris
BTW: Did you known, that the vt8235 southbridge from via have 8 INT Lines? 4 for external use #A - #D and 4 for onboard components only #E - #H
/* This file was generated by getpir.c, do not modify! (but if you do, please run checkpir on it to verify) * Contains the IRQ Routing Table dumped directly from your memory, which BIOS sets up * * Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM */
#include <arch/pirq_routing.h>
const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ 32+16*8, /* there can be total 8 devices on the bus */ 0x00, /* Where the interrupt router lies (bus) */ (0x12<<3)|0x0, /* Where the interrupt router lies (dev) */ 0xc00, /* IRQs devoted exclusively to PCI usage */ 0x1078, /* Vendor */ 0x2, /* Device */ 0, /* Crap (miniport) */ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ 0x3f, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ { /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ {0x00,(0x07<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0x0deb8}}, 0x1, 0x0}, /* pci/isa expansion */ /* {0x00,(0x08<<3)|0x0, {{0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0x0deb8}}, 0x2, 0x0}, */ {0x00,(0x09<<3)|0x0, {{0x00, 0xdeb8}, {0x01, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0, 0x0}, /* onboard vga */ /* {0x00,(0x0a<<3)|0x0, {{0x04, 0xdeb8}, {0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0x0deb8}}, 0x4, 0x0}, */ /* {0x00,(0x0b<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0x0deb8}}, 0x5, 0x0}, */ {0x00,(0x12<<3)|0x3, {{0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x02, 0xdeb8}, {0x00, 0x0deb8}}, 0x0, 0x0}, /* onboard audio */ /* {0x00,(0x0d<<3)|0x0, {{0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0xdeb8}, {0x02, 0x0deb8}}, 0x7, 0x0}, */ {0x00,(0x13<<3)|0x0, {{0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x03, 0x0deb8}}, 0x0, 0x0}, /* onboard usb */ } };
unsigned long write_pirq_routing_table(unsigned long addr) { return copy_pirq_routing_table(addr); }
* Christian Sühs chris@suehsi.de [060516 19:12]:
ok, can anybody have a look to the irq_tables.c
I have set all onboard components to slot 0x0 and assigned one link. Or is there a better way?
to achieve what?
Does USB get an interrupt with that pirq table?
Stefan
Stefan Reinauer schrieb:
- Christian Sühs chris@suehsi.de [060516 19:12]:
ok, can anybody have a look to the irq_tables.c
I have set all onboard components to slot 0x0 and assigned one link. Or is there a better way?
to achieve what?
Does USB get an interrupt with that pirq table?
Stefan
Well, the microsoft docu prefers to set onboard devices to 0x0 for slot numbers in the slot entrys.
First slot entry is device 7d, I think the pci/isa expansion slot, possible IRQs 10 and 11, because of the explicit settings. Next device 9d onboard vga should be IRQ 10; 11 or 9 Next device 18d function 3 onboard audio should be IRQ 5 Last device 19d onboard usb should be IRQ 10; 11 or 9
I'm unsure about the linking for #A; #B; #C; #D
chris
again, on some platforms which are broken, in mainboard.c, I just force the value of the 0x3c byte register for each device which needs an IRQ, the force the interupt router settings.
ron
Christian Sühs wrote:
Is it possible to assign IRQs with the Config.lb file like the superIO devices?
not currently.
I would just go ahead and set IRQs in your mainboard config file. In many cases, we have found the BIOS $PIR table is wrong, and the BIOS just sets register 3c.
ron
Ronald G Minnich wrote:
Christian Sühs wrote:
Is it possible to assign IRQs with the Config.lb file like the superIO devices?
not currently.
I would just go ahead and set IRQs in your mainboard config file. In
mainboard.c
many cases, we have found the BIOS $PIR table is wrong, and the BIOS just sets register 3c.
ron
sorry
ron
* Christian Sühs chris@suehsi.de [060511 15:33]:
One of the many delicacies of LinuxBIOS is that it enters protected mode (32bit mode) after only 17(!) CPU instructions.
Ok, were is it done in LB is entering protected mode a standard procedur of LB.
Yes, this is a standard procedure on all x86 CPUs
I wrote the attached document quite a long time ago. Its not all current but it might help to understand the concept
I would assume it is there anyways, or the FPU is always enabled for the GX1?
Maybe, I have to read the datasheet for FPU
I would not care any further. This part works...
Stefan
On Mon, May 08, 2006 at 09:21:07PM +0200, Christian Sühs wrote:
That is my epia M Board ;) Currently we talk about MB3036 from Allwell.
Oops. Sorry. :)
On Tue, Apr 25, 2006 at 08:04:42PM +0200, Christian Sühs wrote:
LinuxBIOS-1.1.8.0Fallback Tue Apr 25 19:44:31 CEST 2006 starting...
[...]
No "Enabling cache" in there..
//Peter
The whole boottime is slow. Lb is 15s slower as the factory bios in kernel booting.
- copying LB to RAM seems slow.
- copying kernel and intitrd.gz to RAM seems slow
- uncompressing kernel seems slow.
All operations to or in RAM seems to be 3 times slower as under factory.
For all:
I have test the system under factory and LB with lmbench. Here are the results in textform. PostScript output files were sent to Ron. Is somebody interested, I could send these files to him/her, too.
I hope somebody has an good answer, for the differences ;) I need the final hint.
chris
// Factory bios
Simple syscall: 0.9600 microseconds Simple read: 2.3918 microseconds Simple write: 1.9787 microseconds Simple stat: 34.6497 microseconds Simple fstat: 3.4453 microseconds Simple open/close: 42.6172 microseconds Select on 10 fd's: 25.1296 microseconds Select on 100 fd's: 181.7419 microseconds Select on 250 fd's: 421.1667 microseconds Select on 500 fd's: 883.8333 microseconds Signal handler installation: 4.920 microseconds Signal handler overhead: 16.070 microseconds Protection fault: 3.541 microseconds Pipe latency: 30.8697 microseconds AF_UNIX sock stream latency: 114.1037 microseconds Process fork+exit: 2101.6667 microseconds Process fork+execve: 5921.0000 microseconds Process fork+/bin/sh -c: 38460.0000 microseconds File /usr/tmp/XXX write bandwidth: 12266 KB/sec Pagefaults on /usr/tmp/XXX: 12 usecs
"mappings 0.524288 63 1.048576 91 2.097152 147 4.194304 243 8.388608 409 16.777216 760
"File system latency 0k 1000 2420 12289 1k 1000 1465 6402 4k 1000 1383 6396 10k 1000 1037 5209
UDP latency using localhost: 268.1605 microseconds TCP latency using localhost: 529.0121 microseconds localhost: RPC: Unable to receive; errno = Connection reset by peer TCP/IP connection cost to localhost: 1586.5556 microseconds Socket bandwidth using localhost: 16.70 MB/sec Avg xfer: 3.2KB, 41.8KB in 49.0840 millisecs, 850.99 KB/sec AF_UNIX sock stream bandwidth: 18.33 MB/sec Pipe bandwidth: 28.55 MB/sec
"read bandwidth 0.000512 34.08 0.001024 51.92 0.002048 65.33 0.004096 56.90 0.008192 27.30 0.016384 24.78 0.032768 28.26 0.065536 28.44 0.131072 29.55 0.262144 28.65 0.524288 29.63 1.05 29.18 2.10 29.39 4.19 29.48 8.39 29.41 16.78 29.00
"read open2close bandwidth 0.000512 6.25 0.001024 9.76 0.002048 15.13 0.004096 16.01 0.008192 19.13 0.016384 23.12 0.032768 26.19 0.065536 28.47 0.131072 28.94 0.262144 28.92 0.524288 29.42 1.05 29.54 2.10 29.38 4.19 29.46 8.39 28.36 16.78 28.71
"Mmap read bandwidth 0.000512 335.31 0.001024 360.26 0.002048 374.30 0.004096 381.42 0.008192 385.99 0.016384 130.26 0.032768 111.84 0.065536 112.53 0.131072 112.39 0.262144 112.81 0.524288 113.19 1.05 113.19 2.10 113.34 4.19 113.40 8.39 113.42 16.78 113.43
"Mmap read open2close bandwidth 0.000512 3.37 0.001024 6.45 0.002048 11.83 0.004096 20.30 0.008192 30.98 0.016384 45.13 0.032768 59.90 0.065536 72.43 0.131072 81.10 0.262144 84.73 0.524288 88.23 1.05 90.12 2.10 91.20 4.19 91.87 8.39 92.38 16.78 91.49
"libc bcopy unaligned 0.000512 181.88 0.001024 166.07 0.002048 159.08 0.004096 154.96 0.008192 54.87 0.016384 37.60 0.032768 37.65 0.065536 37.16 0.131072 35.33 0.262144 37.72 0.524288 35.59 1.05 35.83 2.10 35.96 4.19 37.95 8.39 38.03
"libc bcopy aligned 0.000512 181.36 0.001024 166.41 0.002048 158.77 0.004096 155.13 0.008192 79.75 0.016384 38.71 0.032768 33.47 0.065536 34.72 0.131072 35.83 0.262144 35.66 0.524288 34.30 1.05 33.19 2.10 32.88 4.19 31.89 8.39 31.22
"unrolled bcopy unaligned 0.000512 78.50 0.001024 77.65 0.002048 77.10 0.004096 76.40 0.008192 74.12 0.016384 48.09 0.032768 42.16 0.065536 47.81 0.131072 44.12 0.262144 43.64 0.524288 45.17 1.05 43.94 2.10 43.49 4.19 43.59 8.39 42.31
"unrolled partial bcopy unaligned 0.000512 339.91 0.001024 321.87 0.002048 314.28 0.004096 308.66 0.008192 302.18 0.016384 72.57 0.032768 78.92 0.065536 91.61 0.131072 72.33 0.262144 72.37 0.524288 72.24 1.05 72.08 2.10 73.19 4.19 72.79 8.39 68.07
Memory read bandwidth 0.000512 398.59 0.001024 394.00 0.002048 391.75 0.004096 390.06 0.008192 386.22 0.016384 124.45 0.032768 106.41 0.065536 106.91 0.131072 107.10 0.262144 107.47 0.524288 107.70 1.05 107.78 2.10 107.88 4.19 107.94 8.39 107.94 16.78 107.97
Memory partial read bandwidth 0.000512 1510.70 0.001024 1471.08 0.002048 1459.23 0.004096 1443.90 0.008192 1426.68 0.016384 186.60 0.032768 147.81 0.065536 148.86 0.131072 148.95 0.262144 149.45 0.524288 149.58 1.05 149.73 2.10 150.04 4.19 150.29 8.39 150.32 16.78 150.13
Memory write bandwidth 0.000512 81.05 0.001024 77.64 0.002048 77.00 0.004096 80.24 0.008192 78.77 0.016384 76.65 0.032768 76.51 0.065536 76.70 0.131072 76.61 0.262144 76.49 0.524288 76.49 1.05 76.58 2.10 76.59 4.19 76.57 8.39 76.55 16.78 76.55
Memory partial write bandwidth 0.000512 335.73 0.001024 320.35 0.002048 313.17 0.004096 342.13 0.008192 309.40 0.016384 307.06 0.032768 305.86 0.065536 307.10 0.131072 305.86 0.262144 305.33 0.524288 305.40 1.05 305.35 2.10 305.35 4.19 305.40 8.39 304.95 16.78 304.77
Memory partial read/write bandwidth 0.000512 657.73 0.001024 646.30 0.002048 643.47 0.004096 637.52 0.008192 529.97 0.016384 66.52 0.032768 48.55 0.065536 62.41 0.131072 63.75 0.262144 63.09 0.524288 62.78 1.05 65.78 2.10 69.49 4.19 72.13 8.39 73.36 16.78 73.17
Memory bzero bandwidth 0.000512 165.47 0.001024 159.40 0.002048 155.87 0.004096 154.40 0.008192 152.56 0.016384 73.35 0.032768 64.76 0.065536 67.95 0.131072 66.03 0.262144 64.40 0.524288 64.55 1.05 65.10 2.10 66.90 4.19 67.70 8.39 67.46 16.78 66.72
###########################################################
// Linuxbios
Simple syscall: 1.0587 microseconds Simple read: 3.0496 microseconds Simple write: 2.2977 microseconds Simple stat: 39.5735 microseconds Simple fstat: 7.5697 microseconds Simple open/close: 53.2816 microseconds Select on 10 fd's: 30.4326 microseconds Select on 100 fd's: 244.9130 microseconds Select on 250 fd's: 571.6667 microseconds Select on 500 fd's: 1132.8000 microseconds Signal handler installation: 10.752 microseconds Signal handler overhead: 26.242 microseconds Protection fault: 3.764 microseconds Pipe latency: 37.8057 microseconds AF_UNIX sock stream latency: 124.3030 microseconds Process fork+exit: 2114.3333 microseconds Process fork+execve: 6837.0000 microseconds Process fork+/bin/sh -c: 47319.0000 microseconds File /usr/tmp/XXX write bandwidth: 10117 KB/sec Pagefaults on /usr/tmp/XXX: 15 usecs
"mappings 0.524288 66 1.048576 102 2.097152 164 4.194304 281 8.388608 509 16.777216 949
"File system latency 0k 1000 2235 10752 1k 1000 1300 5164 4k 1000 1224 5149 10k 1000 918 4063
UDP latency using localhost: 304.6211 microseconds TCP latency using localhost: 627.8740 microseconds localhost: RPC: Unable to receive; errno = Connection reset by peer TCP/IP connection cost to localhost: 1821.4375 microseconds Socket bandwidth using localhost: 14.70 MB/sec Avg xfer: 3.2KB, 41.8KB in 57.3850 millisecs, 727.89 KB/sec AF_UNIX sock stream bandwidth: 18.41 MB/sec Pipe bandwidth: 19.38 MB/sec
"read bandwidth 0.000512 19.77 0.001024 27.35 0.002048 38.14 0.004096 37.52 0.008192 32.68 0.016384 22.86 0.032768 26.28 0.065536 25.17 0.131072 27.13 0.262144 25.79 0.524288 27.63 1.05 26.66 2.10 27.39 4.19 27.40 8.39 27.93 16.78 28.31
"read open2close bandwidth 0.000512 4.62 0.001024 7.44 0.002048 12.11 0.004096 14.87 0.008192 18.90 0.016384 19.46 0.032768 24.69 0.065536 26.23 0.131072 25.82 0.262144 26.67 0.524288 25.89 1.05 26.90 2.10 26.77 4.19 27.17 8.39 27.63 16.78 27.01
"Mmap read bandwidth 0.000512 336.09 0.001024 359.72 0.002048 374.05 0.004096 383.24 0.008192 385.79 0.016384 236.49 0.032768 110.97 0.065536 110.72 0.131072 110.57 0.262144 110.89 0.524288 111.25 1.05 111.30 2.10 111.38 4.19 111.40 8.39 111.45 16.78 111.49
"Mmap read open2close bandwidth 0.000512 2.83 0.001024 5.45 0.002048 10.07 0.004096 16.53 0.008192 26.34 0.016384 38.39 0.032768 53.77 0.065536 67.27 0.131072 76.42 0.262144 82.76 0.524288 85.93 1.05 87.89 2.10 89.35 4.19 89.53 8.39 89.39 16.78 90.02
"libc bcopy unaligned 0.000512 73.99 0.001024 74.40 0.002048 74.61 0.004096 74.71 0.008192 66.59 0.016384 40.64 0.032768 33.67 0.065536 31.07 0.131072 33.16 0.262144 32.92 0.524288 32.76 1.05 33.16 2.10 32.74 4.19 32.84 8.39 32.21
"libc bcopy aligned 0.000512 73.95 0.001024 74.32 0.002048 74.85 0.004096 74.57 0.008192 70.46 0.016384 40.17 0.032768 29.74 0.065536 32.42 0.131072 31.61 0.262144 31.63 0.524288 32.10 1.05 32.28 2.10 31.78 4.19 31.33 8.39 29.15
"unrolled bcopy unaligned 0.000512 74.75 0.001024 74.61 0.002048 74.74 0.004096 74.69 0.008192 73.48 0.016384 59.93 0.032768 41.56 0.065536 40.22 0.131072 39.76 0.262144 40.53 0.524288 39.71 1.05 39.91 2.10 40.21 4.19 40.38 8.39 39.23
"unrolled partial bcopy unaligned 0.000512 297.85 0.001024 297.71 0.002048 298.54 0.004096 294.47 0.008192 294.19 0.016384 222.50 0.032768 60.30 0.065536 64.31 0.131072 63.56 0.262144 68.53 0.524288 64.84 1.05 64.28 2.10 65.24 4.19 66.06 8.39 62.29
Memory read bandwidth 0.000512 503.47 0.001024 441.51 0.002048 412.41 0.004096 402.22 0.008192 393.14 0.016384 229.19 0.032768 105.31 0.065536 105.31 0.131072 105.41 0.262144 105.73 0.524288 105.51 1.05 106.09 2.10 106.17 4.19 106.20 8.39 106.23 16.78 106.25
Memory partial read bandwidth 0.000512 6413.62 0.001024 2376.47 0.002048 2263.91 0.004096 1598.26 0.008192 1502.30 0.016384 622.78 0.032768 145.21 0.065536 146.23 0.131072 146.15 0.262144 146.74 0.524288 146.90 1.05 147.02 2.10 147.14 4.19 147.50 8.39 147.56 16.78 147.60
Memory write bandwidth 0.000512 74.58 0.001024 74.68 0.002048 74.77 0.004096 74.55 0.008192 74.78 0.016384 75.08 0.032768 74.74 0.065536 74.98 0.131072 74.81 0.262144 74.82 0.524288 74.87 1.05 74.99 2.10 74.97 4.19 74.95 8.39 74.96 16.78 74.94
Memory partial write bandwidth 0.000512 261.86 0.001024 279.25 0.002048 299.46 0.004096 298.74 0.008192 298.44 0.016384 298.11 0.032768 297.95 0.065536 299.20 0.131072 298.36 0.262144 298.52 0.524288 298.65 1.05 298.65 2.10 298.61 4.19 298.46 8.39 298.62 16.78 298.36
Memory partial read/write bandwidth 0.000512 298.30 0.001024 277.56 0.002048 296.72 0.004096 294.21 0.008192 294.64 0.016384 205.18 0.032768 89.60 0.065536 89.87 0.131072 89.87 0.262144 90.79 0.524288 90.01 1.05 90.50 2.10 90.55 4.19 90.47 8.39 90.49 16.78 90.53
Memory bzero bandwidth 0.000512 72.31 0.001024 73.77 0.002048 74.15 0.004096 74.49 0.008192 74.45 0.016384 71.12 0.032768 55.88 0.065536 55.98 0.131072 56.04 0.262144 56.16 0.524288 56.16 1.05 56.19 2.10 56.20 4.19 56.21 8.39 56.25 16.78 56.23
It don't work :D
I can't believe that, whit enabled orginal printfs it don't work. Whit disabled ones it work normally.
Sorry, for this run I have made a mistake.
You can ignore the results. The proper logs was sent to Richard.
With testbios there is also a long delay after the first int10.
The debug spokes out about 5MB of ff for inb, than I have stop the run. After that I have disabled the inb printf and all went fine.
Now I wait for an answer from Richard.
chris
Two theories:
- caching of the C segment is messed up
- timing is messed up
Sorry, I'm not a bit guru. What is the result of that.
0x040000000>>30
bitwise rightshift
is it 0x04 ??
chris
Christian Sühs wrote:
Two theories:
- caching of the C segment is messed up
- timing is messed up
Sorry, I'm not a bit guru. What is the result of that.
0x040000000>>30
bitwise rightshift
is it 0x04 ??
chris
Get the aardvark, calculator, acalc. It makes this stuff really easy.
in acalc, you would do this: x40000000 30 sr
and get 1.
ron
in acalc, you would do this: x40000000 30 sr
Well, the graphic instructions for the geode are disabled in that case :D
because this value is writen to b8h (Graphic Control Registers)
However, I'm not sure what I should do next.
I think i will play around with the BC_XMAP_1 registers and will set the amd prefered values :D
Currently the whole video RAM section seems to be disabled. a0000 - bffff
chris
and get 1.
ron
On 4/28/06, Christian Sühs chris@suehsi.de wrote:
I think i will play around with the BC_XMAP_1 registers and will set the amd prefered values :D
Currently the whole video RAM section seems to be disabled. a0000 - bffff
Yeah but remember it all works from the userspace emu with the same settings.
-- Richard A. Smith
Yeah but remember it all works from the userspace emu with the same settings.
-- Richard A. Smith
Ok, I will wait for a better in tree emulator :D
chris
On 4/28/06, Christian Sühs chris@suehsi.de wrote:
Yeah but remember it all works from the userspace emu with the same settings.
Ok, I will wait for a better in tree emulator :D
Hmmm giving this some more thought and based on what Ron has said this I think I made an Apples to Oranges comparison.
Since we still don't know _what_ is really going on, seems reasonable to just try everything. So go ahead and play with those bit settings. Can't hurt.
-- Richard A. Smith
* Christian Sühs chris@suehsi.de [060428 18:40]:
Two theories:
- caching of the C segment is messed up
- timing is messed up
Sorry, I'm not a bit guru. What is the result of that.
0x040000000>>30
type in bash:
$ printf "0x%x\n" $(( 0x040000000>>30 ))
Stefan
Goodrich,Steven schrieb:
Hmm... Let me back up a step. I'm apparently answering a question you're not asking. Your problem is that you want to disable the internal video (and PCI header) and use external, right? Is that it?
Yes, but Not really external, the "onboard" Cyberpro 5000 graphic chipset looks like a integrated pci card with own memory. I guess external is the right word for that :D
Under factory bios, the device 00:12.4 is not shown with lspci. We know, that it is possible to disable the special graphic instructions for the Geode CPU, but I think 00:12.4 is the integrated graphic stuff at the southbridge cs5530. So, is it automaticaly disabled, when the Geode Graphic stuff is disabled or is there a magic bit for the cs5530 itself?
However, it would be fine to totally disable device 00:12.4
Our current main problem is the slow coming up "external" vga device. It takes around 90 seconds to initialize this device under LB with the emulator.
Our preferred settings for this platform were:
BC_XMAP_1 = 0x1300C060
That could help, currently is it set to 0x60
BC_XMAP_2 = 0x09999999 BC_XMAP_3 = 0x99****99 (* = don't care)
Or perhpaps just confuse things more. 9's in XMAP2 is PCI accessable, No Cache, No Write, Read.
What about CPU revisions, could it be that this registers have changed in the time? I guess, I use an older datassheet.
chris
-
Carl-Daniel Hailfinger -
Christian Sühs -
Goodrich,Steven -
Hidasi Jozsef -
Li-Ta Lo -
Peter Stuge -
Richard Smith -
Ronald G Minnich -
Russell Whitaker -
Stefan Reinauer