NanoPI M4

[mindee]

2 hours ago, lucho said:

I think that the hardware development is already complete, unlike the software development, which has only recently started and is progressing quickly (a new pre-release almost every day).

 

As to the hardware revisions, the difference between V1.0 and V2.0 is quite large. The difference between V2.0 and the July 2018 batch is only 1 omitted resistor (R895381), which was probably not needed in the first place. So the bare PCB can be the same as for V2.0. In general, the number of hardware revisions of a product is much lower than the number of software revisions. This is natural.

 

But what's interesting to me is how the price of RockPro64, Orange Pi RK3399, and other RK3399-based boards like the NanoPC T4 can be so low. As many of you probably don't know, the Chinese government subsidises Shenzhen Xunlong Software Company (the maker of the Orange Pi boards), and so they can afford to sell their boards at the BOM (Bill of Materials) cost, not following the "golden rule" that the retail price of a product must be 3 times higher than the BOM cost to pay salaries, depreciation allowances, etc. But their RK3399 board has only 2 GB of DRAM and 16 GB of eMMC flash memory and sells for $109. The 2 GB RockPro64 variant plus 16 GB eMMC sells for even less: just $75. How is this possible? Does the Chinese government subsidise Pine Microsystems as well? Unlikely! Then, what is the secret behind their astonishingly low prices?

 

NanoPi-M4 will be cheaper and same form factor as RPI 3. 

[lucho]

41 minutes ago, mindee said:

NanoPi-M4 will be cheaper and same form factor as RPI 3.

We're going off-topic here, but could you give some more details? Which SoC will the NanoPi-M4 use? Because there already is an RK3399-based board with the same size as Raspberry Pi 3 – the Rock960.

[mindee]

22 minutes ago, lucho said:

We're going off-topic here, but could you give some more details? Which SoC will the NanoPi-M4 use? Because there already is an RK3399-based board with the same size as Raspberry Pi 3 – the Rock960.

NanoPi-M4 is RK3399 based too, just no eMMC on board, and no so many interface as NanoPC-T4 So a little lower cost.

 

 

[chwe]

11 minutes ago, mindee said:

NanoPi-M4 is RK3399 based too, just no eMMC on board, and no so many interface as NanoPC-T4 So a little lower cost.

Do you have a pic from the top side too?  

 

34 minutes ago, lucho said:

We're going off-topic here

Maybe it would make sense to split them to a dedicated topic in case there comes more.  

[tkaiser]

2 hours ago, mindee said:

NanoPi-M4 is RK3399 based too

 

SoC on the appropriate PCB side (to be combined with a metal enclosure/baseplate efficiently dissipating the heat out of the enclosure)! This looks really nice. I would suspect we get 2 x USB3-A, 2 x USB2, Gigabit Ethernet but no PCIe and all the camera/display connectors?

2 hours ago, lucho said:

there already is an RK3399-based board with the same size as Raspberry Pi 3 – the Rock960

Not the same size. The Rock960 is 96boards compliant (the SBC standard without connectivity  )

2 hours ago, chwe said:

Maybe it would make sense to split them to a dedicated topic in case there comes more.

Please merge all the M4 stuff into a new 'NanoPI M4' thread. 

[chwe]

27 minutes ago, tkaiser said:

Please merge all the M4 stuff into a new 'NanoPI M4' thread. 

done

 

27 minutes ago, tkaiser said:

I would suspect we get 2 x USB3-A, 2 x USB2

 

Soldering holes looks more like 4x USB3 (so either something shared or a PCIe --> USB bridge, maybe the 3th bigger IC besides GbE-controller and SoC - don't have the eyes to read what's written on it). But that's more speculation..  Doesn't make much sense to speculate..  

 

I really hope that's a USB-C in the left corner and not a micro-USB would make powering at least a bit more save (5V GND RX/TX 'friendlyElec standard' header is at least there).

[tkaiser]

On 6/18/2018 at 11:33 PM, chwe said:

I really hope that's a USB-C in the left corner and not a micro-USB would make powering at least a bit more save

 

