Hi Marc, Thanks for you last reply on virtual pci config space, I finally find a doc on it at http://www.amd.com/files/connectivitysolutions/geode/geode_gx/32663C_lx_gx_p... by reading the paper of <<Breaking the Chains—Using LinuxBIOS to Liberate Embedded x86 Processors>>, really thanks.
And I am curious with the irq signal of cs5536. it's said that gpio12 can be used as a INTR_OUT of pic, I have configure the GPIO as out_aux1，but it's seems I have missed something, the output of gpio12 doesn't change with some rtc interrupt occur(I can see some bit of irr of 8259 set).
Thanks in advanced.
Tian
done, there's a bug in my software, datebook is right~:)
Songmao Tian wrote:
Hi Marc, Thanks for you last reply on virtual pci config space, I finally find a doc on it at http://www.amd.com/files/connectivitysolutions/geode/geode_gx/32663C_lx_gx_p... by reading the paper of <<Breaking the Chains—Using LinuxBIOS to Liberate Embedded x86 Processors>>, really thanks.
And I am curious with the irq signal of cs5536. it's said that gpio12 can be used as a INTR_OUT of pic, I have configure the GPIO as out_aux1，but it's seems I have missed something, the output of gpio12 doesn't change with some rtc interrupt occur(I can see some bit of irr of 8259 set).
Thanks in advanced.Tian
with regard to interrupt signal, I am still puzzled with the PCI_INTA#, it is said that it's a input io. Shouldn't it output the interrupt signal to cpu?
Songmao Tian wrote:
done, there's a bug in my software, datebook is right~:)
Songmao Tian wrote:
Hi Marc, Thanks for you last reply on virtual pci config space, I finally find a doc on it at http://www.amd.com/files/connectivitysolutions/geode/geode_gx/32663C_lx_gx_p... by reading the paper of <<Breaking the Chains—Using LinuxBIOS to Liberate Embedded x86 Processors>>, really thanks.
And I am curious with the irq signal of cs5536. it's said that gpio12 can be used as a INTR_OUT of pic, I have configure the GPIO as out_aux1，but it's seems I have missed something, the output of gpio12 doesn't change with some rtc interrupt occur(I can see some bit of irr of 8259 set).
Thanks in advanced.Tian
On Thu, Jul 05, 2007 at 10:34:53PM +0800, Songmao Tian wrote:
with regard to interrupt signal, I am still puzzled with the PCI_INTA#, it is said that it's a input io. Shouldn't it output the interrupt signal to cpu?
I suspect it is the signal facing PCI devices.
The signal facing the CPU is probably inside the GeodeLink somewhere.
//Peter
Peter Stuge wrote:
On Thu, Jul 05, 2007 at 10:34:53PM +0800, Songmao Tian wrote:
with regard to interrupt signal, I am still puzzled with the PCI_INTA#, it is said that it's a input io. Shouldn't it output the interrupt signal to cpu?
I suspect it is the signal facing PCI devices.
The signal facing the CPU is probably inside the GeodeLink somewhere.
//Peter
Peter is correct. The PCI_INTA# from the CPU(northbridge) to the cs5536 is for graphics and/or AES egine interrupts. The interrupt signal(INTR#) from the cs5536 to the CPU is in the sideband serial packet. Look for "CPU Interface Serial (CIS)" in the 5536 databook for more information.
Marc
Marc Jones wrote:
Peter Stuge wrote:
On Thu, Jul 05, 2007 at 10:34:53PM +0800, Songmao Tian wrote:
with regard to interrupt signal, I am still puzzled with the PCI_INTA#, it is said that it's a input io. Shouldn't it output the interrupt signal to cpu?
I suspect it is the signal facing PCI devices.
The signal facing the CPU is probably inside the GeodeLink somewhere.
//Peter
Peter is correct. The PCI_INTA# from the CPU(northbridge) to the cs5536 is for graphics and/or AES egine interrupts. The interrupt signal(INTR#) from the cs5536 to the CPU is in the sideband serial packet. Look for "CPU Interface Serial (CIS)" in the 5536 databook for more information.
Marc
I got it:), I suspect that, but I haven't notice the that there's pci devices in northbridge. thanks Marc, thanks Peter.
On 7/5/07, Songmao Tian tiansm@lemote.com wrote:
with regard to interrupt signal, I am still puzzled with the PCI_INTA#, it is said that it's a input io. Shouldn't it output the interrupt signal to cpu?
On 5536, the PCI_INT{A,B,C,D}# signals are usually configured as inputs. (they are all just part of the GPIO block). Those signals then get mapped into the interrupt logic through the various IRQ mapping MSRs.
Interrupt delivery to the processor is done on the "CIS" pin that is an output from 5536 to the GX or LX processor. The CIS pin delivers IRQ, SMI, NMI, etc in a serial stream to the CPU. (the CPU de-serializes it, and has internal versions of those signals)
Your goal seems to be to mux 5536's internal INTR signal out onto a GPIO. There are some hints about that in the datasheet, but that is not an official way to do it. Normal Geode systems all use the serial packet. You will probably not get any support from AMD to do it that way, that path is not tested. (though I have seen it work)
Tom Sylla wrote:
On 7/5/07, Songmao Tian tiansm@lemote.com wrote:
with regard to interrupt signal, I am still puzzled with the PCI_INTA#, it is said that it's a input io. Shouldn't it output the interrupt signal to cpu?
On 5536, the PCI_INT{A,B,C,D}# signals are usually configured as inputs. (they are all just part of the GPIO block). Those signals then get mapped into the interrupt logic through the various IRQ mapping MSRs.
Interrupt delivery to the processor is done on the "CIS" pin that is an output from 5536 to the GX or LX processor. The CIS pin delivers IRQ, SMI, NMI, etc in a serial stream to the CPU. (the CPU de-serializes it, and has internal versions of those signals)
Your goal seems to be to mux 5536's internal INTR signal out onto a GPIO. There are some hints about that in the datasheet, but that is not an official way to do it. Normal Geode systems all use the serial packet. You will probably not get any support from AMD to do it that way, that path is not tested. (though I have seen it work)
Actually, we are using a non-Geode CPU(in fact it's a mips varient). I understand the situation, luckily I got helps from all of you:), thanks again.
Perhaps I will try to port the LinuxBIOS, but if so, I have to port another payload(I am looking into grub2, any other sugguestion?)
and u-boot is another good option.
On Fri, Jul 06, 2007 at 08:55:37AM +0800, Songmao Tian wrote:
Actually, we are using a non-Geode CPU(in fact it's a mips varient). I understand the situation, luckily I got helps from all of you:), thanks again.
Perhaps I will try to port the LinuxBIOS, but if so, I have to port another payload(I am looking into grub2, any other sugguestion?)
GRUB2 is being worked on as part of Google Summer of Code, so that should work soonish...
If you want to port LinuxBIOS to MIPS (which would be great!), please start with LinuxBIOSv3, which is still in early development stages but is a _lot_ better and easier to handle from a development (and user!) point of view.
Other than that, the "typical" payloads in LinuxBIOS are FILO (to boot from disk, for example) or memtest86 (for testing the RAM setup while developing). I don't know whether either of them support MIPS (guess not).
and u-boot is another good option.
Yeah, I've been wondering about this, too. But doesn't u-boot do pretty much the same we do in LinuxBIOS (just for other, mainly embedded boards)?
Or can it be configured to basically _not_ init the system (and leave that part to LinuxBIOS), but only provide a "shell" of some sort for configuration stuff (sorry, I haven't yet played much with u-boot).
Uwe.
Uwe Hermann wrote:
On Fri, Jul 06, 2007 at 08:55:37AM +0800, Songmao Tian wrote:
Actually, we are using a non-Geode CPU(in fact it's a mips varient). I understand the situation, luckily I got helps from all of you:), thanks again.
Perhaps I will try to port the LinuxBIOS, but if so, I have to port another payload(I am looking into grub2, any other sugguestion?)
GRUB2 is being worked on as part of Google Summer of Code, so that should work soonish...
I see you on the list:)
If you want to port LinuxBIOS to MIPS (which would be great!), please start with LinuxBIOSv3, which is still in early development stages but is a _lot_ better and easier to handle from a development (and user!) point of view.
I am under the way of clean up the start.S code, which is the common work of every thing, also some cache and basic configuration work. after that porting will be much easier.
Other than that, the "typical" payloads in LinuxBIOS are FILO (to boot from disk, for example) or memtest86 (for testing the RAM setup while developing). I don't know whether either of them support MIPS (guess not).
and u-boot is another good option.
Yeah, I've been wondering about this, too. But doesn't u-boot do pretty much the same we do in LinuxBIOS (just for other, mainly embedded boards)?
Or can it be configured to basically _not_ init the system (and leave that part to LinuxBIOS), but only provide a "shell" of some sort for configuration stuff (sorry, I haven't yet played much with u-boot).
u-boot trys to be versatile and small, and some tricky relocation is done to place itself on the top of the available ram (which I think I don't need). but I think with some modification u-boot can be a payload of LinuxBIOS:)
Uwe.
-
Marc Jones -
Peter Stuge -
Songmao Tian -
Tom Sylla -
Uwe Hermann