This is not signed off, as it does not work.
It sets up the interrupts correctly, or at least as defined in the dts:
00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 0) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 10 Region 0: I/O ports at 1880 [size=128]
00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02) (prog-if 10 ) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 Interrupt: pin D routed to IRQ 5 Region 0: Memory at fe016000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02) (prog-if 20 ) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin D routed to IRQ 5 Region 0: Memory at fe017000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
But they appear not to be wired internally: pbx ~ # cat /proc/interrupts CPU0 0: 48248 XT-PIC-XT timer 2: 0 XT-PIC-XT cascade 4: 2333 XT-PIC-XT serial 5: 0 XT-PIC-XT ohci_hcd:usb1 7: 4 XT-PIC-XT 8: 0 XT-PIC-XT rtc 10: 21 XT-PIC-XT eth0 14: 13886 XT-PIC-XT ide0 NMI: 0 Non-maskable interrupts TRM: 0 Thermal event interrupts SPU: 0 Spurious interrupts ERR: 4
So if I push a USB part in, then I get no interrupts.
If I leave the USB interrupts in the irq_table, I get interrupts.
What piece am I missing here? I assume I'm not wiring something up in the x,y,z unrestricted interrupt register.
Further, what interrupts are safe to use? We keep reusing 10, 11, 5, etc. Any reason not to use (e.g.) 6 or 13 or 12? Is there a Geode rule I need to know?
thanks
ron
On Fri, May 02, 2008 at 10:51:59PM -0700, ron minnich wrote:
So if I push a USB part in, then I get no interrupts.
If I leave the USB interrupts in the irq_table, I get interrupts.
What piece am I missing here? I assume I'm not wiring something up in the x,y,z unrestricted interrupt register.
I think it's more difficult than that. We talked about this during the summit (there's a similar problem with the alix.2c3 and eth2/usb interrupts), and Marc said that in addition to a change like this patch, we need to make the change in the VSA...
I'm not sure how that would work. Ideally this stuff would be board-specific; can we adjust the cs5536 internal interrupts in the VSA somehwo during coreboot build?
Thanks, Ward.
Hi Ron,
I merged two mails from you with similar topic to answer them in one swoop.
On 03.05.2008 07:51, ron minnich wrote:
This is not signed off, as it does not work.
It sets up the interrupts correctly, or at least as defined in the dts:
00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 0) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 10 Region 0: I/O ports at 1880 [size=128]00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02) (prog-if 10 ) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 Interrupt: pin D routed to IRQ 5 Region 0: Memory at fe016000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mAPME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02) (prog-if 20 ) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin D routed to IRQ 5 Region 0: Memory at fe017000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mAPME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
But they appear not to be wired internally: pbx ~ # cat /proc/interrupts CPU0 0: 48248 XT-PIC-XT timer 2: 0 XT-PIC-XT cascade 4: 2333 XT-PIC-XT serial 5: 0 XT-PIC-XT ohci_hcd:usb1 7: 4 XT-PIC-XT 8: 0 XT-PIC-XT rtc 10: 21 XT-PIC-XT eth0 14: 13886 XT-PIC-XT ide0 NMI: 0 Non-maskable interrupts TRM: 0 Thermal event interrupts SPU: 0 Spurious interrupts ERR: 4
So if I push a USB part in, then I get no interrupts.
If I leave the USB interrupts in the irq_table, I get interrupts.
What piece am I missing here? I assume I'm not wiring something up in the x,y,z unrestricted interrupt register.
Further, what interrupts are safe to use? We keep reusing 10, 11, 5, etc. Any reason not to use (e.g.) 6 or 13 or 12? Is there a Geode rule I need to know?
thanks
ron
On 03.05.2008 06:46, ron minnich wrote:
(I'm hoping someone will do this :-)
One issue I'm having is that the hfcpci card (or driver) can't tolerate shared interrupts. But we have shared interrupts on the various cs5536 boards, since we put USB interrupt info in the table.
To allow us to have non-shared interrupts for all devices, we need to get the USB interrupts out of the PIR table. They are not really routed via the standard IRQ router anyway -- they are internal -- and don't need to share interrupt #s with the other devices that are actually routed via the interrupt routing hardware.
Put simply, having the USB f.3,4,5 devices in the PIR table works, but is really a bit of a mistake.
So an abstract model of the hardware would be: - standard IRQ router, settings from PIR table - CS5536-internal virtual IRQ router, settings outside PIR table.
OK, where do we put the IRQ info for the USB devices? In the DTS for the cs5536.
SO in DTS for the cs5536 we need three more properties, usbf3 usbf4 usbf5
with reasonable settings for them. Then in the chipset init code, we need to see if these are set and, if so, set the IRQ line in the f.3, f.4, and f.5 devices.
If this is confusing I can explain in more detail, but later, I'm tired, and the ISDN card just locked up again. How can such a simple driver have so many failure modes? Oh, wait, it's not simple, sigh.
but, short form: on the cs5536, USB interrupts should not be described in the PIR table, but via settings derived from dts. They should be initialized in cs5536 setup code, no in the PIR setup code. That will allow us to have non-shared interrupts on the various PCI slots on, e.g., alix1c, and allow broken drivers like hfcpci to work.
Sorry, but I have to disagree with the design. Your proposed change scatters interrupt settings and routing info into totally different types of files. Either interrupt settings are something we want to have in the DTS (and that would mean we have to keep the PIR table in the dts as well) or they are kept in separate tables in irq_tables.h.
Index: southbridge/amd/cs5536/cs5536.c
--- southbridge/amd/cs5536/cs5536.c (revision 674) +++ southbridge/amd/cs5536/cs5536.c (working copy) @@ -410,6 +410,28 @@ #define PADEN_SET (1 << 7)
/**
- Depending on settings in the config struct, manage audio setup.
- @param sb Southbridge config structure.
- */
+static void audio_init(struct southbridge_amd_cs5536_dts_config *sb) +{
- u32 *bar;
- struct msr msr;
- struct device *dev;
- if (!sb->audio_enable)
return;- dev = dev_find_pci_device(PCI_VENDOR_ID_AMD,
PCI_DEVICE_ID_AMD_CS5536_AUDIO, 0);
I see dev_pci_find_device crop up more and more often in v3 and it scares me. Is the device tree code really that bad that we can't avoid dev_pci_find_device? Or did I misunderstand the benefits of the device tree?
- if (dev) {
pci_write_config8(dev, PCI_INTERRUPT_LINE, sb->audio_irq);- }
+}
+/**
- Depending on settings in the config struct, manage USB setup.
- @param sb Southbridge config structure.
@@ -438,9 +460,21 @@
/* EECP=50h, IST=01h, ASPC=1 */ *(bar + HCCPARAMS) = 0x00005012;
/* set interrupt line */pci_write_config8(dev, PCI_INTERRUPT_LINE, sb->ehci_irq);}
dev = dev_find_pci_device(PCI_VENDOR_ID_AMD,
PCI_DEVICE_ID_AMD_CS5536_OHCI, 0);
Same dev_find_pci_device objection here.
- if (dev) {
/* set interrupt line */pci_write_config8(dev, PCI_INTERRUPT_LINE, sb->ohci_irq);- }
- dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_OTG, 0);
Same dev_find_pci_device objection here.
if (dev) { bar = (u32 *) pci_read_config32(dev, PCI_BASE_ADDRESS_0); @@ -649,6 +683,8 @@
enable_USB_port4(sb);
- audio_init(sb);
- /* disable unwanted virtual PCI devices */ for (i = 0; 0 != sb->unwanted_vpci[i]; i++) { hide_vpci(sb->unwanted_vpci[i]);
I see v3 as a big promise of clean design, readable code and easy porting and I fiercely try to keep it that way. This motivates me to work on secret projects which will transform the current v3 code to fulfill its design destiny. Expect code sometime in July.
Regards, Carl-Daniel
On Sat, May 3, 2008 at 9:25 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Sorry, but I have to disagree with the design. Your proposed change scatters interrupt settings and routing info into totally different types of files. Either interrupt settings are something we want to have in the DTS (and that would mean we have to keep the PIR table in the dts as well) or they are kept in separate tables in irq_tables.h.
good point.
The geode is a very odd beast, however, and does not follow the rules. The USB is not really connected via the IRQ router. You can specify USB IRQs in the PIR table and get working boards, but you are restricting the USB interrupts to one of four choices and that is really not necessary or required. It would be better if we do not restrict ourselves unnecessarily.
Which really means the PIR table must die! die! die! die!
dev = dev_find_pci_device(PCI_VENDOR_ID_AMD,PCI_DEVICE_ID_AMD_CS5536_AUDIO, 0);I see dev_pci_find_device crop up more and more often in v3 and it scares me. Is the device tree code really that bad that we can't avoid dev_pci_find_device? Or did I misunderstand the benefits of the device tree?
I don't see the problem. This strikes me as a fairly cheap and safe way to ensure that the device you think is there is there. Given vendor's propensity for undocumented chipset changes, I think this is safe.
I could blindly trust the bus:dev.fn I put in the tree, however; I had not even thought of this. Good point again but ... look at the cs5536 code and the dts. Much of cs5536 init code involves things not in the dts, as there is no reason to put it in the dts. Why burden people with all this specification when a simple find_device can resolve it?
I see v3 as a big promise of clean design, readable code and easy porting and I fiercely try to keep it that way. This motivates me to work on secret projects which will transform the current v3 code to fulfill its design destiny. Expect code sometime in July.
Well, I trust you to create a great design, but still, a 'secret project' sounds a little worrisome. We used to get these from one vendor, just submitted with no comments, and they were not really usable. I think if you're doing a redesign you should do what I try to do -- bring it to the list and take the comments.
I will probably drop this patch I guess. But I suspect there are some deep-rooted IRQ problems in the LX port, even down into the VSA, and that's why we're having MFGPT and other issues. The Geode is just not quite right yet, and interrupts are a part of the problem.
The DBE62 does not really set up IRQs for USB, and that may be related to why there is a power issue. Mart, note that alix1c sets up USB in the PIR table and dbe62 does not. How are you getting USB to work at all?
thanks
ron
On Sat, May 03, 2008 at 11:41:16AM -0700, ron minnich wrote:
The geode is a very odd beast
Yes.
It would be better if we do not restrict ourselves unnecessarily.
I don't think we'll go all the way on this anytime soon. :\
Which really means the PIR table must die! die! die! die!
I would like to specify all about interrupts in the dts. I still don't know what we need in the syntax..
dev_pci_find_device?
I don't see the problem.
The point is that the device tree model should allow code to be associated with the right device, so that no find_device() calls are needed.
deep-rooted IRQ problems in the LX port, even down into the VSA,
VSA is very much involved at least in setting up interrupts so I suspect anything about interrupts on Geode has to at least be seen by VSA so it can update the neccessary MSRs.
Until the Geode architecture is supported in Linux we have to deal with the PCI emulation. Maybe time to look into OpenVSA a bit more?
//Peter
On Sat, May 3, 2008 at 3:28 PM, Peter Stuge peter@stuge.se wrote:
dev_pci_find_device?
I don't see the problem.
The point is that the device tree model should allow code to be associated with the right device, so that no find_device() calls are needed.
Well, I welcome the patches. Until I have time for this, or someone else does, it'sgoing to have to stay that way :-)
I agree that we ought to be able to make this work.
Until the Geode architecture is supported in Linux we have to deal with the PCI emulation. Maybe time to look into OpenVSA a bit more?
I think it's time to move to openvsa. I am not comfortable depending on this binary blob. I think there's a problem but have no way to even attempt to diagnose it. Peter, if you could, OpenVSA might be a good thing for you to focus on for a little bit. Rather than all of us working on the same thing, I think we need to divide and conquer.
I think I will have to fix this crappy ISDN driver, if only to show that it's not a coreboot problem.
It would be nice to get Geode rock solid in the next 6 weeks, in time for July 14.
We are very, very close.
Thanks
ron
On 04.05.2008 00:34, ron minnich wrote:
It would be nice to get Geode rock solid in the next 6 weeks, in time for July 14.
We are very, very close.
May I ask about the meaning of July 14 and at the same time suggest we have v3 Geode rock solid at the end of May so I can showcase it at LinuxTag?
Regards, Carl-Daniel
On Sat, May 3, 2008 at 4:34 PM, Carl-Daniel Hailfinger
May I ask about the meaning of July 14
bastille day, when people stormed the ramparts and released 7 prisoners. http://en.wikipedia.org/wiki/Bastille_Day
and at the same time suggest we have v3 Geode rock solid at the end of May so I can showcase it at LinuxTag?
I love that idea, but at the rate we're going it will be tough. I think it'd be wonderful to have the booth full of dbe62s and alix?c? and so on.
But we need to resolve MFGPT and one or two other issues.
I think your goal is really a good one, however.
ron
On Sat, May 03, 2008 at 04:58:11PM -0700, ron minnich wrote:
But we need to resolve MFGPT and one or two other issues.
MFGPTs are in the DD (Diverse Device) while USB is a separate module on a differet GLIU port. I doubt the problems are related.
//Peter
On Sat, May 03, 2008 at 03:34:21PM -0700, ron minnich wrote:
Maybe time to look into OpenVSA a bit more?
Peter, if you could, OpenVSA might be a good thing for you to focus on for a little bit.
Surely you jest. You know how I feel about VSA.. I was just trying to inspire someone else.
Rather than all of us working on the same thing, I think we need to divide and conquer.
Also a good point.
It would be nice to get Geode rock solid in the next 6 weeks, in time for July 14.
I would also like to show off v3 in Berlin. I will bring my alix boards and the epia cn, maybe Bari has it too good by then. :) I'll bring an m57sli or two. I'll need to buy or borrow a screen for it all..
We are very, very close.
Dunno..
//Peter
On 04.05.2008 03:48, Peter Stuge wrote:
On Sat, May 03, 2008 at 03:34:21PM -0700, ron minnich wrote:
It would be nice to get Geode rock solid in the next 6 weeks, in time for July 14.
I would also like to show off v3 in Berlin. I will bring my alix boards and the epia cn, maybe Bari has it too good by then. :) I'll bring an m57sli or two. I'll need to buy or borrow a screen for it all..
Depending on how much space we get, displaying more than two systems could pose real challenges.
We are very, very close.
Dunno..
I'd even say we have arrived. With the right payload configuration, these systems work fine (unless you want to use those pesky ISDN cards with horrible drivers). To be honest, I'd say we sidestep the ISDN issue completely by using any other miniPCI card for demos.
Regards, Carl-Daniel
On Sun, May 04, 2008 at 11:57:25AM +0200, Carl-Daniel Hailfinger wrote:
I would also like to show off v3 in Berlin.
Depending on how much space we get, displaying more than two systems could pose real challenges.
IIRC orgas are talked about one half infopoint. That is an area about 1m wide and 60cm deep. I'd say up to six mainboards can fit if they are small enough. My only problem is with displays - there is neither room nor logistics for more than a single screen, and it's a little boring to only see output from one board at a time. :\
I'll try to bring a 4-1 monitor switch so we can at least switch around easily. Last year we had serial output from lots of boards on the screen at the same time, we can do that again but it's more fun to have VGA tint on power on. ;)
I'll bring a PS/2 keyboard.
We are very, very close.
Dunno..
I'd even say we have arrived.
Strongly disagree.
With the right payload configuration,
Nono, "arrived" means there are zero reservations.
I spent a good hour creating a v3 that did nothing at all on my alix1c. Turned out to be a VSA blob formatting problem. It still can not use the CF.
Neither buildrom nor v3 actually include VSA blob and payload.elf when I run make. I forget where the zerofill option was, but that wasn't done either.
Oh and stuffing everything into build/ feels so unusual. I go looking for lar in all the wrong places (util) but that's just me.
these systems work fine (unless you want to use those pesky ISDN cards with horrible drivers). To be honest, I'd say we sidestep the ISDN issue completely by using any other miniPCI card for demos.
Yes definately. But please keep in mind that the product is not done until it has been so polished that users mistake it for a mirror. ;)
Btw, what is a fun miniPCI-card? All I have is the POST card and two wifi cards.
Or a fun PCI card for that matter, for alix1c.
//Peter
On Sun, May 04, 2008 at 12:34:42PM +0200, Peter Stuge wrote:
We are very, very close.
Dunno..
I'd even say we have arrived.
Strongly disagree.
Let's just say more work needs to be done. Polishing is really really really important. We want to be better than the proprietary alternative - and that means that all parts of a supported board need to work, and work properly.
With the right payload configuration,
Nono, "arrived" means there are zero reservations.
Agreed.
I spent a good hour creating a v3 that did nothing at all on my alix1c. Turned out to be a VSA blob formatting problem. It still can not use the CF.
I'm not seeing all these issues?
Neither buildrom nor v3 actually include VSA blob and payload.elf when I run make. I forget where the zerofill option was, but that wasn't done either.
.... I don't know what the problem is you are seeing, but buildrom (v3) works just fine for me. It generates an alix.1c image with filo payload and VSA blob, which boots perfectly from CF (with the dongle). All built on Ubuntu Gutsy 32 bit.
Config and generated image at
http://ward.vandewege.net/coreboot/alix.1c-v3-working/
Toolchain issues? Your CF boots under the proprietary bios right? Are there multiple alix.1c revisions?
Oh and stuffing everything into build/ feels so unusual. I go looking for lar in all the wrong places (util) but that's just me.
I'm with you there :) It's weird and a bit annoying.
these systems work fine (unless you want to use those pesky ISDN cards with horrible drivers). To be honest, I'd say we sidestep the ISDN issue completely by using any other miniPCI card for demos.
Yes definately. But please keep in mind that the product is not done until it has been so polished that users mistake it for a mirror. ;)
100% agreed. By that reasoning, I don't think we have a single board that is truly 'finished'.
Thanks, Ward.
On 04.05.2008 12:34, Peter Stuge wrote:
On Sun, May 04, 2008 at 11:57:25AM +0200, Carl-Daniel Hailfinger wrote:
I would also like to show off v3 in Berlin.
Depending on how much space we get, displaying more than two systems could pose real challenges.
IIRC orgas are talked about one half infopoint. That is an area about 1m wide and 60cm deep. I'd say up to six mainboards can fit if they are small enough. My only problem is with displays - there is neither room nor logistics for more than a single screen, and it's a little boring to only see output from one board at a time. :\
I'll try to bring a 4-1 monitor switch so we can at least switch around easily. Last year we had serial output from lots of boards on the screen at the same time, we can do that again but it's more fun to have VGA tint on power on. ;)
I'll bring a PS/2 keyboard.
Great! I'll bring a USB keyboard.
http://www.coreboot.org/LinuxTag_2008 has the info I collected so far.
We are very, very close.
Dunno..
I'd even say we have arrived.
Strongly disagree.
With the right payload configuration,
Nono, "arrived" means there are zero reservations.
For me, "arrived" means v3 is as good as v2.
I spent a good hour creating a v3 that did nothing at all on my alix1c. Turned out to be a VSA blob formatting problem. It still can not use the CF.
Can you explain what you mean with "VSA blob formatting problem"?
Neither buildrom nor v3 actually include VSA blob and payload.elf when I run make. I forget where the zerofill option was, but that wasn't done either.
Buildrom should include the VSA AFAIK.
Oh and stuffing everything into build/ feels so unusual. I go looking for lar in all the wrong places (util) but that's just me.
these systems work fine (unless you want to use those pesky ISDN cards with horrible drivers). To be honest, I'd say we sidestep the ISDN issue completely by using any other miniPCI card for demos.
Yes definately. But please keep in mind that the product is not done until it has been so polished that users mistake it for a mirror. ;)
Right. The MFGPT issues definitely need to be solved.
Btw, what is a fun miniPCI-card? All I have is the POST card and two wifi cards.
Video+Audio capture cards would be a very unusual but rewarding choice: Commell MP-878AS or similar.
Or a fun PCI card for that matter, for alix1c.
A DVB-T receiver card could fit, but I have no idea where you can get decent reception indoors.
Regards, Carl-Daniel
On Sun, May 04, 2008 at 12:34:42PM +0200, Peter Stuge wrote:
With the right payload configuration,
Nono, "arrived" means there are zero reservations.
I spent a good hour creating a v3 that did nothing at all on my alix1c. Turned out to be a VSA blob formatting problem. It still can not use the CF.
Neither buildrom nor v3 actually include VSA blob and payload.elf when I run make. I forget where the zerofill option was, but that wasn't done either.
If you were trying to build v2 for the alix.1c using buildrom, that was broken - mea culpa. I fixed it in buildrom r178.
Thanks, Ward.
ron minnich wrote:
I think it's time to move to openvsa. I am not comfortable depending on this binary blob. I think there's a problem but have no way to even attempt to diagnose it. Peter, if you could, OpenVSA might be a good thing for you to focus on for a little bit. Rather than all of us working on the same thing, I think we need to divide and conquer.
Well, it is not really a binary blob. You have the source for it. You could rebuild it if you wanted to for some reason, you just need MASM. OpenVSA is the right goal, but it is no more "open" than the VSA you are using now, except that the hurdle of compilation is lower. The hurdle of getting it working and well tested is much higher, however.
Carl-Daniel Hailfinger wrote:
I see v3 as a big promise of clean design, readable code and easy porting and I fiercely try to keep it that way. This motivates me to work on secret projects which will transform the current v3 code to fulfill its design destiny. Expect code sometime in July.
Please don't. As you wrote yourself a few days ago to another developer (no exact quote): Release early and often, so we can correct your design in case it doesn't fit the standards.
There are (mostly legal) circumstances that make it hard or impossible to release code early, but I don't see any of those apply in your case.
Stefan
ron minnich wrote:
Further, what interrupts are safe to use? We keep reusing 10, 11, 5, etc. Any reason not to use (e.g.) 6 or 13 or 12? Is there a Geode rule I need to know?
This is not a Geode rule but you should take care when trying to share PCI interrupts (level) with legacy (edge) devices. 6 - floppy 13 - FPU 12 - ps/2 mouse
Marc
-
Carl-Daniel Hailfinger -
Marc Jones -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Tom Sylla -
Ward Vandewege