29-Mar-2024 10:01 GMT.
UNDER CONSTRUCTION
Anonymous, there are 290 items in your selection (but only 90 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 290]
[News] Ben Hermans about the A1 "bugs"ANN.lu
Posted on 23-Aug-2003 13:55 GMT by Amon_Re290 comments
View flat
View list
We're testing a patch for the U-Boot / Linux Kernel which takes care of all USB related issues and IDE to IDE DMA transfers which now work 100% reliable.

(Thanks to Adam and Mai Labs for their efforts.)

This was accomplished by tinkering with the VIA 686B settings, nothing else, conclusively proving that the issues are related to that Southbridge and not to the Articia S.

All IRQ' are routed through the VIA 686B and most if not all issues appear to be related to unserviced interrupts.

Hopefully this will end all the FUD about these issue's once & for all. Read the original post here.

Ben Hermans about the A1 "bugs" : Comment 201 of 290ANN.lu
Posted by tarbos on 25-Aug-2003 03:09 GMT
In reply to Comment 196 (Anonymous):
The Motorola ATX MVP platform is another board that uses the VIA 686B...http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MVPX3
Ben Hermans about the A1 "bugs" : Comment 202 of 290ANN.lu
Posted by Amon_Re on 25-Aug-2003 03:29 GMT
In reply to Comment 193 (Anonymous):
Like i said, they are different from design to the A1 or Teron or Pegasos boards, you are comparing apples & oranges.

Also, how do you know there are no further fixes in the BIOS of said machine?

Cheers
Ben Hermans about the A1 "bugs" : Comment 203 of 290ANN.lu
Posted by hammer on 25-Aug-2003 04:04 GMT
In reply to Comment 1 (Anonymous):
>It can mean that the sofwtare fix is used because they don't have enough >money (SNIP)
Note that MSI (Micro-Star International) didn't issue a hardware fix for 686B in MSI-6330 KT7 Turbo Limited V3 and V5. MSI > Genesi in terms of capitalisation.
Ben Hermans about the A1 "bugs" : Comment 204 of 290ANN.lu
Posted by Anonymous on 25-Aug-2003 04:33 GMT
In reply to Comment 200 (tarbos):
Allright, that seems to be a PPC end-user computer that uses a VIA 686. Thank you for your polite, non-smartass reply. I suspect that since IBM recommends Linux for that computer, no-one will hit any VIA-related glitches - as others have already mentioned, Linux has behaved correctly wrt this chipset for some time now.
Ben Hermans about the A1 "bugs" : Comment 205 of 290ANN.lu
Posted by priest on 25-Aug-2003 05:07 GMT
In reply to Comment 151 (bbrv):
"finish OS4. When this is done you will have accomplished something"

oops!
Ben Hermans about the A1 "bugs" : Comment 206 of 290ANN.lu
Posted by Fabio Alemagna on 25-Aug-2003 05:21 GMT
In reply to Comment 198 (James Carroll):
> No april required? AmigaOne owners are reporting their machines working fine
> without the April fix.

AmigaONE owners have the fix already onboard, thanks to Gerald Carda.

> The only small glitch being the VIA bugs,

It's unproven it's a VIA's bug, just because the BUG gets hidden by tweaking with the VIA chip's settings it doesn't mean it's a VIA's bug.

> which have just now been fixed up. Why does the PegasosI need the April fix
> and the AmigaOne doesnt?

As said, and as Neko said, the AmigaONE also has an HW fix already onboard, which has to be coupled with a SW fix. April I does the same as the HW fix on the AmigaONE, and April II does the same as the AmigaONE's fix + sw patches.
Ben Hermans about the A1 "bugs" : Comment 207 of 290ANN.lu
Posted by Anonymous on 25-Aug-2003 05:24 GMT
In reply to Comment 206 (Fabio Alemagna):
"AmigaONE owners have the fix already onboard, thanks to Gerald Carda."

This is what I don't get - and this is a genuine question, I'm not trying to troll here - why did Genesi, after spending so much effort in developing a fix and apparently just giving it to Mai, decide to go for a different chipset for the P2?
Ben Hermans about the A1 "bugs" : Comment 208 of 290ANN.lu
Posted by Pete on 25-Aug-2003 06:03 GMT
There is no particular problem with the VIA 686B when it's used correctly. And Linux use it correctly since beginning 2002.

And whatever the firmware can do, Linux doesn't care of it, as Linux driver for the VIA 686B re-initialize it and so even if the firmware did a bad thing, this shouldn't matter for Linux. Of course this can be important for AmigaOS 4 if AmigaOS 4 doesn't reinitialize it after...

