Ooops, wrong reply!

Last edited by AMiGR on 04-Jun-2005 at 12:33 AM.

_________________

@Chip

Wrong, Chip. The April adds Cache Coherency to the ArticiaS. No revision of the chip has it, no matter what. I thought that THIS was clear. The same thing is done on the micro with 2 MACH chips, as seen on the TeronMini stuff MAI accidently leaked, that include full schematics and the program for both chips. Lack of cache coherency can be worked around in software, by writing drivers with that in mind. This is done in OS4 for example. However, you cannot expect anyone to rewrite all Linux drivers to work with it.

_________________

@Chip

No working coherency fixes were done to the later Articia S steppings by MAI - the newer BNGE revision shows exactly the same DMA-related corruption as the older BNGP version used on the A1-SE. The DMA 'fix' is purely for the IDE/Ethernet lock-up problem and I don't recall that either Eyetech or any dealer doing the fix has ever claimed otherwise.

The coherency issue can't be fixed just by soldering some joints and cutting a few tracks. It's far too complex to be cured by anything other than a new revision of the Articia or an external IC that forces a cache invalidation after DMA activity, and I have my doubts that the latter course of action can ever be 100% effective without large performance penalties.

The IC-based fix on the production uA1-C boards would not have been necessary if MAI really had implemented a coherency fix in the BGNE Articia.

_________________
Who do you serve, and who do you trust? - Galen

Hi @elwood

This is really good news! Thanks for reporting it. France?
I'm not all that happy about pulling out the mobo and shipping it postal. I've lost UPS orders before, so I may pass the fix -- based soley on risk.
Thumbs up

@CodeSmith

You got that right.
Problem is people on this thread are talking about totally different things here.

