28-Mar-2024 23:55 GMT.
UNDER CONSTRUCTION
Anonymous, there are 335 items in your selection (but only 35 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 335]
[Forum] Try only to realise the truthANN.lu
Posted on 04-Jul-2004 14:02 GMT by Truth335 comments
View flat
View list
There is no DMA in the AmigaOne. http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=5558&forum=13
Try only to realise the truth : Comment 301 of 335ANN.lu
Posted by Don Cox on 07-Jul-2004 10:37 GMT
In reply to Comment 238 (Ferry):
"Some of my hobbies are related to Science, and in scientific method the charge of the proof is always up to the person who states something, i.e. if you states 'einstenium' exist, you MUST provide proofs. If proofs are not provided, it can be a theory or even just a personal opinion, but NOT a fact."

Popper argues, IMO convincingly, that in science you can never prove a theory, only disprove it. A currently accepted theory is one that has not been disproved.
Try only to realise the truth : Comment 302 of 335ANN.lu
Posted by Bernie Meyer on 07-Jul-2004 10:41 GMT
In reply to Comment 264 (Sammy Nordström):
Considering the same motherboard was, for a while at least, sold as a "LinuxOne", assuming that it works as advertised because surely nobody would ever sell something that doesn't work as advertised seems somewhat naive.For, as far as I can tell, that is the one thing everyone seems to be able to agree on now --- the Teron board (no matter whether you call it Teron, AmigaOne, or LinuxOne) has DMA issues under linux that rule it out for any sort of mission-critical use.So if one product gets sold by one vendor under one label and *fails* to perform as advertised, then assuming that the same product, sold by the same vendor, just under a different label, would necessarily live up to its promised feature list surely is a stretch.
Try only to realise the truth : Comment 303 of 335ANN.lu
Posted by Bernie Meyer on 07-Jul-2004 10:55 GMT
In reply to Comment 286 (Amon_Re):
The line between what is considered "odd, but functional" and what is considered "broken" is probably quite difference in the embedded world.In the embedded world, you write your programs especially for the hardware in question; when you write your program, you *know* what hardware it is going to run on, and you can (and will :) take its peculiarities into account. So in the embedded world it's perfectly fine to walk up to your software developer and say "Mike, we need you to write new firmware for this digital camera. Now, one thing --- there is no hardware cache coherency, so you have to keep that in mind when accessing DMA'ed data".On the desktop, the whole idea is to get away from known hardware. The whole job of an operating system is to provide a consistent and abstracted view of a whole range of hardware; Heck, AmigaDE was abstracting away the CPU, but even OS4 has a HAL and supposedly will provide the same APIs and behaviour on anything from Phase5 BlizzardPPC boards all the way to the AmigaOne/XY with a G9 which may be released in 2012. In *that* environment it's quite a lot harder to say "well, on one of the supported platforms, as far as your program is concerned, the order in which DMA'ed I/O operations happen is undetermined". That's not a consistent interface, and it's a large enough deviation from the expected behaviour that calling it "broken" doesn't seem too farfetched.
Try only to realise the truth : Comment 304 of 335ANN.lu
Posted by Bernie Meyer on 07-Jul-2004 11:00 GMT
In reply to Comment 290 (Don Cox):
IIRC, the PPC can handle several page sizes, with 4096 bytes being the smallest.Speaking from experience, targets for disk transfers in classic AmigaOS programs are rarely even 512-byte aligned, let alone 4096-byte aligned, and it's quite conceivable that the rest of those 4096 bytes might be allocated to frequently-used data. So making the whole page range covering a DMA target non-cacheable is quite likely to inflict a crippling performance penalty on the CPU's other work which is supposed to go on during the transfer.
Try only to realise the truth : Comment 305 of 335ANN.lu
Posted by Bernie Meyer on 07-Jul-2004 11:06 GMT
In reply to Comment 295 (syrtran):
It was my understanding that linux/PPC uses the BAT to map all physical memory *for the kernel*.Thus, whenever you have a userspace-to-kernel transition, all you have to do is activate the BAT, and voila, the kernel can access the physical memory in one nice, flat chunk. The alternative would be to set up page tables for the kernel, which would require considerably more overhead for userspace-to-kernel transitions (and the reverse, of course).Userspace memory management is, of course, handled through normal MMU tables. Unfortunately, drivers are running in kernel space....
Try only to realise the truth : Comment 306 of 335ANN.lu
Posted by Fabio Alemagna on 07-Jul-2004 11:12 GMT
In reply to Comment 304 (Bernie Meyer):
> IIRC, the PPC can handle several page sizes, with 4096 bytes being the smallest.