So if there is still a problem with the AOne under linux this can't be only the VIA 686B as I already said. Something else in the motherboard "help" to make this problem happens.

Also a general note about fixes: Software fixes for hardware bugs are ALWAYS worse than hardware fixes.

Considering the problems i've seen on AOne, I personally not consider it as a viable hardware and a software fix/workaround (at it seems more to be that) will not make it more viable for me. Only a GOOD hardware fix would make it viable in my eyes.
Ben Hermans about the A1 "bugs" : Comment 209 of 290ANN.lu
Posted by Anonymous on 25-Aug-2003 07:06 GMT
nothing like a pro-A1 post to bring out a >200 thread.

quick cleanp.

1) This allows proper DMA. using the "nodma" Linux option disabled DMA fully

2) Pegasos can also avoid this problem...not with April, but just with some correct code and register value settings in their OpenFirmware setup

3) VIA is known for a long long time to have rather buggy products. thats why the #1 download that i force PC users to get is the via 4-in-1 patch
Ben Hermans about the A1 "bugs" : Comment 210 of 290ANN.lu
Posted by Phill on 25-Aug-2003 07:11 GMT
In reply to Comment 208 (Pete):
It's pretty obvious that this VIA chip needs kludges to work, try running an unpatched operating system on one. It should also be pretty obvious that a kludge relies on certain side effects to work. Change the situations it's working in and the kludge doesn't work anymore, this is what seperates a kludge from a design.

Go back and read the Amiga RKM's, you will find a number of kludges that you need to perform there too ( writing to the disk dma "randomly" dropping the last two words etc ). Then you have to match certain zorro 3 cards with certain buster revisions etc.

Whether you scrap your product and go back to the drawing board or whether you work round the issues as best you can is a choice that isn't always available. It's certainly not worth the effort of arguing over, as it will only end up as a religious choice anyway.

If you really have time to sit there thinking up conspiracy theories then there are much better subjects. You can only go on the word of the people that say they have identified the problem as a VIA initialisation problem, unless you have the correct skills to put forward more compelling evidence. Putting up straw man arguments, and in most cases contradicting purely on which faith you belong to, is pointless and only perpetuates the Amiga weirdo image.

Phill
Ben Hermans about the A1 "bugs" : Comment 211 of 290ANN.lu
Posted by Amon_Re on 25-Aug-2003 08:23 GMT
In reply to Comment 208 (Pete):
Again, Pete, i don't agree with you.

And how do you explain the problem with the pegasos 1 and the secondary IDE channel?

You sound so sure of yourself, yet you seem unable to come up with anything convincing enough, sadly

Cheers
Ben Hermans about the A1 "bugs" : Comment 212 of 290ANN.lu
Posted by vortexau on 25-Aug-2003 09:25 GMT
In reply to Comment 167 (BrianK):
> In Reply to Comment 47:
> You're wrong the last working Amiga was the A4000T.

Hmmm! 'seems I have a 'working A2000', a 'working CD32',
and a 'working A1200'.

I'd think that there are folk with A1000s that still work!
CBM built them to LAST! :-)
Ben Hermans about the A1 "bugs" : Comment 213 of 290ANN.lu
Posted by Pete on 25-Aug-2003 09:29 GMT
In reply to Comment 211 (Amon_Re):
-> Amon_Re

"Again, Pete, i don't agree with you.

And how do you explain the problem with the pegasos 1 and the secondary IDE channel?"

This is not the same problem. Yes this problem is related to the VIA 8231. The problem on the AOnes is a trashed datas problem.

"You sound so sure of yourself, yet you seem unable to come up with anything convincing enough, sadly"

As I said Linux don't use the BIOS/Firmware initialisation and re-initialise all the hardware. The VIA 686B used by the AOne is fully supported by Linux since beginning 2002, which include all the necessary fixes/workarounds. It perform perfectly well on PC using the same southbrige (VIA 686B) and there is no reason that it should not work as much well on the AOne, except if something else have issues on the motherboard.

If you can't understand that and be convinced about that, then I'm sorry I think I won't be able to convince you :(
Ben Hermans about the A1 "bugs" : Comment 214 of 290ANN.lu
Posted by BrianK on 25-Aug-2003 09:34 GMT
In reply to Comment 212 (vortexau):
If you'd followed the thread by reading the comment prior you'd see that person called the 'last working Amiga' as the last shipping model. Thus, what you said while fitting into the statement didn't fit the context. But, thanks we all know there's lots of working Amiga's out there. I have an A1000 that works I don't often use it but boot it up about once or twice a year for fun.
Ben Hermans about the A1 "bugs" : Comment 215 of 290ANN.lu
Posted by vortexau on 25-Aug-2003 10:08 GMT
In reply to Comment 214 (BrianK):
> In Reply to Comment 212:
> If you'd followed the thread by reading the comment prior
> you'd see that person called the 'last working Amiga' as
> the last shipping model.