If there are 4 USB3 receptacles (either provided by an internal USB3 hub or with an own PCIe attached USB host controller) then USB consumers alone might take 18W (each USB3 port has to provide 900mA at 5V). With 2 x USB2 and 2 x USB3 it's only slightly better: 14W max by USB consumers. And the board needs some juice for its own so we're talking about 25-30W input requirements.

 

Unfortunately USB-C ports still have to provide only 900mA, the two more powerful USB-C 5V modes with 1.5A and 3A are optional (and insufficient too since only providing 7.5W or 15W). So without an USB-C charger capable of USB PD (power delivery specs) and supporting at least profile 3 (36W when switching to 12 V at 3A) USB-C isn't an advantage over a barrel plug. And it would also require NanoPi M4 being compliant to USB PD and able to cope with changing input voltages.

 

In other words: curious how powering will look like here... Will we see a 'dumb' 12V PSU with USB-C jack that is not USB PD compliant ready to fry normal USB-C devices?

[lucho]

12 hours ago, tkaiser said:

Not the same size.

Yes, indeed, it's slightly smaller.

 

But the NanoPi M4 looks like it's not only the same size as the Raspberry Pi 3, but also has the same connectors at the same places. So if it weren't the necessity of a heat sink on the RK3399 on the bottom side, it could be placed in an enclosure made for the Raspberry. But now, to use such enclosure, one has to cut a square hole rotated at 45 degrees for the heat sink.

 

If the connectors are the same and at the same places as on the Raspberry, then the microUSB power connector must be the one that supplies power. IMHO this SBC is too powerful for that.

[chwe]

50 minutes ago, lucho said:

If the connectors are the same and at the same places as on the Raspberry, then the microUSB power connector must be the one that supplies power

If you've to cut a square for the SoC anyway, then it doesn't hurt you to cut a bit around the microUSB hole to make it working for an USB-C... 

 

4 hours ago, tkaiser said:

Unfortunately USB-C ports still have to provide only 900mA, the two more powerful USB-C 5V modes with 1.5A and 3A are optional (and insufficient too since only providing 7.5W or 15W). So without an USB-C charger capable of USB PD (power delivery specs) and supporting at least profile 3 (36W when switching to 12 V at 3A) USB-C isn't an advantage over a barrel plug

Optional, but at least the connector allows it, whereas on microUSB the 1.8A at 5V is the max the specs allow. I don't say that USB-C is better than the good old barrel plug (my old notebook has a barrel, my new will have a USB-C --> it's not an apple ) but it's better than the microUSB.

 

5 hours ago, tkaiser said:

If there are 4 USB3 receptacles

Which other connector do you know with a 4pin 5pin layout? And if you count the solder-balls under the USB connector you see this 4-5 setup 4 times...  

 

I guess the picture from @mindee is an unofficial prototype, so things might change until official release.

 

5 hours ago, tkaiser said:

In other words: curious how powering will look like here  

They could replace the boring 3.5mm audiojack to something useful, like a 3.5mm barrel jack  At least, FriendlyElec knows that proper powering is important, they've enough experience. 

[lucho]

On 19 юни 2018 at 2:04 PM, chwe said:

They could replace the boring 3.5mm audiojack to something useful, like a 3.5mm barrel jack  At least, FriendlyElec knows that proper powering is important, they've enough experience.

The problem is not their experience, but the compatibility with the Raspberry Pi that they aim. This reminds me of the dreaded "IBM PC compatibility" which has tortured us for 37 years.

[Da Xue]

This is going to end up like another ASUS Tinkerboard. Shove a 15W+ design in a form factor designed for 5W. This really takes the cake since it has the SoC on the bottom where you can't even put a heatsink.

[TonyMac32]

20 minutes ago, Da Xue said:

This really takes the cake since it has the SoC on the bottom where you can't even put a heatsink.

 

Well, there are some options here that "SoC-on-top" designs don't allow for, such as mounting in an aluminum housing with the SoC dissipating into the enclosure.  I would take a guess a heatsink similar to the NanoPi Neo's in concept, which is also Soc-on-bottom, would be available. I agree with you in that some users will inevitably stuff one of these into some plastic Pi case and wonder why it doesn't work well, which won't be too much fun...

 

