AmigaWorld has interviewed Alan Redhouse, the managing director of the Eyetech Group, regarding the AmigaOne motherboards. Alan is trying to push AmigaOS4, LinuxPPC and the AmigaOne boards into new markets. For instance earlier this year he did presentations in Taipei and Beijing.
That’s the first time I see that there are bug because you don’t use a
feature….
really : ROTFL
Part of the DMA problems of the past was a lack of support for this feature in LinuxPPC drivers.
So it’s not an ArticiaS bug, but the Linux drivers needed to be altered to take advantage of the simultaneous memory access by both the CPU and a PCI bus master.
With the worst case scenario in the past this meant that DMA had to be disabled to prevent problems (until altered). So not that big of a deal and a non-issue with regard to AmigaOS4 anyway.
Similarly Linux ports to classic Amiga hardware did not take full advantage the hardware like AmigaOS did., For example some of the hardware’s multi-processing capabilities and multi-resolution screen displays etc.
Oh come now, how can something malfunction when not using a supposed “feature”, but the standard *documented* way of doing things if it’s not a bug?
It’s like your data getting corrupted because you use PIO access on your HDs instead of DMA, would you say that it’s because you don’t use DMA, or because PIO mode is bugged? .. it just doesn’t make any sense dismissing this obvious bug as a feature…
– CISC
When the OS is unaware of certain hardware features this may cause trouble. For example AmigaOS 1.0 may not function properly on a far more featureful but still compatible 68060 CPU (compared to the original 68000).
So with regard to this past problem, was this a hardware bug or not?
IMO no, as an OS like AmigaOS4 will use this feature to its advantage without any problem or sacrifice.
So was it a software “bug” then?
IMO at least an incompatibility when seen as a complete provided solution, as the combination LinuxPPC drivers/ArticiaS were not fully compatible with regard to their DMA functionality.
However for example 68k Linux does run on classic Amiga hardware, but is unable to take full advantage of all the provided hardware features due to its design. For example Linux (or Windows/MacOS for that matter) is simply unable to display various resolutions simultaniously within one screen like the hardware supports. Does this really mean that the hardware or Linux is bugged? IMO it does not, modern x86 hardware and x86 OSes simply lack this functionality so their feature set is not the same.
Due to the fact that AmigaOS can take full advantage of the classic Amiga hardware, you could boot into a GUI system and do some neat pre-emptive multi-tasking (e.g. Music Player in background, Format a diskette, do some painting, etc) simultaneously with a 7 Mhz CPU.
This is largely due AmigaOS’ ability to take full advantage of the hardware’s multi-proccesing features. Linux on a 7 Mhz Amiga would be almost useless and forget about using a GUI or things like movie editing (e.g. you on a 7Mhz you could mix animations with PAL/NTSC video or add subtitlings, etc) with such specifications!
It’s pretty simple really, in the case of the 68060, it actually *lacks* features, which has to be replaced by software, this is all well documented by Motorola, however in the case of the ArticiaS it’s *documented* features do not work properly, and the claim put forward by Mr Redhouse is that it’s due to *not* using an *undocumented* “feature”, which is pretty bizarre to say the least…
..and this kind of bizarre thinking is further illustrated with your Linux analogy .. what exactly would the fact that Linux does not take full use of hardware features of the Amiga have to do with bugs? It doesn’t use the features, and you are non-the-wiser, the system still works as expected, it just doesn’t do this thing that’s quite specific to this certain hardware, it has no effect whatsoever on the system as a whole…
It would be quite another thing if the ArticiaS simply would be missing a feature and this was documented as missing, but this is not the case .. it has a documented feature, and this feature does not work as documented – and might I add, how *all* other northbridges work – ergo it is a bug.
– CISC
@ Sigbjørn
> It’s pretty simple really, in the case of the 68060, it
> actually *lacks* features
What I am trying to say is that OSes need to be altered to take into account differences of the underlying hardware. For instance AmigaOS3.1 does run without changes on 68000 and all the way up to 68060 level CPUs.
The way DMA is supported by the ArticiaS simply wasn’t supported properly by the Linux drivers. Sadly this problem wasn’t obvious and harder to find due to the VIA bug. So what the developers had to do was to add code to the drivers which would tell Linux how to properly handle the ArticiaS’ way of handling DMA.
This feature is not a bug, but instead this feature is differently implemented than is the case on x86 hardware and thus Linux. Similarly the classic Amiga’s well documented feature to display multiple screens using multiple color depths and resolutions simultaneously isn’t a bug, it’s simply a feature Linux cannot benefit from at all due to its design.
BTW which features does the 68060 lack compared to the 68000?
@ Sigbjørn
> it actually *lacks* features, which has to be replaced
> by software, this is all well documented by Motorola
I believe you may be confusing Motorola’s Coldfire CPUs (used in the embedded market in vast quantities) with their 68060 range of CPUs.
@ Sigbjørn
> it has no effect whatsoever on the system as a whole…
And just in case you missed it, with the altered Linux drivers taking into account this hardware feature, the DMA functions normally.
A great interview!
The install 3.1 boot disk crash a whole system if the 68060.library
hasn’t been copied on it before that’s a fact… and yes, the 68060
lack some instructions compared to a 68000.
@ Joël EHRET
You probably own an upgraded Amiga?
Although the mentioned 68040/060 libraries do emulate certain missing 68882 (FPU) instructions, please note that the 68000 did not include an FPU (nor MMU in fact). The A4000 desktop originally shipped with a 25 MHz 68030/68882 combo or 25 MHz 68040 CPU and version 3.0 of AmigaOS.
The Amiga4000T/060 came with a 68060 CPU and version 3.1 of AmigaOS supplied.
I know the Coldfire does lack certain 68k instructions, but AFAIK the 68060 does include all the functionality provided by the 68000 CPU, but has an very different design and implementation and that’s why I used it as an example.
No, I’m not confusing it with the ColdFire, but I was comparing against 68020, which supports DIVS/U/L.L and MULS/U.L, and the 68060 does not, and it’s missing almost the entire FPU register set (but as you say, FPU used to be separate anyway)…
Anyway, back on subject, the altered drivers don’t take any “feature” at all into account, they simply try to avoid the problem with the already documented feature (how many times do I have to stress this before it sinks in?) by introducing cache stalls at strategic places (which apparently even the authors (or MAI themselves) of the fix don’t know why works in the first place) .. this is a pretty flakey “fix” to say the least, and I think most people won’t be satisfied that it does indeed really fix the issue until there has been properly executed third party tests (the previous inhouse tests have been proven wrong several times already (otherwise we wouldn’t be discussing this issue here today)).
– CISC
The 68000 has several instructions not found in the 68060… nor even the 68020. Those are well documented and state “do not use these opcodes for upward-mobile software as it will break on any future revisions of this chip.”
Atari learned this the hard way when their version of GEM used these codes, and required an almost total re-write when they released 020 and up machines, costing them almost a year in the process. It is also why Atari computers continued running the 68000 processor for longer periods than any other desktop, including the Amiga. (last Amiga that came with the 68000 was the A600 or the CDTV, I can’t recall which, while the last Atari produced running it was built well into the A1200/A4000 era)
This is so old discussion. There is no way Hyperion and Mai are going to get this ‘fix’ of theirs into Linux Kernel Tree. There are plenty of people who do understand basic issues of computers like Cache Coherency (and lack of it) and how big performance hit implementing these suggested workarounds will be.
Expecting Chinese to purchase this system without any reserch is quite blindsighted. Meanwhile AlanR has been there couple times talking, companies like Sun and AMD are doing real deals. And why .. they have real product and can back their marketting with facts.
For example: http://www.theregister.co.uk/content/54/34068.html
Sun delivering a Million Java Desktops with Staroffice to china in Next year alone. Those machines are cheaper, faster and have proven os and office packege.
Hello,
It would be very interesting if you could provide ANY other northbridge that supports two totaly transparent (to eachother) transfers on the same bus, it’s pretty clear AmigaOne (the Pegasos obviously fixed this “feature/bug” in hardware) is the ONLY PowerPC that has this “standard”, Macintosh DOES not, and honestly I don’t know of ANY other architecture that supports it, which leads me to the conclusion that MAI is obviously pioneers on this area ?
Please think about it; do you find it likely that it’s a “normal” behavior ?
(And no before anyone says something, I’m not affiliated with either bplan/gensi; I own a pegasos though; but it could just as well been an AmigaOne if it wasn’t due to this “feature/bug”)
@ Sigbjørn Skjæret
> but I was comparing against 68020, which supports
> DIVS/U/L.L and MULS/U.L, and the 68060 does not
Do you know some links to articles explaining these CPU differences in more detail and I am especially interested how this relates to AmigaOS.
Something like the following document, which expains the differences between Coldfire/68k.
http://www.microapl.co.uk/Porting/ColdFire/cf_68k_diffs.html
I know The 68020 adds a number of enhancements to the 68000 architecture (including new addressing modes and instructions) which could cause incompatibilities issues like for instance timing problems, but never could find documentation suggesting the 68020 lacks in areas in comparison.
@ JoannaK
> There is no way Hyperion and Mai are going to get
> this ‘fix’ of theirs into Linux Kernel Tree.
The nice thing about Linux is that you don’t have to ask permission to anyone.
@ Fredrik Andersson
> but it could just as well been an AmigaOne if it wasn’t
> due to this “feature/bug”
IMO then you have been misled by the Propaganda. Like I stated a long time ago, bPlan’s Pegasos board performs with regard to Linux just as well as the long discontinued AmigaOne-SE 600 Mhz G3 board. The Genesi followers claimed that I was incorrect despite I tested both hardware for quite a while. Afterwards there were comparisons suggesting I was correct, but even until today I have never have seen any proof that the April1/2 were wonder chips and as claimed that the Pegasos G3 @ 600 Mhz would outperform the G4 AmigaOnes…. Personally I would recommend you to test the AmigaOne yourself before making judgements.
You lost the key point. Without becoming part of standard Linux distrobutions they (Mai,Eyetech,Hyperion) have no chance on getting sales for that board. You’ll need to have installation and latest kernels available from Disto maker before any serious users consider your motherboard. Like it is now (= bunch of homemade patches) it’s just outcast, pariah..
This is double as important when system is from unknown manufacturer(s) who have no name nor any proven products. Actually, on this case.. Mai has no positive references to show, only bunch of companies who have pulled out from their products. Their current Linux needs rework (as admitted, even though IMHO they are barking on wrong tree when blaming Linux to be buggy) and their only other OS is months away for being in condition to demonstrate to anyone but fanclub.
As you well know.. this is three year old product. And on this business it’s a lot. They are becoming relics before never making it happen. With years old technology and inflated prices, they are highly unlikely to make much sales.
Well, just go find Motorola’s PRM/PEM’s for the 68k series, they have a nice chart of what instructions are supported where…
Uhm, you *do* need permission to get a patch submitted into the Linux maintree (if you didn’t, we’d all be in trouble a long time ago)…
As for propaganda, have you ever stopped to think that perhaps it has been you that have been misled, and subsequently spreading this propaganda yourself? Just take this very issue .. how many times have you been told that there never was any problem whatsoever with the ArticiaS, yet here we are today discussing the very problem (data corruption) that others have been trying to tell you has been there all along .. and to make matters worse, you won’t even recognize that the April does, among other things, fix this very problem! You cannot deny it, it has been proven, over and over again, by extremely simple tests, such as repeatedly checking the md5sum of a file .. several independent people have tested this, both on Pegasos and AmigaOne .. on Pegasos with April, the md5sum is always the same, on AmigaOne it changes every so often .. this is a real problem, no lies, no propaganda…
But let’s hope *this* fix finally fixes the problem on AmigaOne for good, as it really needs to have this fixed if it is to have any chance in the real world whatsoever .. but you better make damn sure everyone who ever wants to make/port an OS to it have full details on how to avoid data corruption (pity it means *alot* of work “fixing” every driver in existing OS’, as this may discourage alot)…
– CISC
@ Sigbjørn Skjæret
> Well, just go find Motorola’s PRM/PEM’s for the 68k
> series
Where? At Motorola.com?
> Just take this very issue .. how many times have you
> been told that there never was any problem whatsoever
> with the ArticiaS, yet here we are today discussing the
> very problem (data corruption) that others have been
> trying to tell you has been there all along
Incorrect, what I have *always* stated was that people who think that modern hardware is completely bug free is living in a fantasy world. IMO what is important is that if a (significant enough) bug/problem has been discovered, how this can be fixed (as is the case with regard to both VIA bugs and ArticiaS/Linux incompatibilities) or not. In fact I have often compared this to the many known bugs of the classic Amiga hardware. With regard to if such problems are fixed through a hardware patch or software patch, well I only care about the end result.
I heard that the April2/Peg there are still some issues to be solved, but I don’t know if this has to do with the fact that AmigaOne-XE boards ship with the latest Revision Articia chips and the Pegasos do not.
Another thing I have stated is that the ArticiaS is of excellent quality and that both AmigaOne and Pegasos1 boards are IMO equally good as Linux platforms.
What I have also stated is that the AmigaOne-XE has gone through extensive testing and these tests suggest that we are dealing with good quality hardware. I have never stated that there would never be any problems in some ackward situations people may never actually encounter. (This counts for any modern/complex hardware IMO)
But of course with regard to the AmigaOne one had always the option (a worst case scenerio) to disable DMA until any fear for DMA problems were fixed. And I still stand by all I have written above within this message.
@ Sigbjørn Skjæret
> Uhm, you *do* need permission to get a patch submitted
> into the Linux maintree
I don’t see why that would be needed. Anyone could use the adapted Linux kernel for the AmigaOne without problem.
It’s not like the AmigaOne is mainstream hardware anyway, just like the Pegasos, Playstation2, classic Amiga, etc aren’t. The kernel would be adapted specificly for the hardware anyway.
>The kernel would be adapted specificly for the hardware
>anyway.
Well it’s a good thing only 1 Linux distro runs on the AmigaOne then! If the feature/bug “patch” (the patch officially exists now, does it?) isn’t in the main Linux tree, it’ll have to re-applied to every port of each distro.
I really hope some full pro Linux guru could explain this to you. But I’ll try to do my best and explain this in simple terms.
Linux is based on Open source.. Everything running on machine is available on source level. At the first thing any potential client want’s is to access to full source unless system runs on standard Distro. Linux people won’t accept anything less and they are suspicious to any hack/patch stuff.
Every Linux user/coder knows that these machine-specific patches need constant maintaining, and are likely to break on next kernel/driver update. And those updates are common on Linux world, it’s under heavy development and it’s moving on with considerable speed.
As you said. They (Mai/Hyperion) could Disable Ide DMA as it helps a little, but that’s only one device.. That won’t help on USB, SCSI, Ethernet and any other devices that use DMA to move data. Besides.. Using PIO-mode for hard disk hits so badly to system performance it’s definitely ByeBye to all Linux-sales.
And AmigaOne has to get sales from mainstream markets. There are not enough Amiga-fans to make enough sales as Mai need a lot sold chipsets to justify and finance development of future products.
Heh, where do all the blue people come from? Is some MOS/Peg site linking here?
I think it would be a very bad idea to make platform specific driver changes part of the main Linux kernel source code tree. Especially considering this bloat would have no use on x86 hardware as this feature isn’t supported there anyway.
I also believe most Linux people are more used to patching/hacking their operating system than anyone else, including even us (ex-)AmigaOS supporters. To think a driver update would scare these people or companies away is IMO unfounded.
@ smithy
Just read the interview, Alan:
“The second problem is that many PPC-ported Linux drivers (which we must not forget were developed for the x86 environment) have often implicitly relied on the fact that Intel architecture prevents simultaneous memory access by the CPU and a PCI bus master. In the AmigaOne both processes operate simultaneously and transparently to each other and so some of the ported drivers fail under extreme pressure. IDE DMA drivers have been modified to make them behave properly on the AmigaOne and a universally applicable OS patch is now in test. We believe that this is a much better solution than to throttle back the simultaneous memory access with a hardware dongle as has been tried by others.
These issues are exclusive to the PPC port of Linux and are irrelevant under OS4.”
At this point I’d like to ask Eugenia herself to see this and ask opinions from Linux and MacOSX gurus.. There must be some around here who can explain Real life facts cause apparently my word ain’t goodenough.
I’m not sure about this color-paranoia of yours but it definitely hinders this site and makes it look Amateurish. I know this PPC-stuff quite well cause I have done Embedded PPC hardware design/testing for my living. I need to read and understand thousand page datasheets and I need to see through marketting Whitewash so I can avoid making stupid decisions that would not only cost a lot of $$$ but also perhaps a client and jeopardize my job.
And I can tell that AlanR is speaking plain and simple marketting BS. There are no facts that prove this particular chip to be any better than alternativies made by IBM, Motorola, Apple, Marvell, Tundra etc.. All those do work fine under Linux and I’m pretty sure THEY do know a lot better what PowerPC is capable on than one marketroid…
And .. besides that you’ll better check what those X86 chipsets are able to do. They could teach Articia-S a lot about how things should work. Afterall they are generations ahead on every aspect of chipset design, features, speed and making.