However, if I recall correctly from some screenshots of early AmigaOS4 boots, the page size is set to 64k on AmigaOS4.
Try only to realise the truth : Comment 307 of 335ANN.lu
Posted by Anonymous on 07-Jul-2004 13:02 GMT
In reply to Comment 291 (Johan Rönnblom):
>These allow to set up MMU/cache options for a range between 128KB and 256MB.

You can use up to 4GB now.
Try only to realise the truth : Comment 308 of 335ANN.lu
Posted by Amon_Re on 07-Jul-2004 13:08 GMT
In reply to Comment 303 (Bernie Meyer):
You raise a fine point, remains to be seen how the implementation affects AOS4 as a whole, if it only affects the HAL, then i'd say it's a minor issue, if it affects the whole OS, then it might be a bigger problem.

We don't really know how it affects it tho, and probably never will, but we do know it (ArticiaS) evolved from the embedded market, or that's how i remember it anyway, and that might explain some of it's peculiarities.

Given what we know about it, it's hard to tell, we know it's an issue with the cache coherency, but what we don't know is what goes on during DMA inside the ArticiaS, and wether or not it is possible to change it's DMA handling, it has a floating buffer, and that might be part of the problem, and part of the solution might also be related, who knows, perhaps it's behaviour can be altered, perhaps not.

*IF* AOS4 works correctly with DMA on the ArticiaS, and *IF* the implementation has no adverse effects on AOS4, or it's API's, would you still call it a broken design?
Try only to realise the truth : Comment 309 of 335ANN.lu
Posted by Amon_Re on 07-Jul-2004 13:10 GMT
In reply to Comment 306 (Fabio Alemagna):
Wich would cripple performance even more in Bernie's scenario, or atleast the one he was explaining to Don
Try only to realise the truth : Comment 310 of 335ANN.lu
Posted by Don Cox on 07-Jul-2004 13:32 GMT
In reply to Comment 308 (Amon_Re):
"*IF* AOS4 works correctly with DMA on the ArticiaS, and *IF* the implementation has no adverse effects on AOS4, or it's API's, would you still call it a broken design?"

I think the time has come to wait until the DMA for AOS4 is released. They say they are testing it very thoroughly because they know everyone will jump on them if there is the slightest problem.
Try only to realise the truth : Comment 311 of 335ANN.lu
Posted by Amon_Re on 07-Jul-2004 13:36 GMT
In reply to Comment 310 (Don Cox):
I'd be cautious if i where them too
Try only to realise the truth : Comment 312 of 335ANN.lu
Posted by Anonymous on 07-Jul-2004 13:56 GMT
Short extract from Articia S documentation published by Mai Logic:

"The snoop cycle is used to probe the primary and secondary cache for updated data when the PCI
accesses DRAM. This is done to maintain data coherency between the Floating Buffer, DRAM and both
caches. The Articia S performs the Snoop cycle. When there is a snoop hit on a modified cache line in
either level one or two cache, the contents are written back directly to the Floating Buffer. A PCI Bus
master can subsequently later on fetch the data directly from the Floating Buffer. The Floating Buffer is
flushed back to DRAM during a PCI write cycle. The corresponding line in level one or level two cache is
thus invalidated. Snoops are hidden, meaning the CPU can continue its current data access without
being interrupted while the Articia S simultaneously queries both caches."

The design is fine. The ArticiaS should maintain cache coherency during PCI Bus master access (that is DMA).
But that doesn't work... and it is a serious bug.

The real question is: why do Hyperion&Eyetech people say the documentation is fine but bplan people didn't know how to read it?
Try only to realise the truth : Comment 313 of 335ANN.lu
Posted by Fabio Alemagna on 07-Jul-2004 16:16 GMT
In reply to Comment 312 (Anonymous):
Where did you take that from? If indeed true, that's the proof that ArticiaS' "feature" is rather a damn big bug.
Try only to realise the truth : Comment 314 of 335ANN.lu
Posted by Fabio Alemagna on 07-Jul-2004 16:18 GMT
In reply to Comment 312 (Anonymous):
Is such documentation publicly available? If indeed true, that's the proof that ArticiaS' "feature" is rather a damn big bug.
Try only to realise the truth : Comment 315 of 335ANN.lu
Posted by Amon_Re on 07-Jul-2004 19:19 GMT
In reply to Comment 314 (Fabio Alemagna):
It's definatly not in google that bit of text, so if it is authentic it does shed some light on this.
Try only to realise the truth : Comment 316 of 335ANN.lu
Posted by Ferry on 07-Jul-2004 20:51 GMT
In reply to Comment 301 (Don Cox):
@Don Cox