I also sincerely hope that is a Type-C USB poking out up there, so the 15 watts becomes a bit more manageable. (it does look like one)

[wtarreau]

On 6/18/2018 at 11:33 PM, chwe said:

I really hope that's a USB-C in the left corner and not a micro-USB.

It definitely is one, the size and shape leave no doubt about it.

 

I'm also seeing some symmetric lines routed to the GPIO2 connector, maybe it's USB2 that's brought there. Maybe even PCIe (though I doubt PCIe works fine on such large connectors since it requires very low capacitance).

 

I do also appreciate a lot the CPU on the correct side. Those who complain about the inability to use a heatsink in an RPi enclosure are also the ones not planning on using one anyway if it were on the other side   Also, very likely the other side will feature the DDR4 chips, and it will still be possible to use a heatsink there to spread most of the heat into the enclosure. But having an aluminum enclosure for such a design would be really great.

[tkaiser]

1 hour ago, wtarreau said:

But having an aluminum enclosure for such a design would be really great

 

No need for a full aluminium enclosure (to rip-off clueless users as today with FLIRC case and others). Just a thin thermal pad combined with an aluminium bottom plate combined with an enclosure top made out of plastic, wood or whatever is all that's needed: https://forum.armbian.com/topic/6794-pi-factor-cases/?do=findComment&comment=51529

 

[tkaiser]

BTW: For anyone thinking USB-C would make life easier and powering more reliable... please think about that USB-C compliance is a different thing than what we already get on SBCs and will see in the future. As an example the 'famous' Vim2 using an USB-C receptacle to be powered while not being USB-C compliant: http://forum.khadas.com/t/power-supply-suggestions/1221

[chwe]

3 hours ago, tkaiser said:

BTW: For anyone thinking USB-C would make life easier and powering more reliable...

Compared to microUSB, I still think it will...  It will not save us from bad PSUs nor cheap bad cables out of spec nor boardmakers don't do it 100% according to specs (I'm quite sure some of my microUSB devices have connectors out of specs soldered on it). Ohm's Law will still be true.. It's not the magic pill that solves you all kind of problems 

I guess, and that's more a guess than a fact checked statement the newer generation of PMICs will be optimized for USB-C. It may need one or two years until they show up on SBCs...

 

8 hours ago, wtarreau said:

It definitely is one, the size and shape leave no doubt about it.

I tried to calculate it with the size of the SoC (Pythagoras combined with paint.. ), problem microUSB connectors and USB-C don't differ much in size but you don't see something 'bent' on the connector so I think it's a type C too.. 

 

10 hours ago, Da Xue said:

This is going to end up like another ASUS Tinkerboard. Shove a 15W+ design in a form factor designed for 5W.

Hardkernel showed it ~1year ago how to convert a 'known overheater' (you could cool it appropriate but it seems that people had trouble in the beginning) into a device which is properly cooled even with a smaller pcb...  It's called the HC1, and I really don't  understand why others didn't pick up this concept (connectors on two sides and a big U-profile acting as a big heatsink). It's simple, it works and the top can be a cheap plastic case. 

 

I don't understand the RPi 'formfactor' for more powerful SBCs this makes only sense if the SoC has the same high/position as the RPi so that such cases work properly:

But this shows clearly the drawback of having the SoC on the topside.. Every change in the position of the SoC makes those cases worthless. If the SoC is on the bottom side this doesn't matter.. Just place the thermalpad on a different place and you're fine.  The RPi formfactor makes IMO only sense if the SoC isn't that powerful otherwise you just fool your customers that they think a cheap plastic case together with a Tinker board like heatsink will be sufficient to run the device. Pick up the things RPi solved (e.g. using the same CSI/DSI saves you from developing a own display or a camera for your board with the drawback that you've to write a driver/software which takes RPis design decisions into account). 

 

[TonyMac32]

Just for some levity since this is the "M" series of nanoPi's, the next one from this one has to be impossibly powerful and/or artificially intelligent:

 