You DID notice that *smilie* in my post, didn't you? :-)

BTW, I'd have reaconed that the *Wonder TV A6000 and A6060*
(Lotus Pacific - 1998) and *The Access* (Index Information
- 1998) still qualify as Amigas!
"The Access system offers around 2.3x the average performance of an A1200, with 30% increase in Chip RAM access."
Ben Hermans about the A1 "bugs" : Comment 216 of 290ANN.lu
Posted by Amon_Re on 25-Aug-2003 10:51 GMT
In reply to Comment 213 (Pete):
Pete,

The problem is that yes, the A1 isn't like any generic x86 machine, that's precisely the point, it's not a data trashing problem, it's an unserviced IRQ's problem, perhaps we should get the datasheet for the ArticiaS & for a generic x86 northbridge, put them aside, and start comparing them.

I agree that the patches in the linux distributions were there, but these weren't suited for the A1, some others have raised other VIA equiped machines running on PPC, but again, there are huge differences between these & the A1.

Are the VIA issue's being shown because of a flaw in the ArticiaS? No, i don't think so, it's not logical (For one, Mai would have fixed it by now if it really was the ArticiaS at fault)

Are the VIA issue's being shown because a problem with existing patches? More likely, because most, if not all of these patches originate from the x86 world, also, there was a problem with the commands being used to drive the VIA, something to do with the EDGE & LEVEL commands, perhaps Olegil could explain those.

Are the VIA issue's a hardware fault? Most unlikely, otherwise tweaking the drivers/patching the init wouldn't solve it at all.

I hope this came out readable ;)

Cheers
Ben Hermans about the A1 "bugs" : Comment 217 of 290ANN.lu
Posted by samface on 25-Aug-2003 11:05 GMT
In reply to Comment 213 (Pete):
>The VIA 686B used by the AOne is fully supported by Linux since beginning
>2002, which include all the necessary fixes/workarounds. It perform perfectly
>well on PC using the same southbrige (VIA 686B) and there is no reason that it
>should not work as much well on the AOne, except if something else have issues
>on the motherboard.

I fail to see why it would somehow not be an issue for PPC motherboards using the VIA 686B anymore simply because it has been fixed for x86 motherboards using the VIA 686B. Care to tell me how and with what motherboard they managed to fix this?

Furthermore, using hardware to fix software issues is never a good idea.
Ben Hermans about the A1 "bugs" : Comment 218 of 290ANN.lu
Posted by Anonymous on 25-Aug-2003 11:21 GMT
In reply to Comment 216 (Amon_Re):
>Are the VIA issue's a hardware fault? Most unlikely, otherwise tweaking the drivers/patching the init wouldn't solve it at all.

That's nonsense, frankly speaking.
Ben Hermans about the A1 "bugs" : Comment 219 of 290ANN.lu
Posted by Amon_Re on 25-Aug-2003 11:32 GMT
In reply to Comment 218 (Anonymous):
Ok now that settled it for me, how could i miss such obvious facts!

If someone says i'm wrong, whom am i to question them? After all, they didn't use any logic to correct me, they just stated it witch sush authority that it *must* be truth!

Thank you so much for educating little old me!

</sarcasm>

If it were a hardware related problem, please do explain it, because i fail to see it.

IIRC the problem was partially related to the way they used LEVEL & EDGE, one of these commands isn't recommended by VIA themselves because it causes problems, but the original drivers used that one (don't remember if it was EDGE or LEVEL).

And how can initiating something differently be a hardwareproblem? The only hardware at fault here would be the VIA one.

Hmm, so technicly you *were* right after all, but you held the wrong chip at fault

Cheers
Ben Hermans about the A1 "bugs" : Comment 220 of 290ANN.lu
Posted by Pete on 25-Aug-2003 11:33 GMT
In reply to Comment 217 (samface):
-> samface

"I fail to see why it would somehow not be an issue for PPC motherboards using the VIA 686B anymore simply because it has been fixed for x86 motherboards using the VIA 686B. Care to tell me how and with what motherboard they managed to fix this?"

Because it a general fix that has been made to work for all architectures. So PPC included.

"Furthermore, using hardware to fix software issues is never a good idea."

This is an hardware issue!
Ben Hermans about the A1 "bugs" : Comment 221 of 290ANN.lu
Posted by Amon_Re on 25-Aug-2003 12:23 GMT
In reply to Comment 220 (Pete):
How in heavens name do you think you can prove it?

