Quote:

When we've discussed the feature set they would like to implement, I have tried to remind them of the limitation of the T2080 (let alone the T2081), so I don't know how that got in there.
I don't prepare releases, but there is simply no way to attach the number of devices they want to use to a T2081.
You know the specs for that CPU as well as I do.

Frankly, I'd like to see SATA 3 and eSATA support dropped as well.

> there is simply no way to attach the number of devices they want to use
> to a T2081. [...] I'd like to see SATA 3 and eSATA support dropped

https://www.powerpc-notebook.org/2017/11/powerpc-notebook-block-diagram-done/
https://www.powerpc-notebook.org/wp-content/uploads/2017/11/Portatile_schema2a_pub.png
https://www.powerpc-notebook.org/wp-content/uploads/2017/11/Portatile_schema2a_pub.pdf

T2081 is out. T2080, SATA3 and eSATA are in.

Quote:

Yeah, I can verify this. While I'm not allowed to discuss the details, a PCI-E bridge chip has been incorporated to handle the additional components. Oh, and in addition to the parts Andreas has mentioned, USB3 controllers are being evaluated.

In short if this makes production it is likely to be the most advanced new PPC system introduced thus far.
While the clock speed is lower than the G5, the cpu supports two times the threads of a dual 970MP or four times the threads of a dual 970 (8 total).

So, T2080, MXM, SATA3, eSATA, and USB3.
And the schematics are being created by Acube.

So, do we sound serious now?

[ Edited by Jim 05.11.2017 - 10:40 ]

> a PCI-E bridge chip has been incorporated to handle the additional components.

According to the block diagram, the PCIe-PCIe bridge handles only WiFi, 3G/LTE and a MiniPCIe x1 slot. Everything else is handled either by direct PCIe connection (MXM, USB3, SATA3/M.2/eSATA) or by other SoC controllers (Ethernet, audio, input devices, SD slot, SATA2, webcam etc.).
Btw, I wonder what became of the originally announced Bluetooth.

> if this makes production it is likely to be the most advanced new PPC system
> introduced thus far.

...if we ignore the Talos II ;-)

> the cpu supports two times the threads of a dual 970MP or four times the threads
> of a dual 970 (8 total).

...and it can actually be used to build a mobile device :-)

> So, T2080, MXM, SATA3, eSATA, and USB3.

...and much more (see above) :-)

Quote:

Please don't bring that back up, I think they forgot about it.
And they jammed a lot in there already, also frankly I think limiting the PCI-E switching is a good thing.
And if people want bluetooth, they can add it via USB (or just use a USB device instead).

Also, isn't the TalosII a Power system, not a PPC?
Splitting hairs, I know, but I tend to think of PPCs primarily as the G3-G5 (and similar) processors.

Anyway, what do you think so far?



[ Edited by Jim 05.11.2017 - 16:17 ]

>> I wonder what became of the originally announced Bluetooth.

> I think they forgot about it. ;-)

Forgot? Or is it that there are no Bluetooth parts suited for OSH?

> I think limiting the PCI-E switching is a good thing.

Yes, of course, switching/bridging is always something to avoid and to use only if really necessary to implement the desired features. Using a PCIe bridge without being really necessary would be bad design and just add to the costs.

> isn't the TalosII a Power system, not a PPC?

The POWER microarchitecture implements the PowerPC ISA (as well as the more recent Power ISA), so yes, the POWER9 is a PPC and the Talos II is a PPC-based system.

http://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=7289&start=40

> I tend to think of PPCs primarily as the G3-G5 (and similar) processors.

I tend to think of PPCs as all CPUs implementing the 32-bit and/or 64-bit PowerPC ISA :-)

> what do you think so far?

The block diagram looks good :-)

>The block diagram looks good

Yeah, I think so too.
Most of the functionality I was hoping for (I wasn't particularly interested in bluetooth, bandwidth for that is pretty low).

I going to donate some more cash to this project after the new year (right now I need to concentrate on the holidays and my tuition expenses).

uboot?
I would like to have Open Firmware like the OLPC XO-1

First published Open Source implementation of OpenFirmware

[ Editiert durch polluks 06.11.2017 - 17:57 ]

> Open Firmware like the OLPC XO-1 [...]
> First published Open Source implementation of OpenFirmware

...just that the OLPC XO-1 uses a different OpenFirmware implementation than the one linked to ;-)

Quote:

The two are not incompatible.
Open firmware implementations often rely on software like uboot.

But frankly, I'd want to work with whatever Acube is comfortable with.

>> uboot? I would like to have Open Firmware

> The two are not incompatible.

They are, for everything but one detail:

"Linux kernel expects certain information on the hardware that it runs on. For kernels compiled with fdt support, this information has the form of a device tree, which is based on the Open Firmware specification. Bootloaders like U-Boot that do not implement the Open Firmware API, are expected to pass to the kernel a binary form of the flattened device tree, commonly referred to as FDT blob"
https://www.denx.de/wiki/DULG/LinuxFDTBlob

> Open firmware implementations often rely on software like uboot.

Can you give examples of that?

> I'd want to work with whatever Acube is comfortable with.

And ACube works with whatever NXP uses, which happens to be U-Boot :-)

>Can you give examples of that?

There is a link to the OpenBIOS site on the page that he referenced that specifically mentions this technique.

And at its most basic, uboot is just a bootloader.

Nothing prevents it from being scaled down to a minimum and having it initiate other firmware.