https://www.imdb.com/title/tt0708481/

 

... Ideally it won't commandeer a starship and kill a ton of people though...

[tkaiser]

13 minutes ago, chwe said:

3 hours ago, tkaiser said:

BTW: For anyone thinking USB-C would make life easier and powering more reliable...

Compared to microUSB, I still think it will...

 

Again: http://forum.khadas.com/t/power-supply-suggestions/1221

 

If board makers use now an USB-C receptacle without being USB-C compliant then this is what happens:

• Good and standards compliant USB-C chargers won't work or will show stability issues under load. These standards compliant USB-C chargers will refuse to provide to 'dumb devices' more than 'Default USB power' (which is 500mA at 5V with USB2 and 900mA at 5V with USB3: so those chargers will provide up to 4.5W or maybe only just 2.5W). How to overcome this limitation? Use also a dumb PSU with an USB-C connector like Khadas does (2A at 5V -- already a bit on the low side). Is this better than a barrel plug? No.
• While the above 'dumb USB-C' misuse at 5V won't cause any harm it gets interesting once board makers start to repeat the game with 12V: again putting only an USB-C receptable on the board while not being fully USB-C compliant (would require USB PD and support for at least profile 3), selling also a 12V USB-C PSU to be combined with the board. Won't cause harm on the board but might fry other devices with USB-C receptacle that expect 5V only.

USB-C is a rather complex specification and wrt powering requires that both current and voltage will be negotiated between both ends of the cable (even roles should be negotiated!). Making one side dumb is asking for troubles  

[TonyMac32]

27 minutes ago, tkaiser said:

Making one side dumb is asking for troubles

Right, I've been poking around for a "usable" controller for a Type C receptacle, my BGA fab abilities are non-existent so far so I'm having no luck. 

 

[chwe]

6 minutes ago, tkaiser said:

How to overcome this limitation? Use also a dumb PSU with an USB-C connector like Khadas does (2A at 5V -- already a bit on the low side). Is this better than a barrel plug? No.

I don't argue that it is better than a barrel plug. I compared it with a microUSB, and if the boardmaker cares about USB-C spec for sure it will be better if they fuck up or don't care I'm sure the community will figure it out quite soon and those boards are on the shit list.. 

The only case I think an USB-C powering can be better than barrelplug is with a smart solution (e.g. level up to 12V in case there's a 12V device connected to the board and stay at 5V in case not, but I don't think smart solutions will show up soon). 

19 minutes ago, tkaiser said:

USB-C is a rather complex specification and wrt powering requires that both current and voltage will be negotiated between both ends of the cable (even roles should be negotiated!). Making one side dumb is asking for troubles  

One side dumb is IMO similar to two sides dump -  the situation we have at the moment for every/most microUSB powered board. I would love when every USB-C PSU would only bring 500mA in case there's no proper communication from the other side.. This would rule out shitty board immediately.  If a boardmaker wants to feed a power-hungry board over USB-C, it is possible (apple showed this a 'long time' ago with the macbook) if he care similar as in the past with microUSB those boards might have even bigger issues due to 'known good' chargers will simply deny to deliver 'over spec' current which is 'the right thing to do'. 'Good' boardmakers might spend some extra hours for proper powered boards over USB-C and in a perfect world, the ones not able or willing to deal with the more complex specification will switch to simple barrel plug (in fact they will stay with microUSB until nobody else uses it or will use dump USB-C solution which hopefully breaks that bad that the community recognizes it fast enough to avoid buying the board).  

The microUSB was a 'we need quickly a de facto standard, otherwise authorities will standardize which connector we've to use'-decision. The connector wasn't developed for this purpose and it's probably the 'lowest standard' everyone could agree with. Some of the issues where solved by USB-C some not (IMO apples MagSafe was a way smarter for powering only - probably not for DATA lines, but it saved my old macbook multiple times from falling down somewhere).

I think it's to early to say USB-C will be a fail but I agree with you that we will see boards where it isn't solved properly (as you pointed out with the vim). It has the potential to solve some of the issues but the boardmakers have to design it properly otherwise we've the same shitty situation we've since years with microUSB (or in case they do it really bad, it would be even worse) but the solution is simple:

 