April fixed some timing errors and inverts line on the Peg I board thats ALL IT EVER DID.
Same mod was done on the SE boards (just no fancy name ).
This was due to faulty documentation from Mai and a screw up from BPLAN
Not needed on the XE motherboards ( as the problem was discovered and corrected by the time the boards were made.

The Cache problem is a totally different story ( April does not fix this at all )
A Simple Software cache solution is used on the Linux distros (peg I and A1 boards ) and AOS4.

The Micro A1 problems are related to the 750GX module as 750FX equipped micros do not have the same issues.

The DMA fix on the A1 are related to the VIA south bridge.
This is not related to any problems on the Peg I becuase that uses a different south bridge.
The 686B on the A1 is not being initialized properly hence the onboard sound problem and the occasional DMA garbage spit out on the built in IDE port. None of which is related to or caused by the North bridge.

The DMA fix simply reroutes the signals and eliminates the unwanted garbage.

The USB Fix done at the same time is to fix a simple design screw up.
By replacing capacitors with pullup resistors.

You people are arguing about different things.

Hope this helps

Kgrach

@kgrach

Eh, I'm afraid that you're wrong. The April's *main* job was to fix the cache coherency issue.
Linux and other OSes work on the Peg1/April2 with generic drivers. The cache coherency issue is an ArticiaS issue, not Peg. It can be worked around with drivers written with it in mind but do not expect anyone to rewrite all linux drivers.

_________________

@AMiGR

So have you tried uA1c Linux to see if these MACH chips provide the magic answer you believe they have?

@AMiGR

There were two issues with the ArticiaS. One was fixed with a 3rd revision of the chip as used in the XE or later or April 1 or the wire fix, the other was suppossed to be worked around by April 1 ( at a huge performance loss - constantly resetting ArticiaS ). The second problem is the so called 'cache coherency' issue.

@Wiffy

Well, nope, but since people I trust (on your side) claim that it fixed the Cache Coherency issue, I've got no reason to disbelieve them.

_________________

@Wiffy

The cache coherency issue was the one that was fixed by the April 1 (at a big memory performance loss, I would guess that it flushes the cache after DMA operations), plus the "wire fix". The April2 fixed various other lockups. Problems left were: The G4 issue (I would guess that this was a combination of the Pegasos layout and ArticiaS' weak signal drive, which causes the memory compatibility problem afaik, the lines might have been too long) and the AGPGART issue. I would guess that all things fixed by the April2 (the April 1 and the wire fix are 2 totally different things) are fixed on the micro, probably better, since much time has passed since then, enough time to find better solutions.

_________________

@AMiGR

I dont have a side, a few edges and a corner maybe.

I think what has happenned is that there are three things here:

1. The defect in the ArticiaS in the Pegasos1 and the AmigaONE SE.
2. The 'feature' in the ArticiaS used in the AmigaONE XE and uA1c.
3. The network/ide interface controller issue on the XE ( hangs, lockups, corruption using DMA on both at once regardless of 'cache coherency' setting or design in the OS ) which is not present on the uA1c.

I do not see how fixing (3) could have changed anything about how software operates around (2). Indeed it hasn't as far as I am aware. Thus if those MACH chips have been analysed by someone as having anything to do with modifying the 'feature' then either they are ####ting used car salesmen or those that only use Linux on the uA1c with the cache coherency patched kernel are doing something they needn't do. Personally I suspect the former through a desperate attempt to imply that the uA1c needed to be 'Aprilled' as 'everyone claimed in 2002'.

But again, considering a working DMA enabled Linux exists on the uA1c, and that AmigaOS which is why we are here works just fine on it ( aside from a few minor CPU related bugs which is a firmware/software issue ) I don't see why we are sitting here still talking about this two years later.

But don't let me stand in anyones way over this. In the meantime Ill continue to enjoy my uA1 and what a fine piece of hardware it is too.

Regards

Dave.

Last edited by Wiffy on 04-Jun-2005 at 08:53 AM.

@AMiGR

The CPU issue is purely a Pegasos related problem. The XE works fine with being plugged with different CPUs in the CPU socket ( as I can attest ). But Im sure some way to blame the ArticiaS has to be found for the look of the thing.

@Wiffy

I am talking about 1&2. 3 is a southbridge problem apparently, I was not talking about it.

Quote:

ut again, considering a working DMA enabled Linux exists on the uA1c, and that AmigaOS which is why we are here works just fine on it ( aside from a few minor CPU related bugs which is a firmware/software issue ) I don't see why we are sitting here still talking about this two years later.

Ehm, that's exactly what I'm saying, in case you misread me. DMA enabled Linux exists on the uA1C, as the cache coherency issue is fixed.

_________________

@Wiffy

Read what I wrote again, please. It's a Pegasos issue in conjuction with the ArticiaS. It seems that the CPU card introduces much longer signal paths, which in conjuction with the weak signal drive cause the G4 problem on the Pegasos1. That's my bet. The longer signal paths are a Pegasos issue of course.

Since MAI designed the other boards, they did know to keep them short to stay in spec with the ArticiaS of course, so no problem with the A1s. But still, I do not rule out the possibility that the Peg1 design is in spec with the original ArticiaS documentation (which also mentioned that the chip DOES have cache coherency).

Last edited by AMiGR on 04-Jun-2005 at 09:08 AM.

_________________

@AMiGR

No, it has to be used with the 'cache coherency kernel', as far as I am aware. So we are totally disagreeing. I am saying that the fact people have to use the cache coherency based kernel on the uA1c kind of implies those MACH chips that someone has identified aren't doing what the someone has identified.

Anyhow, Im downloading the latest and greatest distro source and binaries for the uA1c today so should be able to see for myself.

Either way, it works, so it hardly matters anyhow.

@Wiffy

Well, it's easy to see what fixes what. If the kernel you're using on the micro works nicely but does not work on the XE, it means that the cache coherency issue is fixed on the micro.

_________________

@AMiGR

I read it, and I don't believe I need to modify my response in the slightest.

Quote:

ArticiaS' weak signal drive

Naughty ArticiaS! Naughty!

@Wiffy

Will you stop being defensive for a second? I'm not flaming you, we're having a conversation here, for god's sake! The weak signal drive is what causes the incompatibility with many DIMMs, isn't it? Am I making this up too?

Oh, and note that I still use a Pegasos1, so any ArticiaS issues fixed in the latest Linux kernel are in my best interest, *especially* AGPGART.

Last edited by AMiGR on 04-Jun-2005 at 09:12 AM.

_________________

@AMiGR

I already know that the Linux that 'doesnt work' on the XE also 'doesnt work' on the uA1c.

I haven't tried it with a sil card on the uA1c yet, and if the 'not working' Linux works on the sil card then its not an articia-S problem now is it?

The 'working' Linux ( for the third time now ) is a specially built kernel with software cache coherency, IIRC.

@AMiGR

Never said you were flaming me, you think Im samface or something? I tend not to put smileys or monty python images in defensive posts, at least mostly.