If a rewrite of the initcode/driver solves the problem, why is it so impossible for you to accept that it *is* a software issue?

It might be coupled to the ArticiaS, but that doesn't change the fact that the driver are/were at fault in the first place.

Cheers
Ben Hermans about the A1 "bugs" : Comment 222 of 290ANN.lu
Posted by PegasosII!? on 25-Aug-2003 13:28 GMT
Hi BBRV!
In May/June we all read everywhere that "in September or probably BEFORE" (these are your words) we will have had PegasosII ready in shops. Heem, where is it?!?
September is arrived, it is next week and we have seen no one photo or video of PegasosII (also a prototype would be enough...) running MorphOS.
Will we have the usual frustrating delays you accustom us!? Like with the first Pegasos (with all the announcments regarding the date of new stocks to sell not respected), the 1.4 that had to be out for the 26July that not respected its date, the SBundle also delayed and PegXLin that is ready for weeks but still not on the FTP?
Please let's not discuss if these delays are important or irrilevant for you, tell us only if we will have another one as always.
I know my words can be a bit fastidious and not so nice to hear but you can understand that all your customers are really really really annoyed by ALL your ***TOO OPTIMISTIC ANNOUNCMENTS.***
There has been NO ONE your announcment in what a date appeared that has been confirmed by facts. No one. No one date respected.
Please tell us about PegasosII: will it be out in september or no? Have you a mobo already running or not?
Thanks a lot for the eventual answer and sorry again if these line are a bit "hot". I'm a big MOS fun, but not so much a BBuck fun :-p Sorry!
Ben Hermans about the A1 "bugs" : Comment 223 of 290ANN.lu
Posted by Neko on 25-Aug-2003 14:02 GMT
In reply to Comment 137 (Anonymous):
> So when Pegasos will be available via let's say Microwarehouse it's
> considered a standard board by you?

When we start making it again :D

=Neko=
Ben Hermans about the A1 "bugs" : Comment 224 of 290ANN.lu
Posted by Neko on 25-Aug-2003 14:14 GMT
In reply to Comment 150 (Fabio Alemagna):
> > Having said that, I'm still laughing because bPlan killed off a working
> > hardware platform for which they had just provided two expensive hardware
> > fixes which can apparently be sorted out in software.
>
> Neko has provided you with all the explanations you need, how about starting
> to read and stop to laugh?

Thanks, Fabio.

The crux of the matter is: we didn't throw away the Pegasos I and April II
designs simply because we "couldn't fix the bugs". We already fixed the bugs
already, both in the AmigaOne and Pegasos, regardless of how funny that sounds.

Anything Mai fixed in their latest revision was found and solved by Gerald
Carda. We still hold fast that not everything was fixed.. but.. irrelevant.

So, it wasn't about "working platforms". We dropped the Articia S because we
didn't like the experience of working with Mai.

It's important to have a good business relationship with the people who
supply your hardware, to the point that you can take such actions as put it
on a board in an unsupported configuration (Marvell with a G4), be trusted to
do the horsework of testing it, before the company signs off on it. Marvell
are happy to have their Northbridge (best available in the market at this
time..) certified for new processors by a skilled group of engineers.

This is exactly the same way that Hyperion are doing firmware work for Mai,
no punches pulled.

=Neko=
Ben Hermans about the A1 "bugs" : Comment 225 of 290ANN.lu
Posted by Anonymous on 25-Aug-2003 14:27 GMT
In reply to Comment 224 (Neko):
> The crux of the matter is: we didn't throw away the Pegasos I and April II
designs simply because we "couldn't fix the bugs". We already fixed the bugs
already, both in the AmigaOne and Pegasos, regardless of how funny that sounds.

Thats a claim which will be pretty hard to prove. The articia received a new revision and the only obvious thing is that this was done by Mai.

> Anything Mai fixed in their latest revision was found and solved by Gerald
Carda. We still hold fast that not everything was fixed.. but.. irrelevant.

Also a claim we would have to take your word for it and Im sorry but a certain persons actions and your general "press releases" concerning Mai stand in the way of me believing your party anything without proof.

> So, it wasn't about "working platforms". We dropped the Articia S because we
didn't like the experience of working with Mai.

Thats very true for Mai too and concerning the aforementioned "press releases" Id rather guess they dumped you. Getting down on your supplier never gets good results and at this point you seemed pretty certain the pegasos would continue to use the articia or where you just deceiving us and trying to sell a product you knew is faulty and obsolete?
Ben Hermans about the A1 "bugs" : Comment 226 of 290ANN.lu
Posted by samface on 25-Aug-2003 15:13 GMT
In reply to Comment 220 (Pete):
>Because it a general fix that has been made to work for all architectures. So
>PPC included.