Avoid every board/boardmaker who does it wrong until they get it...   

 

Shitty powered USB-C boards should be dropped from support or wip as soon as we figure out that it is an issue. We learned it with microUSB and we shouldn't make the same mistakes again and again. A board with only one USB-A can be properly powered over microUSB, every 'RPi a-like' 4 usb-ports powered over microUSB is IMO an error by design. You picked up a design decision from a boardmaker which has known powering issues since the beginning (RPi) and you made it even worse by 'forget' the shitty workaround in their second iteration of the board (throttling when under-voltage is detected). There was an excuse in the beginning (we didn't know it better) but it's known now (whereas now means the last two to three years or so... ).  

 

But back to topic, let's happily speculate what we see from the bottom side picture of a board which wasn't announced in public.. 

[ashthespy]

5 hours ago, TonyMac32 said:

Right, I've been poking around for a "usable" controller for a Type C receptacle, my BGA fab abilities are non-existent so far so I'm having no luck. 

 

I was recently looking at TI's catalogue and came across the TPS65987D

It a QFN so can be reflowed without having to worry of bga shorts. :-)

[lucho]

On 19 юни 2018 at 12:33 AM, chwe said:

I really hope that's a USB-C in the left corner and not a micro-USB would make powering at least a bit more save (5V GND RX/TX 'friendlyElec standard' header is at least there).

 

Yes, it really is one. It's about 1,5 times wider than the 6 mm diameter outer ring of the 3.5 mm audio jack (that is, about 9 mm wide), so it's USB-C indeed (micro USB is narrower, about 7 mm wide). But as someone here already noted, if one intends to use a Raspberry Pi enclosure and has to cut the lower part of it for the SoC heat sink and the upper part for the USB-C, why not cut the latter a bit more for the barrel jack? The decision to use USB-C for the power supply instead of microUSB is IMHO a halfway one and therefore a bad one, if a 5.5 mm barrel jack can be used instead, which would solve the high power supply current problem much, much better. Hopefully the shown photo is an early prototype and it's not too late for them to fix that.

[wtarreau]

On 6/24/2018 at 8:31 AM, tkaiser said:

 

No need for a full aluminium enclosure (to rip-off clueless users as today with FLIRC case and others). Just a thin thermal pad combined with an aluminium bottom plate combined with an enclosure top made out of plastic, wood or whatever is all that's needed: https://forum.armbian.com/topic/6794-pi-factor-cases/?do=findComment&comment=51529

 

Oh I definitely agree and that's what I was thinking as well in the case an RPi enclosure was used : cover all the bottom with a 1mm thick aluminum plate that will radiate the heat through the plastic over all this surface. After all my cardboard-made npi-fire3 enclosure is not far from this :-) BTW I wasn't aware of the FLIRC case at all.

[tkaiser]

47 minutes ago, wtarreau said:

I wasn't aware of the FLIRC case at all

 

According to this review https://youtu.be/mBSfb6vlfKo?t=6m37s the FLIRC case is a very poor performer compared to the 'Wicked Aluminium Raspberry Pi 3 Case'. There's also https://cogent.design but it seems they stopped their business of selling overpriced aluminium enclosures.

 

And all those enclosures are expensive like hell and I would guess not exactly environmentally friendly due to the need to process huge aluminium blocks?

 

Anyway: By putting the SoC on the right side of the PCB so that a simple metal plate + thermal compound/pad can be used to dissipate heat away all of this stuff is not necessary any more... 

 

[Help Me Stream]

Hi, I'm new to the forum and to Friendly ARM / non Raspberry Pi (Rpi) products in general, but was intrigued enough by the picture that Mindee posted of the NanoPi-M4 to risk commenting as a noob...

 

If this is, indeed, an Rpi form-factor compatible board, the GPIO has almost doubled in size. GPIO 101 in the picture Mindee posted aligns with the 40-pin header for a standard Rpi, but I don't recall seeing on any of the official Pi units a second 24-pin GPIO (labeled as GPIO 102 in the pic of the NanoPi-M4).

 