Hum, Karl Popper.... I have not heard that name since the time I was student :¬) Well, anyway, Popper is right, because that's the true scientific spirit. As I said in the same message you were quoting "of course, [a theory] will remain open to further theories and tests that could change the results - that's the way Science works". A theory is accepted until someone else postulates a new, and usually more complete, theory. For example, in cosmology: Aristarco of Samos -> Copernico -> Galileo -> Kepler -> Newton -> Einstein ->...

Saluditos,

Ferrán.
Try only to realise the truth : Comment 317 of 335ANN.lu
Posted by Neko on 07-Jul-2004 20:58 GMT
In reply to Comment 64 (Fabio Alemagna):
I can quote a situation where you'd get crappy performance.

Until a little while back I was plugging all my machines into the back of my
ADSL router. Despite being specced as "100Mbit" (and the rest of the network
syncing to 100Mbit, Full Duplex) the actual throughput on it's tiny tiny host
processor failed to reach 7Mbit. Of course the actual ADSL specification it
implements would barely bit 8Mbits in one direction, and that even shared
between upwards of 20 people at the ISP.. so it doesn't matter so much.

Bridged through a FreeBSD server (Via C3 "Samuel", 800MHz, two 3C905B's), the
network performs excellently and at full speed.

So.. first look at shitty network hardware, I doubt most AmigaOne users really
have a properly wired corporate-style network, high performance switches in
racks etc. sitting around to test with. The same goes with Gigabit Ethernet on
the Pegasos - I'll be damned if I know it works beyond 100MBit because I have
nothing to test it with. I trust Nicolas' work and Gerald's assurances
though :)

Neko
Try only to realise the truth : Comment 318 of 335ANN.lu
Posted by Neko on 07-Jul-2004 21:01 GMT
In reply to Comment 315 (Amon_Re):
That description of the "feature", above, is correct, and yes - the bug is in
fact that the "feature" doesn't work as it is documented above.

Neko
Try only to realise the truth : Comment 319 of 335ANN.lu
Posted by hammer on 07-Jul-2004 21:04 GMT
In reply to Comment 313 (Fabio Alemagna):
"SNDF2003_DALLAS_A2513.pdf" has some hints of it e.g. in Page 18....

- copy and paste -
Floating Buffer
* Patented Floating Buffer design
provides tag-fixed, data floated
buffering technology
* Quickly handles buffered data
from bus-to-bus for data
coherency control
* 256-bit point-to-point data bus
structure for easy data path
connection and layout design
* Thread cache for concurrent CPU,
AGP, and PCI to DRAM access
* Piped control engine for coherent
maintenance
* Pre-fetch, Merge Write and Page
Re-ordering support
* Threading control to optimize
performance for different devices
---

From Page 20
---
Articia’s Cache Coherency Flow
* If snoop miss, the device needs to request data from
DRAM again
n Lower performance with extra request cycles when snoop
miss
* Higher performance with concurrent processing of snoop
operation and DRAM data requesting
---

Note that this is from MAI's marketing matterials.
Try only to realise the truth : Comment 320 of 335ANN.lu
Posted by hammer on 07-Jul-2004 21:20 GMT
In reply to Comment 314 (Fabio Alemagna):
From http://www.google.com.au/search?q=cache:Y_WTinYN8CAJ:www.mai.com/products/BRA661R2.0.pdf+Articia+floating&hl=en
it give some clues on

Floating Buffer
(SNIP)
• Support multiple data transfer protocols including page
reordering, page merge write, and cache line merge write
(SNIP)
• Four-port concurrency control among CPU, Memory, PCI 0
and AGP/PCI bus 1 interfaces
• Hidden Snoop/Snoop Ahead features with no interference
to CPU normal data cycles
Try only to realise the truth : Comment 321 of 335ANN.lu
Posted by Fabio Alemagna on 07-Jul-2004 21:35 GMT
In reply to Comment 320 (hammer):
Well, that says it all then. Feature my a*#e.
Try only to realise the truth : Comment 322 of 335ANN.lu
Posted by Fabio Alemagna on 07-Jul-2004 21:38 GMT
In reply to Comment 320 (hammer):
Hmm, wait, it says Articia Sa. Is that the one we're interested in?
Try only to realise the truth : Comment 323 of 335ANN.lu
Posted by Nicolas Sallin on 07-Jul-2004 23:05 GMT
In reply to Comment 322 (Fabio Alemagna):
Sa or S, there are the same infos here:

