Would it be possible to add an M.2 PCIe slot for NVMe or breakout-board for extenders on the bottom of a future H64 in RPi form factor? Stackable enclosures would also be a nice way of expanding the H64 to a desktop replacement or clustering purposes.
The HPC group at the Uni I work at are considering testing out miniclusters on ARM. At the moment, they're looking at a Cray solution. H64 could be a great way to do entry-level case studies or lower cost livetesting without breaking the compute clusters in production.
(06-22-2018, 02:03 PM)CaptainZalo Wrote: Would it be possible to add an M.2 PCIe slot for NVMe or breakout-board for extenders on the bottom of a future H64 in RPi form factor? Stackable enclosures would also be a nice way of expanding the H64 to a desktop replacement or clustering purposes.
The HPC group at the Uni I work at are considering testing out miniclusters on ARM. At the moment, they're looking at a Cray solution. H64 could be a great way to do entry-level case studies or lower cost livetesting without breaking the compute clusters in production.
Unless there is a suitable NVMe driver that can runs on H64 "model A" board, the board that same size as PINE A64, we not no plan to ass M.2 slot at the back for H64 "model B" based. based on currently layout complexity, adding M.2 this will push the PCB layer from 6 layer to 8 layer.
So exactly what are your plans?
Will you manufacture & sell two versions of H64 at the same time?
Ar forget rev A, and sell rev B only, which actually will be faster version of Rock64.
At first, I liked very much original H64, as I need faster "Rock64" alternative (or 64bit Tinker version).
M.2 or mPCI slot features possibility of connecteg LTE modem, which was very attractive option to me.
Do not get me wrong, I am still interested in rev B, but from my perspective Rock64 can be phased out 
Rock64 can be phased out - probably the best selling and popular PINE64 board? Also, do you know the state of Linux on the H6 and status of mainline?
I know it is popular.
Personally I have few of them, however for already two projects I was involved in I have recommended either RockPro or.. H64. It is about single thread CPU performance. In the image processing application (not media player alike device), 1.3 GHz of Rock64 is a bit to low for processing more than 120MB/s of video feed (over USB3) while desired speed is to be 180MB/s
Talking about H6, I know Linux kernel support exists, but PCI support does not, due to serious flaw in H6 design. That is why I stated above I am still interested in rev B.
Having Cortex A53 running with 1.8GHz clock is something I am eagerly awaiting to test my app on.
(06-25-2018, 03:59 AM)Arkadiusz Wrote: I know it is popular.
Personally I have few of them, however for already two projects I was involved in I have recommended either RockPro or.. H64. It is about single thread CPU performance. In the image processing application (not media player alike device), 1.3 GHz of Rock64 is a bit to low for processing more than 120MB/s of video feed (over USB3) while desired speed is to be 180MB/s
Talking about H6, I know Linux kernel support exists, but PCI support does not, due to serious flaw in H6 design. That is why I stated above I am still interested in rev B.
Having Cortex A53 running with 1.8GHz clock is something I am eagerly awaiting to test my app on.
I see what you are saying. But since everyone is working on mainline I expect that it will be some time before production-ready images will be available. That said, there are 3.10 images and 4.9 images may become available before mainline is ...
(06-24-2018, 08:13 PM)tllim Wrote: (06-22-2018, 02:03 PM)CaptainZalo Wrote: Would it be possible to add an M.2 PCIe slot for NVMe or breakout-board for extenders on the bottom of a future H64 in RPi form factor? Stackable enclosures would also be a nice way of expanding the H64 to a desktop replacement or clustering purposes.
The HPC group at the Uni I work at are considering testing out miniclusters on ARM. At the moment, they're looking at a Cray solution. H64 could be a great way to do entry-level case studies or lower cost livetesting without breaking the compute clusters in production.
Unless there is a suitable NVMe driver that can runs on H64 "model A" board, the board that same size as PINE A64, we not no plan to ass M.2 slot at the back for H64 "model B" based. based on currently layout complexity, adding M.2 this will push the PCB layer from 6 layer to 8 layer.
I've talked to Ole, one of our compute guys, and he got fired up about the "model A" board. There might be an order coming from us soon. Also, I didn't know the M.2 PCIe port would be that much hassle.
I was very pleased to see PineH64 and RockPro in the big size format. It's so much better, I don't get what this race for small size is for. Just to introduce unnecessary overheating and layout problems?
And yet the question - sorry it's not in the right place. I see that for rk3399, there is 4GB - 128MB possible space for SDRAM. Have I understood right, that for the 4GB model, 128MB of the so expensive and scarce RAM won't be accessible, thanks to Rockchip laziness of using wider system bus? Or I missed something?
ANT - my hobby OS for x86 and ARM.
(06-20-2018, 04:54 PM)tllim Wrote: Just receive the PINE H64 model B board, production will be arranged once once tested.
Attached is the model B photo.
How the tests are going? And appreciate if you could attach photo of the back side as well.
Hello, any bad or good news?
|
