[solved] looking for a RISC board, with 2 PCI slots, able to run linux

[legacy]

So, I don't like linux but I have to deal with it for business. 

Now, to cut the story short, I need to replace a board with something more friendly since the board I am using at the moment has a lot of issues with PCI_IO and I am in the rush.

I will for sure find out what is wrong, but for now I need to replace the board with something able to run linux 3.* at least, and with one or two PCI32bit v2.* compliant.

I just need two PCIs slots, 128MB of ram, and a serial port. As CPU, I can move the rootfs to powerpc*, mips32r2, arm*

Open to ideas/suggestions 

[neil555]

Would this work?

http://www.acube-systems.biz/index.php?page=hardware&pid=2

Dunno if they are still available though 

[legacy]

Yup, may be. I will dig deeper.
Thanks 

[David Hess]

Is there some reason you cannot use an x86 micro ATX motherboard that has 2 PCI slots?  There are lots of cheap ones.

[legacy]

Is there some reason you cannot use an x86 micro ATX motherboard that has 2 PCI slots? 

Yup.
-1- In first place x86-stuff comes with a BIOS, which usually adds more complexity.
-2- my customer doesn't want x86. Which is *THE* main reason I need to stay away.

At the end I have to fix the PowerPC405GP problem (since our prototypes are based on this chip, and I can't change it). I need a board just to avoid to stay idle-blocked due to the PCI_IO.

I wish we had a PowerPC expert in the team. Unfortunately I am all alone.

There are a lot of activities to be completed in the list. Including the userspace: mini-rootfs, applications, configurations, documentation. The list goes longer than I can figure out.

[Gribo]

Will this do?
http://www.amigaos.net/hardware/133/amigaone-x5000

A bit of an overkill.

[legacy]

any MIPS32R2 board with 2 PCI-slots ?

[westfw]

Old ppc mac?

[nctnico]

Is there some reason you cannot use an x86 micro ATX motherboard that has 2 PCI slots? 

Yup.
-1- In first place x86-stuff comes with a BIOS, which usually adds more complexity.
-2- my customer doesn't want x86. Which is *THE* main reason I need to stay away.

I'd go for the x86 solution anyway. BIOS isn't a problem because it goes out of the way quickly once GRUB has loaded. Nowadays there are many fanless x86 solutions. Sticking with power PC probably means using big endian byte ordering which can work badly together with typical PC style hardware.

BTW how do you keep digging these kind of holes for yourself?

[legacy]

I'd go for the x86 solution anyway.

Already told it's a NoGo

BIOS isn't a problem because it goes out of the way quickly once GRUB has loaded

I wouldn't not be so sure, I have a lot of negative experiences which tell me to stay away.

[legacy]

Sticking with power PC probably means using big endian byte ordering which can work badly together with typical PC style hardware.

This is another reason to stay away from PC.
Also, kernel sources about PCI are different.

how do you keep digging these kind of holes for yourself?

What do you mean?

[legacy]

Old ppc mac?

Old G3 mac, "new world" OpenFirmware: may be!
In the meanwhile I got a PowerMac-G3 from ebay.
60 euro of investment (plus postage) it might help.

[nctnico]

how do you keep digging these kind of holes for yourself?

What do you mean?

No offense intended but looking from a distance it seems to me you are always doing things the hard way in too little time for reasons which are not very obvious. For example: nothing is easier than using Linux on a PC so I can't even start to comprehend how that can go wrong.

[legacy]

For example: nothing is easier than using Linux on a PC so I can't even start to comprehend how that can go wrong.

Bah, this is your opinion, completely wrong for the context I am working in.

[technix]

i.MX 6 Quad maybe? A quad-core ARM Cortex-A9 core. That thing comes with little endian core and a few PCIe lanes. There are hacks available out there that can convert that into a pair of PCI lanes. I believe there are also more modern ARM cores (AArch64 with virtualization) with PCIe out there.

[westfw]

Old G3 mac, "new world" OpenFirmware: may be!
In the meanwhile I got a PowerMac-G3 from ebay.
60 euro of investment (plus postage) it might help.

Yep.  Some time back, the company I worked for was using used G5 powermacs to bring up SW that would eventually run on some embedded PPC board.  Perhaps the ill-fated P.A. Semi chip :-(    They were absurdly cheap (compared to their original retail price); cheaper than "eval boards" from semiconductor manufacturers, IIRC...

Likewise PCs are fine bring-up platforms for most x86 projects; yes, there's a BIOS that will stick things in there in nearly invisible "virtual" modes (like USB keyboard bios emulation...), but something like grub will load up software onto a nearly bare-metal x86 environment...

[ale500]

Just a note: PCI Express is not PCI. The former is serial the latter parallel.
There was, once upn a time, a board called pegasos. It had some PPC chip, don't ask me which one. It was a few hundred euros in like 2006-2008... they had PCI slots. 
This is 15 years old tech you are looking for, it was hot at the time, nowadays...

I assume you have a couple of boards with PCI that you must use for some reason, maybe re-thinking the whole concept trying to use more modern tech may not be as bad a solution as you think. How long should your setup work ? 1 year, 5 10 ?, using already outdated, eol'd hard to find components today means that in 1, 5, 10 years it would be a degree harder.
The idea with the quad arm i.MX 6 is not a bad one, a PCIe to PCI bridge exists for sure. Some of TI's parts have 10 years availability.

[legacy]

G5 powermacs

From my point of view they are a NoGo! G5 is a true 64bit machine, which is a completely different branch (different source in the linux kernel) from machines PPC32 like PPC4xx!

The PCI used in G5 is PCI64 with less quirks than in PCI32.

PowertMac-G3 is the best solution for me.

Although there is some code for 4xx support in the standard kernels from Linus Torvalds, it is incomplete and largely broken for the PCI32-embedded part. Well, as far as I have recently experimented, a lot of the code for embedded machines in this tree has been contributed by MontaVista Software Inc, which currently is lagging behind linuxppc 2.6.22 devel. So, you wan't see their support in 3.* and 4.*. Not yet, unless a big customer wants to inject a lot of money into the task. The code is gradually being merged into 'abandonware', since linux is moving to PPC64 (thanks to IBM interest for POWER8), while we are moving to modern PPC32 embedded cores (>460, ~2006 generation), and generally a lot of companies prefer to deal with  ARM chips as main (linux?)processor for their embedded projects.

To cut the story shorter, 4xx is not Dead Iron, but 405 (~1999 generation) is going EOL.
We usually have to provide 20 years of support. For PPC405 17 years are already gone.

cheaper than "eval boards" from semiconductor manufacturers, IIRC

Eval boards are usually better for prototyping purposes! At least they offer a lot of test-points, including performances TP, and LA access points.

Unfortunately they are difficult to find, and expensive.

yes, there's a BIOS that will stick things in there in nearly invisible "virtual" modes (like USB keyboard bios emulation...), but something like grub will load up software onto a nearly bare-metal x86 environment...

Every PC-BIOS usually adds a lot of pre-initializations on PCI to handle quirks. The BIOS itself is designed with the idea of having to deal with VIDEO boards which can be ISA-stuff ported to PCI. It means it carries on PCI_IO which must support fixed addresses, which adds quirks. And here we go! It's an hardware problem, workaround-ed in firmware, before grub, and then linux, can takes the control.

Grub doesn't re-initialize anything! It takes all the legacy BARs already programmed by the BIOS, and once programmed you can't change them. And so the Linux kernel from 2.6.26 to 4.11.0, which does PCI-rescan, but only for reprogrammable BARs.

I have to solve a different kind of quirks, related to the old-pATA controller stuff I find attached to the PPC405 prototype they gave me! I can't change the hardware (e.g. replacing the legacy pATA chip with a modern component, whose addresses are not fixed but programmable), and modern linux kernels don't carry about old legacy-quirks. Code has been removed in the kernel tree.

So, I already have a lot of problems, I don't need to add more problems because of the hole in the address space added by the BIOS to support video board on legacy PCI_IO.

I have already put the old-pATA chip onto a PCI-board prototype, so I can plug it into an empty PCI slot of G3-PowerMac, and try to resurrect the old kernel code (mainly from 2.4.*), fixing the quirk problem. I can isolate the specific board-init code into the bootwrapper as "glue" between the firmware and the kernel.

All of that, waiting to access the PPC405 prototype. But, in the meanwhile I will also use the PowerMac-G3 to develop the userspace stuff (musl-libc driven). Thanks god, it's kernel-independent.

[jwm_]

BIOS goes away? Haha, welcome to the hell that is SMM or system management mode.

https://en.m.wikipedia.org/wiki/System_Management_Mode

Basically the BIOS can interrupt your operating system at any point and take over the CPU and there is no way to stop it, not only that but BIOSs will do fun stuff like twiddle your peripheral settings in a poor attempt to implement power savings. Or do some crypto to decide whether you are authorized to use the software. It is unblockable code that is not contained in the operating system. It's a hella pain to figure out what else is twiddling done device when after a full code search you can't find anything that touches it. And try to write concurrent safe code when the other party ignores your CPU locks.

Incidentally, it's also a fun place for rootkits to hang out because your basically gotta manually read your BIOS flash to find em. The NSA certainly is a fan. https://en.m.wikipedia.org/wiki/File:NSA_DEITYBOUNCE.jpg

[legacy]

BIOSs will do fun stuff like twiddle your peripheral settings in a poor attempt to implement power savings

yup this is a problem I had with an embedded geode (x86) board. It did something "strange" launching "energy green" routines. Don't ask my what they are supposed to do, I haven't investigated, but I know they crashed the attached miniPCI-fpga-VDU I was developing. At the beginning I thought it was my fault, so I spent a lot of time on HDL, fpga's MPU firmware, kernel driver ... at the end I found it was BIOS's fault (thanks god, there was a "disable" option in the bios, which stopped the problem to happen).

Five weeks later

[David Hess]

I assumed legacy's answer about not using x86 was because of the system management mode.  I gave up on Intel hardware for real time applications more than a decade ago because of it.  Even if the BIOS has options to disable it, usually it is not completely disabled.

[dgtl]

yup this is a problem I had with an embedded geode (x86) board. It did something "strange" launching "energy green" routines. Don't ask my what they are supposed to do, I haven't investigated, but I know they crashed the attached miniPCI-fpga-VDU I was developing. At the beginning I thought it was my fault, so I spent a lot of time on HDL, fpga's MPU firmware, kernel driver ... at the end I found it was BIOS's fault (thanks god, there was a "disable" option in the bios, which stopped the problem to happen).

Five weeks later

The Geode was especially difficult x86 platform. The HW and busses were more like non-x86 platforms. They had inside 3 io/memory bus routers, that had configurable routing tables to route the cpu io/memory accesses. As supporting it as a new architecture was too difficult, the classic PC architecture was then virtualized on top of the actual HW; Linux or Windows OSes talked to it like it was regular PC, but actually it was not. If I remember correcly, the internal HW was faked as PCI devices, which they were not (PCI config space implemented in FW?). There was a FW blob called VSA, that had to be run in SMM mode. This AMD-provided blob then virtualized the actual HW that the PC architecture needed but the HW did not provide. The BIOS had to start this blob and then the BIOS had to set up the rest (enumerate PCI HW and then configure the routers to route required addresses to required locations). At first this blob was a black box, later sources were distributed, but with no sane compiler this thing was compilable (sources are probably somewhere in coreboot repos if anybody is interested). There was no way of running without VSA as no OS did support the HW directly. This SMM blob was actually modular and you could hook up different modules as needed. I've seen one with serial port terminal, that was accessible while the board ran happily windows. It was a little bit strange to mess directly with io registers or memory while windows was running, but this helped a lot while developing drivers to custom hw.
Getting some custom boards running with Geode LX + CS5536 was an experience. This platform is now 10+ years old and I hope that nobody needs to touch this mess anymore; let it stay in history.

[technix]

Maybe you can look into the i.MX 7 DualLite for some inspirations. It is a triple-core processor - Cortex-A7 MP2 @1.2GHz and Cortex-M4 @270MHz in the same chip, and the M4 core have almost the same peripheral and memory access to the A7 one. You can also load code from the A7 core to M4 core on demand.

Oh and one of the features of a recent Linux kernel on ARM is Thumb-2 kernel, which results in the kernel being compiled into almost entirely Thumb-2 code both the A7 and the M4 cores would accept. So the locking code and a lock canbe shared by both cores - both A7 and M4 cores uses the exact same locking code and references the exact same lock.

[grumpydoc]

So, I don't like linux but I have to deal with it for business. 

Reasons?

[legacy]

This platform is now 10+ years old and I hope that nobody needs to touch this mess anymore; let it stay in history.

100% agree. It was a bloody horror story, so let it stay in history(1), at least light years away from me 


(1) I am still so terrified that I don't want to report that working experience in my CV

[cdev]

https://opencores.org/


Its a RISC (SPARC i.e Sun compatible) core and its open hardware.

Its used to run realtime applications like GPS successfully (Skytraq which makes excellent GPSs uses it in Navisparq, for example)

[dgtl]

https://opencores.org/
Its a RISC core and its open hardware.

As with the Geode platform, the HW may be actually decent, but the full software ecosystem is all that matters. Going for something that is off-mainstream means a lot of extra development and later during the product lifetime, a lot of hard work to keep it going as the others may be dropping of their input on the platform. So unless you're just playing around, inventing the wheel is not commercially viable. Stick with one of the large SoC vendors work; even if they deprecate the part and do not keep current the OS support, there are a lot of folks like you and everyone can benefit from eachother. I've worked with plenty of old ARM chips, that are still supported with new kernels as there is demand for it, although the chips themselves are not used in new designs for ages.
In addition, the FPGA based soft-core stuff can not compete price-wise (bang for buck) with hard asic-s, that's why the FPGA vendors are adding their hard CPU IPs in there (ie Zynq).
As I understand the original poster, he needs a well-supported linux-running board to plug his PCI card into. Starting from scratch and designing your own hw usually breaks the budget unless your quantities are very large.

As for the imx6/7/8, afaik they have only pcie, not old pci. Finding and existing board with pci interface is not very probable. Of the new ARM Cortex-A SoC-s, the imx is one of my favourites at this time and considering the complexity of the chip, the amount of issues has been reasonably low.

[technix]

As for the imx6/7/8, afaik they have only pcie, not old pci. Finding and existing board with pci interface is not very probable. Of the new ARM Cortex-A SoC-s, the imx is one of my favourites at this time and considering the complexity of the chip, the amount of issues has been reasonably low.

PCIe to PCI bridge chips are widely available. For the i.MX 7 that has 4 PCIe lane's you can bridge one PCIe lane to PCI, and allocate the remaining 3 lanes to a x1 and a x2 M.2 slots, accepting one M.2 Wi-Fi + Bluetooth card and one M.2 NVMe SSD. The latter two are COTS modules.