LOL! Excuse me, but... how do you make general fixes for hardware that works with all architectures? I'm sorry but it sounds like you don't have a clue of what your talking about at all.

>"Furthermore, using hardware to fix software issues is never a good idea."
>
>This is an hardware issue!

If there is a flaw in the hardware, it's per definition not something you can fix with software tweaks or patches. Sure, you might be able to make work-arounds, but no "fix", period. MAI and Hyperion obviously found a way to "fix" this by software, which makes this problem a software problem rather than a hardware problem.
Ben Hermans about the A1 "bugs" : Comment 227 of 290ANN.lu
Posted by Pete on 25-Aug-2003 15:14 GMT
In reply to Comment 221 (Amon_Re):
-> Amon_Re

"How in heavens name do you think you can prove it?

If a rewrite of the initcode/driver solves the problem, why is it so impossible for you to accept that it *is* a software issue? "

Sorry but if the initcode/driver of Linux for the VIA 686B works fine in all the other motherboards using the VIA 686B but doesn't in the AmigaOne this can only mean that something in the AmigaOne board make this happen as the only difference in that case is the hardware (not the sofware which remain the same).

By this fact, this is obviously a hardware issue even if this can be work around or/and fixed by software tricks in the original driver code.

"It might be coupled to the ArticiaS, but that doesn't change the fact that the driver are/were at fault in the first place."

Having to change some code inside a driver for a specific platform doesn't mean it's a software issue. In fact it's the contrary. The driver works just perfect on all the other hardware, there is no reason at all that it'd not work on the AOne, except an hardware issue that make it not working well. Software fixes for specific hardware like AmigaOne/Teron boards are of course fixes for hardware issues, this is obvious. And this is the case here.
Ben Hermans about the A1 "bugs" : Comment 228 of 290ANN.lu
Posted by Pete on 25-Aug-2003 15:20 GMT
In reply to Comment 226 (samface):
-> Samface

" LOL! Excuse me, but... how do you make general fixes for hardware that works with all architectures? I'm sorry but it sounds like you don't have a clue of what your talking about at all. "

The fix is for the VIA 686B which is the same piece of hardware on the AOne than on the x86 box. When you want to make a fix for a chip that can be used in multiple architecture, you just have to take care that the fix have to be able to be run on the architectures supported by the chip. How the fix work remain of course the same as it's a fix for the VIA 686B chip that doesn't change and so that have to be fixed the same way.

So in the case of the fixes for the VIA 686B on Linux, when I say that they've been made to be able to work on all the architectures supported by the VIA 686B, that's mean that they are runnable and so fix the VIA 686B on all these architures.

If you can't understand that, then I'm sorry for you, but the one who is clueless is you in that case.
Ben Hermans about the A1 "bugs" : Comment 229 of 290ANN.lu
Posted by samface on 25-Aug-2003 15:22 GMT
In reply to Comment 227 (Pete):
>Having to change some code inside a driver for a specific platform doesn't
>mean it's a software issue. In fact it's the contrary.

There is no such thing as a hardware driver that works unmodified for all architectures, regardless if it's the same OS. This just goes to prove how very little you know about these things and should drop it now before you *really* put your foot in your mouth.
Ben Hermans about the A1 "bugs" : Comment 230 of 290ANN.lu
Posted by Pete on 25-Aug-2003 15:25 GMT
In reply to Comment 229 (samface):
-> Samface

">Having to change some code inside a driver for a specific platform doesn't
>mean it's a software issue. In fact it's the contrary.

There is no such thing as a hardware driver that works unmodified for all architectures, regardless if it's the same OS. This just goes to prove how very little you know about these things and should drop it now before you *really* put your foot in your mouth"

I'm sorry but you should learn to read also. What you commented is completely off topic regarding what you quoted.
Ben Hermans about the A1 "bugs" : Comment 231 of 290ANN.lu
Posted by samface on 25-Aug-2003 15:26 GMT
In reply to Comment 228 (Pete):
>How the fix work remain of course the same as it's a fix for the VIA 686B chip
>that doesn't change and so that have to be fixed the same way.

Different processor architectures -> different code for doing the exact same thing

Every "fix" implemented in Linux for x86 will have to be rewritten and reimplemented for each processor architecture. How many PPC motherboards uses the 686B again?
Ben Hermans about the A1 "bugs" : Comment 232 of 290ANN.lu
Posted by Pete on 25-Aug-2003 15:33 GMT
In reply to Comment 231 (samface):
-> Samface