http://www.google.fr/search?q=cache:hqIDYkRHNGcJ:www.mai.com/products/BRA660R2.0.pdf+&hl=fr&ie=UTF-8
Try only to realise the truth : Comment 324 of 335ANN.lu
Posted by Anonymous on 07-Jul-2004 23:38 GMT
In reply to Comment 322 (Fabio Alemagna):
The Articia Sa is supposed to be an improved model of the S (eg it handles DDR memory)
Try only to realise the truth : Comment 325 of 335ANN.lu
Posted by Don Cox on 08-Jul-2004 06:25 GMT
In reply to Comment 322 (Fabio Alemagna):
AFAIK the Sa is not available yet.
Try only to realise the truth : Comment 326 of 335ANN.lu
Posted by Amon_Re on 08-Jul-2004 07:13 GMT
In reply to Comment 318 (Neko):
Sorry Neko, but even anonymous posts have more credibility then you
Try only to realise the truth : Comment 327 of 335ANN.lu
Posted by hammer on 08-Jul-2004 07:34 GMT
In reply to Comment 322 (Fabio Alemagna):
Both was referring to MAI's patented "Floating Buffer" technology.
Try only to realise the truth : Comment 328 of 335ANN.lu
Posted by hammer on 08-Jul-2004 07:37 GMT
In reply to Comment 324 (Anonymous):
I was referring to the patent “Floating buffer” technology not the memory controller.
Try only to realise the truth : Comment 329 of 335ANN.lu
Posted by hammer on 08-Jul-2004 08:10 GMT
In reply to Comment 321 (Fabio Alemagna):
In fairness, it’s almost expected that the first generation on any given product would be a lemon e.g. Intel's early 915 Grantsdale issues.

The difference is speed in admitting the issues and offering remedies.
Try only to realise the truth : Comment 330 of 335ANN.lu
Posted by priest on 08-Jul-2004 14:37 GMT
In reply to Comment 271 (Fabio Alemagna):
"No one ever said the AmigaONE doesn't have DMA"

Actually, "Truth" did say. Look at the first post. :)
Try only to realise the truth : Comment 331 of 335ANN.lu
Posted by Anonymous on 08-Jul-2004 15:24 GMT
In reply to Comment 329 (hammer):
It's not the first generation chip, iirc the MAI Aureate was used in IBM POP systems, which wasn't exacly a star either...
Try only to realise the truth : Comment 332 of 335ANN.lu
Posted by Sammy Nordström on 09-Jul-2004 03:42 GMT
In reply to Comment 302 (Bernie Meyer):
Read the AmigaOne disclaimer again, they make it perfectly clear that they don't guarantee anything when it comes to using linux with their hardware.
Try only to realise the truth : Comment 333 of 335ANN.lu
Posted by Sammy Nordström on 09-Jul-2004 04:07 GMT
In reply to Comment 293 (Johan Rönnblom):
Again, there is still no proof of your theory that the problem actually is a malfunction in the hardware rather than just an incompatibility with certain industry standards. It's because of issues like this that Eyetech never gave any guarantees when it comes to using other operating systems than AmigaOS4. If you're really that concerned about having a fully functional and ready to go system, Eyetech recommends that you wait until AmigaOS4 has been officially released.

I really don't see any reason to discuss this matter beyond this point until AmigaOS4 is released. Anyone and everyone still doing so obviously has something more than just the interest of AmigaOne consumers in mind.
Try only to realise the truth : Comment 334 of 335ANN.lu
Posted by Darth_X on 09-Jul-2004 23:14 GMT
In reply to Comment 326 (Amon_Re):
p-chan!
Try only to realise the truth : Comment 335 of 335ANN.lu
Posted by hammer on 12-Jul-2004 06:30 GMT
In reply to Comment 331 (Anonymous):
>It's not the first generation chip, iirc the MAI Aureate was used in IBM POP >systems, which wasn't exacly a star either...
It's a first generation chip for "S" line i.e. "Sa" is the next.
Anonymous, there are 335 items in your selection (but only 35 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 335]
Back to Top