Any ideas what that might be for?

 

Given the intent of the RK3399 as a media-centric SoC, I could see a scenario where the RK3399 I2S audio could be pinned out for at least 8 audio receive and 8 audio send,. That would account for 16 of the extra 24 pins, and would also explain why additional real estate was needed on the topside of the board. Taking the burden off the 40-pin GPIO, which had limited audio and video output capabilities on the Rpi, perhaps the remaining 8 pins in GPIO 102 might be used for pinning out one of the multiple video display options?

Edited July 1, 2018 by Help Me Stream
Spelling

[tkaiser]

10 hours ago, Help Me Stream said:

Any ideas what that might be for?

 

No one here knows. So better monitor http://wiki.friendlyarm.com/wiki/index.php/Special:RecentChanges and wait for the M4 page appearing there.  

[Help Me Stream]

Thanks for the advice. In looking through the details on that Wiki, I see that there's an ADC onboard on the T4 (haven't received mine yet for review) so hoping the Nano will build on that (no pun).

 

With the addition of 4 USB 3.1 (gen 1, aka USB 3.0) Type A using two separate USB buses, as well as the Type-C connector for power (and assumed eDP 4 lane) as well as the addition of USB-over-HDMI (CEC) all clearly identifiable on the picture that Mindee posted, looks like the NanoPi-M4 will keep quite a bit of the basic media functionality...

[TonyMac32]

On 6/30/2018 at 5:02 AM, tkaiser said:

I would guess not exactly environmentally friendly due to the need to process huge aluminium blocks?

Well, if the manufacturing is done intelligently, the tailings get recycled nicely.  You could argue the energy involved in it, but I'd probably counter the cast ones use far more energy than simply machining out of large blocks.  In general aluminum and steel are quite "eco" compared to any plastic, and certainly better than say copper as far as mining/refining are concerned.  (off topic, but interesting)

[Moklev]

An extrusion process - compared to cnc machining - isn't more cheaper (economically and energetically)?

Like new Asus case for Tinker Board:
https://www.asus.com/Single-Board-Computer/Tinker-Fanless-Aluminum-Case/

[chwe]

7 hours ago, TonyMac32 said:

In general aluminum and steel are quite "eco" compared to any plastic,

Sources for your claim?  I didn't check it, ecologic footprints are like benchmarking, as soon as you start, you do it wrong...  Aluminium mining is a dirty  process due to its chemistry (e.g. starting with the Bayer-process followed by Hall–Héroult process). As a side-note, to my knowledge there's still no living thing using Al in an enzymatic cycle (Al does mostly insane thing as soon as it steps into an enzymatic cycle due to it's chemistry). Without fact checking, I would guess that cheap plastics (e.g. HDPE) are more eco, but as said I never made an 'overall benchmark' of resources. Steel acts different to aluminum in all stages, recycling, mining and production is IMO easier.

I think extrusions vs. milling is related to the number of cases you produce. Maybe @Da Xue can comment how much this differ in price for smaller batches of cases. Baseplate out of aluminum and topcase out of plastic (as done by the HC1/2 cases) is likely the most economical case, but people won't buy it due to: 'looks ugly'  / 'people don't understand that this works decent'.

If you design a SBC with casing in mind and not a 'okay we have a board, now let's design a case around it'-approach it shouldn't be a problem to design a decent working economically and ecologically case. Seems that SBC makers start to think more about it since those SoCs get more powerful and need a proper cooling to perform well. Now people must learn that a warm case is a good sign...  

BTW if you care about ecological issues, you should go through more or less every rare earth metal.. Extraction & separation of those are really a waste of energy..  But we go a bit off topic here..

 

I think it is more important to buy 'the right SoC for the right job'. E.g. I'm able to get the MT7623 throttling under heavy disc IO load, when the SSD is connected via USB3. It's not that much an issue when done via SATA (over asm1061). A good VPU might be a way cooler than a powerful CPU which is able to softwaredecode in multimedia use-cases. This is where software matters (kernel and userspace software stack).