" Every "fix" implemented in Linux for x86 will have to be rewritten and reimplemented for each processor architecture. "

You finally get it! Congrats :) This is what was done in that case.
Ben Hermans about the A1 "bugs" : Comment 233 of 290ANN.lu
Posted by Stefan Burström on 25-Aug-2003 15:43 GMT
In reply to Comment 231 (samface):
Guys, please before this gets silly, do some reading on hardware and software design.

First of all, if a system with chip A connected to chip B works, but a system with chip A connected to chip C doesnt then it does not mean that there is a problem in chip C. It may very well be that there are certain side effects in chip A that is causing this problem.
Today’s chips are usually filled with lots of different functions, so the way you partition a system is usually dependant on the way software running on the hardware programs the different chips. I have not seen many designs there has been exactly 1 piece of hardware for everything. Usually there are parts of different chips that can be used independently but in the end 1 of the chips is assigned the task. Usually dependant on the over all design, power requirements, timing etc.

Considering that, it should be quite evident that there is very seldom a single point of failure of in a system. Bugs can be fixed in various places and chips can be connected in various ways regardless of what their spec said.

Not a single fact that this thread has brought up can really prove where the problem is or where it should be solved. The only important point is that the problem can be fixed and that it does not affect performance. Bickering about whose solution is the most superior one is rather silly. Saying that a hardware problem should be solved in hardware or the other way around is rather silly since all I have seen here is a SYSTEM problem and for that I’d choose whatever fix that works best

regards,
Stefan Burström
Senior Systems Designer
Anoto AB
Ben Hermans about the A1 "bugs" : Comment 234 of 290ANN.lu
Posted by samface on 25-Aug-2003 16:05 GMT
In reply to Comment 233 (Stefan Burström):
Exactly. Thank you for pointing out the obvious which I obviously failed to explain.
Ben Hermans about the A1 "bugs" : Comment 235 of 290ANN.lu
Posted by samface on 25-Aug-2003 16:09 GMT
In reply to Comment 232 (Pete):
No, you said they made a "general fix" that would somehow work with all processor architectures. That's why I tried to explain to you that this is simply not possible, there must be a specific "fix" for each processor architecture and chipset combination.
Ben Hermans about the A1 "bugs" : Comment 236 of 290ANN.lu
Posted by Pete on 25-Aug-2003 16:16 GMT
In reply to Comment 233 (Stefan Burström):
-> Stefan Burström

The facts are that under Linux, VIA 686B works just fine with EVERY chip (chip A,B,C...,Z).
I just find strange that it'd not work fine on the AOne considering that there is no problem at all on any other motherboard where it's used and with Linux.

For me it can't be the VIA 686B alone if it enter in consideration at all. That's obvious in my eyes that it's not only related to the VIA 686B, and something else enter in consideration.

Note also that the things refered to be the cause of the problems on the AOne are well known since beginning 2002 on Linux and fixes. So they should not appear at all if that the cause. I personnally don't see why and how it can be the cause.

But ok if people want to believe it's the cause, then believe it. Personnally I don't believe it is. Period. I won't discuss this further as it's an endless discussion anyway.
Ben Hermans about the A1 "bugs" : Comment 237 of 290ANN.lu
Posted by JoannaK on 25-Aug-2003 16:22 GMT
In reply to Comment 233 (Stefan Burström):
Well.. For most people here.. It's blind faith they fight on. They have chosen who to belive (and often without any chance on checking any facts) and they keep on fighting. Facts ain't the issue, besides those details would be way over most of heads anyhow. :)

Personally.. I know somewhat of this level of hardware and I can't tell if some solution works or not by this info alone. IF I had enough time/hw etc (and one good coder to help on SW side) I could sort those out, but at the moment it's not possible.

What I have seen, does though give me some suggestions on what works and who might have a clue. And expecially couple of those who definitely don't know what they are talking about :)
Ben Hermans about the A1 "bugs" : Comment 238 of 290ANN.lu
Posted by samface on 25-Aug-2003 17:16 GMT
In reply to Comment 236 (Pete):
>The facts are that under Linux, VIA 686B works just fine with EVERY chip (chip
>A,B,C...,Z).

On x86 motherboards, I don't doubt it. However, I do doubt that this "fix" ever made it into the PPC version of Linux since there are just about no other PPC motherboard besides the AmigaOne that uses the VIA 686B. That's why MAI and Hyperion are now working on such a fix as the one made for x86 boards with the VIA 686B. I mean, why would they do a fix if the fix is already there?
Ben Hermans about the A1 "bugs" : Comment 239 of 290ANN.lu
Posted by Amon_Re on 25-Aug-2003 18:19 GMT
In reply to Comment 227 (Pete):
Sorry Pete, but this statement of yours just convinced me for sure that you are not understanding how these things work.