From what I've seen from many installations its often a two part process anyway (although that is usually a simple ROM routine calling a more complete firmware routine).

[ Edited by Jim 07.11.2017 - 15:45 ]

>> Can you give examples of that?

> There is a link to the Open firmware site on the page that he referenced
> that specifically mentions this technique.

I guess you mean this statement:

"In most cases, the Open Firmware implementations provided on this site rely on an additional low-level firmware for hardware initialization, such as coreboot or U-Boot."
https://www.openbios.org/Welcome_to_OpenBIOS

The OpenFirmware implementations mentioned on the left are Open Firmware, SmartFirmware, OpenBOOT, OpenBIOS and SLOF. For SmartFirmware, the statement is obviously untrue, as can be seen by the Pegasos and the Efika 5200B. And also SLOF doesn‘t rely on another low-level firmware.

Actually, I find the proposition a bit ridiculous myself, but it can be done.

> it can be done.

Someone would have to do it for the PowerPC notebook to satisfy polluks and other OpenFirmware aficionados, as I doubt it is planned to be done by ACube or the Power Progress Community ;-)

Quote:

Again, I never expected it to be, and I'm not sure why I'm even chiming in as Open firmware holds no particular appeal to me.

>> The block diagram looks good :-)

> Yeah, I think so too.

According to the block diagram, there's SATA2 connected (for whatever reason) and the 4 PCIe controllers are configured with 9 lanes as x4-gen3 (MXM/GPU) x2-gen2 (4×SATA3) x2-gen2 (MiniPCIe/LTE/WiFi) x1-gen2 (4×USB3).
I just had a closer look at the SerDes lane assignment options of the T2080:

https://lists.denx.de/pipermail/u-boot/2013-November/167690.html
https://lists.denx.de/pipermail/u-boot/2014-May/179996.html (for completeness sake)

To me it seems the T2080 offers three better PCIe options, so that only the fourth-best option would be the one chosen by ACube:

14 PCIe lanes (x4 x4 x4 x2) without SATA2 (using 0xBC + 0x1F config)
12 PCIe lanes (x4 x4 x2 x2) with SATA2 (using 0xBC + 0x15/0x16 config)
11 PCIe lanes (x4 x4 x2 x1) without SATA2 (using 0xC8/0xD6 + 0x1F config)
09 PCIe lanes (x4 x2 x2 x1) with SATA2 (using 0xC8/0xD6 + 0x15/0x16 config)

Quote:

Thanks, good analysis.
I'll relay it.

Funding for the schematics is almost complete, and Roberto is assembling a team for the campaign for board layouts.

I'm looking for to whatever they decide on the release of first stage info, but they seem committed to making everything public.

So...a set of Acube designed schematics for a T2080 based board seems inevitable, and a board layout for a laptop seems likely.

After that, whatever happens, I'd have to consider this project a success.

Quote:


While the laptop still needs more research&funding (battery,charging,case,display etc) I wonder if those schematics could be used by ACube to do a non retarded Tabor.......

Quote:

Funny you thought of that, when I first mentioned the project to Bigfoot he said he'd like to have one to build a desktop or tower.
I don't see why the basic schematic couldn't be adapted.
But the gpu connections are set for an MXM video card and adapting the design to standard PCIe expansion slots would require reworking it a bit.

And I suppose a SFF board could still use MXM.

The layouts, of course, are specific to the laptop, with the case that has been chosen.

This cpu was one of the candidates I mentioned to Bill Buck when I peepared some initial specs for him.
Actually, it's the second most powerful, while still being relatively low cost.
So, in a curious way, this all moves forward even without Bill's involvement.

And, of course, we had feedback from posters here and on other Amiga forums (and in particular, I'd like to thank Andreas for allowing me to bounce ideas off him since we were discussing the MPC8610 and MPC8640/41 processors).

Once the schematics are made available, whatever anyone wants to do with them is their business, with the qualifier that creating board layouts with their multiple layers is actually a more complicated task than the initial schematics.

This will be (as far as I know) the first completely documented PPC design that our community will have access to, since some of the details of the Pegasos2 have never been released.
There is nothing to prevent Bill Buck or Paul Gentile (or Acube) from building a prototype based on this.

So, how about an Acube produced successor to the SAM460? Well, they ARE the first to have access to the schematics.
Prove to them (or someone else) that there is a market for it.
Bill Buck still has warm feelings for the ISA, but he didn't think it was a practical idea.

Still, I've always argued that we aren't bound by practicality.
Or I wouldn't have been searching all along for a like minded group of fanatics.
Luckily the Linux community still has a few.
It could even lead to some lingering interest in big endian PPC64.

Quote:

I see nothing wrong with this:
ItsybitsyweenytinyRadeon

At the right price (and with the outlook of support) I'd buy a board in an instance.

Quote:

Thanks. Yes, that would do nicely, and the price is good.
With room to upgrade later.

Gee, good thing Mark wanted to keep our driver support progressive and complete, eh?

I've never questioned anything he, Frank, Fab, Jacek, or Andre have ever said to me (except when it came to issues of self restraint).

At the very least, that would be a good choice for an initial system for Mark (since the R800s are a likely candidate for early 3D support).

did i miss something? how could this be of any interest for morphos? AFAIK the next step is going to be an ISA switch or am i wrong? Are there any plans to continue PPC support?

If so, how about this? :D

click me hard

We will stay different! So no ISA switch!

[ Edited by DJBase 21.04.2018 - 20:16 ]