This is not a flame, or an insult, but your insights are wrong, plain & simple.

""It might be coupled to the ArticiaS, but that doesn't change the fact that the driver are/were at fault in the first place."

Having to change some code inside a driver for a specific platform doesn't mean it's a software issue. In fact it's the contrary. The driver works just perfect on all the other hardware, there is no reason at all that it'd not work on the AOne, except an hardware issue that make it not working well. Software fixes for specific hardware like AmigaOne/Teron boards are of course fixes for hardware issues, this is obvious. And this is the case here."

You should look more closely into linux sources, you'd be supriced to see how many software fixes there are.

But i will not discuss this publicly with you any further unless you can come up with some better logic then this.

different hardware works & interacts on different ways, compare the ArticiaS documentation to that of another northbridge if you don't believe me

Cheers
Ben Hermans about the A1 "bugs" : Comment 240 of 290ANN.lu
Posted by Amon_Re on 25-Aug-2003 18:22 GMT
In reply to Comment 233 (Stefan Burström):
I agree %100

Cheers
Ben Hermans about the A1 "bugs" : Comment 241 of 290ANN.lu
Posted by Amon_Re on 25-Aug-2003 18:24 GMT
In reply to Comment 236 (Pete):
Do you, or do you not agree with post 233?

That's my last question about this to you

Cheers
Ben Hermans about the A1 "bugs" : Comment 242 of 290ANN.lu
Posted by Amon_Re on 25-Aug-2003 18:27 GMT
In reply to Comment 237 (JoannaK):
We'll see in the near future i guess, but based on what has been explained to me & from the tests they've done sofar i'd say they're on the right track.

I can't tell if this will fix everything, i don't have the knowledge, experiance or documentation of all parts involved, but it does look promising.

Cheers
Ben Hermans about the A1 "bugs" : Comment 243 of 290ANN.lu
Posted by Stefan Burström on 25-Aug-2003 20:13 GMT
In reply to Comment 236 (Pete):
>The facts are that under Linux, VIA 686B works just fine with EVERY chip (chip A,B,C...,Z).

Just the fact that the VIA driver in Linux is filled with patches to work around bugs in the VIA chip makes it pretty obvious that any design involving the 686B chip needs special care to make it work correctly. Now, I don't take this as a proof of anything, I just take it as a pretty good argument that the world is not as black and white as you seem to think. Just because 2 chips don't work too well together does mean one (or both) of them are broken. They could be working fine to their spec, it is just the software that drives them that need special attention. (Gee how many times have I seen software running on our Asic's that shouldn't run at all (according to the spec). But it still ran. But every so seldome it failed which made people believe the hardware had flaws. Well in the end it usually turned out that the hardware needed to be handled differently.)

regards,
Stefa Burström
Senior Systems Designer
Anoto AB
Ben Hermans about the A1 "bugs" : Comment 244 of 290ANN.lu
Posted by JoannaK on 25-Aug-2003 20:23 GMT
In reply to Comment 242 (Amon_Re):
Well. I have to admit I was surpriced to hear there were some issues
on Aone USB needing a Uboot level fix. I had assumed those kind of
stuff would had been tested and sorted some times ago... But it's
good to hear things move forward. I hope they are right about those
fixes being 100% successful.
Ben Hermans about the A1 "bugs" : Comment 245 of 290ANN.lu
Posted by Mad-Matt on 25-Aug-2003 21:58 GMT
Ya know non of this really matters as long as the running os is running just fine on the hardware. The current amigas have far more software and hardware patches then the a1 has ;)
Ben Hermans about the A1 "bugs" : Comment 246 of 290ANN.lu
Posted by tarbos on 26-Aug-2003 00:27 GMT
In reply to Comment 224 (Neko):
>to the point that you can take such actions as put it on>a board in an unsupported configuration (Marvell with a G4) Maybe you should mention it is only the new G4 that was unsupported (?)since according to my information Marvell had a G4 running on theirboard for about a year and Motorola recommends the Discovery for usewith their G4s (in fact the Motorola MVP has a Discovery NB).
Ben Hermans about the A1 "bugs" : Comment 247 of 290ANN.lu
Posted by Fabio Alemagna on 26-Aug-2003 04:11 GMT
In reply to Comment 231 (samface):
> Different processor architectures -> different code for doing the exact same
> thing

> Every "fix" implemented in Linux for x86 will have to be rewritten and
> reimplemented for each processor architecture. How many PPC motherboards uses
> the 686B again?

Sammy, aren't you too old for bedtime stories? :)

In a well written OS, drivers don't have to care, and don't care about processor-specific things, apart from endianess of course (which has to never be assumed to be in one way or another). A driver is suited to drive the piece of HW it's built for, and nothing else. All Pete is saying is that on all other platforms where there's a VIA 686B, linux has been able to run seamlessy since some time now, thus if it doesn't work well on the AOne/Pegasos, it MUST be because there are _some other things_ which don't make it work and, guess what, the only other thing the Pegasos and the AOne have in common is the Articia...
Ben Hermans about the A1 "bugs" : Comment 248 of 290ANN.lu
Posted by samface on 26-Aug-2003 07:07 GMT
In reply to Comment 247 (Fabio Alemagna):
>All Pete is saying is that on all other platforms where there's a VIA 686B,
>linux has been able to run seamlessy since some time now,

Just like no A1 users never noticed any bugs, you mean?

Again, the A1 is AFAIK the only PPC motherboard in production volume that is using the VIA 686B. Furthermore, there is no such thing as a "hardware independant driver". Well, not yet that is; see http://www.projectudi.org

>thus if it doesn't
>work well on the AOne/Pegasos, it MUST be because there are _some other
>things_ which don't make it work

I'm sorry but that simplified logic is not going to work. Stefan Burström explained this rather nicely and I don't see the point in trying to explain this again.
Ben Hermans about the A1 "bugs" : Comment 249 of 290ANN.lu
Posted by Fabio Alemagna on 26-Aug-2003 08:15 GMT
In reply to Comment 248 (samface):
> Just like no A1 users never noticed any bugs, you mean?

Eh? So, tell me, if there are no bugs how come Hyperion said they fixed them? Please, stick to facts.


> Again, the A1 is AFAIK the only PPC motherboard in production volume that is
> using the VIA 686B.

People have proven you wrong on that one, so stop saying that. Moreover, are you implyng that the processor has any role in all this?

> > Furthermore, there is no such thing as a "hardware
> > independant driver". Well, not yet that is; see http://www.projectudi.org

I'm not talking about "HW independent driver", a driver is by definition dependent on the HW it's supposed to drive. The point I'm making is that the driver doesn't have to depend on anything else than the HW it's supposed to drive. If the Articia complied with its specs there would be no need for any additional tweaks to the drivers, since those drivers work with an almost infinite amount of combinations of different northbriges and VIA's southbridges.



> > thus if it doesn't
> > work well on the AOne/Pegasos, it MUST be because there are _some other
> > things_ which don't make it work

> I'm sorry but that simplified logic is not going to work. Stefan Burström
> explained this rather nicely and I don't see the point in trying to explain
> this again.

That simplified logic works just well. Stefan said that if two new combinations of HW don't work it's not just because one of them or both has a bug, it can also be because they're not properly setup, but THAT is flawed logic, imho: if both HW's comply with their specs, and if those specs are compatible between them, then there can't be any bug whatsoever, if instead one has to use some SW kludges to make things work it IS because of bugs which have to be worked around. The amiga HW needs kludges as well to work properly in certain circumstances, and that's because the HW is _bugged_, not because the HW has certain "features".
Ben Hermans about the A1 "bugs" : Comment 250 of 290ANN.lu
Posted by Phill on 26-Aug-2003 08:46 GMT
In reply to Comment 247 (Fabio Alemagna):
> All Pete is saying is that on all other platforms where there's a VIA 686B,
> linux has been able to run seamlessy since some time now, thus if it doesn't
> work well on the AOne/Pegasos, it MUST be because there are _some other
> things_ which don't make it work and, guess what, the only other thing the
> Pegasos and the AOne have in common is the Articia...

Hmm, and I thought they both used power pc's. Both are probably using gcc too.

If you've ever used C for writing device drivers then you'll know that different optimisations can turn a 100% working driver into something that barely works at all. You'll probably also know that just because something looks like it is running properly, doesn't mean it works 100%.

IMHO _NOBODY_ will ever prove whether this is a kludge or a fix. It's just too difficult to tell unless you spent a very long time analysing all the signals on the board etc. The reason it's taken so long to sort out is because it's damn near impossible to do this. Commodore did even worse things to solve problems, hand tuning each c64 off the production line to get them to boot etc.

Just because Linux is kludged to work with the VIA chipset on x86 has no bearing on whether it works under ppc. In fact someone recently said that some kludges have been broken recently, so it just goes to show how flakey the code in Linux is.

If you really want to get into a religious war over who is right or wrong, without any proof & relying on blind faith then fine.

Phill
Anonymous, there are 290 items in your selection (but only 90 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 290]
Back to Top