Search the Community

That's a bit of a concern these days... We have a ipblock/processor (the AR100) that has better than root access to memory that can read/write at will I repeat - having access to memory is having access to OS and IO at a layer deeper than root... @chwe - yes, interesting indeed... Note the bloomberg thing with BMC's on servers... https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies Allwinner probably needs to be clear on what that AR100 does - not just a blob, but source...

merged it with daily tech news, I think it fits well here not? I thought that was already done, they call this intel management engine.. Well in arm world they push SPI flash for bootloaders. I assume there's plenty stuff left if you decide to hijack them.. Compared to the tiny one bloomberg claims to be there on the Supermicro boards.. Also most (all?) arm SoCs have some sort of a secondary microcontroller which could be compromised (e.g. Allwinners AR100) Let's face it. If they want, it's not much a problem to compromise *whatever device* they want. From network infrastructure, IoT garbage, mobile phones, tablets, etc. The only protection we have is an economical one. If it gets public, some govts. may decide that it's no longer allowed to fab critical infrastructure in china which will harm their industry (we would probably lose 5-10 years updates for such a critical infrastructure cause nobody here knows how to produce such stuff for an acceptable price anymore.. ). So is it worth to harm your electronics industry? Not my decision, I would assume it's not worth. Fact is nobody cares about the Snowden documents anymore and they had some enlightening SOPs for "how to be a good spy" in it.. A not govt. related one: smart engineers they have in the card payment industry. Angular momentum determination won't be the first thing which comes to my mind to determine if a card reader is compromised or not.

Try this This talks to AR100

Checking in... NanoPi-NEO v.1.31 with the OLED hat... need to be a bit specific as there are multiple HW revs of the NEO - v1.2 and later moved from LDO to a DC/DC regulator, so info from 1.0/1.1 might not be accurate these days - still sorting out the regulator in use, as there are a couple of options with Allwinner H3 there. I think it's the SY8113B, but hard to tell... Testing with Armbian 5.61 vs. FriendlyArm's 4.14.52 build for their OLED hat (I'd source a direct link, but they have two source - baidu and google drive) -- The friendlyarm image is pretty good with temps on the 4.14.52 kernel, typically around 31-33c idle, and I've not seen temps above 46c under load. the friendly arm image - the Clocks are pretty conservative - max cpu is 1.0GHz... I'm assuming that mem is at 432 defaults from allwinner bsp tinymembench... standard memcpy : 448.1 MB/s (2.9%) standard memset : 1448.4 MB/s (2.5%) (note - the NEO is well heat-sinked with the provided hs, and it's in a metal closure - it's the cute little item from friendlyarm... so one has the plate HS and the housing) My concern - armbian 5.61 ubuntu idles at 42c in the same scenario... it's the 10 degree difference that's interesting in idle state. subjectively - one can feel the housing warmer with the armbian 5.61 image running - but subjective results are never good... Looking into this, not sure which numbers to trust there - did friendlyarm pull in the dvfs changes? are they levering into the AR100 system manager block? Comment - as soon as one gets into AR100 - it's a blackbox blob - so some concerns there obviously as it's a system manager as such, perhaps better than superuser privs I'm assuming that current Allwinner armbian mainline pulls in the linux upstream here so some of the dvfs items haven't been pushed and accepted there. thoughts?

Kind of reminds me of the Intel System Management Engine - the AR100 block has direct access to memory outside of the ARM's, Mali, and Cedrus - could be a security concern... and the firmware blob from AW is a closed binary (some folks have decompiled it) Anyways - did some spelunking around the webs, and found this... https://github.com/allwinner-zh/linux-3.4-sunxi/tree/master/drivers/arisc I don't think mainline includes this, as there are other ways to do that functionality - some of the Orange PI images do it include it (remember the Orange Pi Zero overheating issue, where ARISC would spam the logs if the right image wasn't used).

Confirmed that AR100 is not involved with the FA Ubuntu 16.04 image, so that's solved... The FA image borrows a lot from the community at large - they do include all their add-ons to support the boards and hats - GPIO is incorrect as it tries to ID the board as an M1, not NEO, but there's a guy over in Japan that has a fix to sort that out. It does run better than the old Allwinner BSP, but they know that the GPU/VPU isn't fully baked yet, so if that's important, either the AW BSP or something else might be the right path until the bootlin stuff gets fully mainlined... Going to give another stab at 5.6, will try the Bionic release, rather than stretch which I tried a bit earlier.

here you go: http://linux-sunxi.org/AR100 Still think the AR100 could be somehow interesting.

Temp diff can be explained with using proper regulator bits ... but since there seem to be many different board revisions, it's a mess. This would be the first case, that some other kernel runs cooler than Armbian :) And it can also be false readings. Did you measure temps? DVFS is n/a in upstream 4.14.y kernel. FA took https://github.com/megous/linux/tree/orange-pi-4.14 as a base ... where DVFS is already implemented. They only added their board's settings and some board recognition to that fork. If boards heat powered down, there is not AR100 involved.

https://forum.armbian.com/search/?q=ar100 Someone will need to dig in.

there are a lot of things about AR100. unfortunately I dont have time to dig that real time processor. anyway i wont implement "shutdown " or "halt" to my project.

Normal. Board can't really power off properly due to ... cheap design. The only way is to make it into sleep mode with use of the AR100 coprocessor inside H2/H3 chip which support is in this state: http://linux-sunxi.org/AR100

Hoped to find something like voltage monitoring (on input) but as far as I understand the manual of the AXP805, there is no such possibility. Would it make a goods beginners board (as soon as kernel is 'in a good shape') cause it would avoid 'powering gone wrong'... - anyway, every barrel plug powered board is a bit more beginners friendly.. I don't follow sunxi mailing list fully (mostly cause I wouldn't understand most of the things discussed there.. ), but as I saw for the A64s PMIC was a bit problematic (handled by AR100, whereas complier for it is not GPL). As I understand, this issue was solved with those commits. Is the H6 also affected by such problems? (Allwinner had PMIC since a long time on the AR100 but it was possible to avoid using it). More experienced users have to decide if it's worth to use this kernel... But nice to see that allwinner publishes this stuff faster than in the past. btw. for those interested in it: https://github.com/Allwinner-Homlet?tab=repositories there you go.

There are some people in the linux-sunxi community that have started writing custom firmware for the AR100, do you follow #linux-sunxi on freenode? For hard real-time applications I would personally go for a setup where the motor control is done by a MCU (Cortex-Mx, AVR32...) and the high level stuff by a SBC...

Here is attempt to make mainline driver for AR100: https://github.com/mripard/linux/commits/sunxi/wip/ar100 But as branch name says, it's wip and not necessarly working. I didn't try it, I just though it might interest you.

@tkaiser This AR100 code seem to perform a hard reset on SoC, I don't think real shutdown can be accomplish with it, especially that there is no PMIC. The best I can see is that it could control a additional GPIO pin where users could attach some kind SSR to control the power line.

Well, I really don't know, because thread on OrangePi forum is too long to check. But if you go in this direction, I would worry more for GPL violations in kernel code. As it currently stand, H3 BSP kernel code is not really redistributable, because it contains at least three binary blobs which are statically linked with kernel. One situation is solvable (AR100 FW), but other two are not if you don't want to loose functionality (HDCP code and libisp, which is responsible for camera). OK, HDCP can be removed without much worries. There might also be other blobs. There is certainly one more for ethernet, but it seems to be redundant as code is available. Another issue are files without clear license. Some are missing terms completely and others have only copyrights asserted. This means that you probably can't make completely legal image with H3 BSP kernel. Another thing about mali - if I understand everything correctly, ARM had weird coditions for libMali redistributions until recently and r6p0 will be one of the first releases which can be redistributed without issues. Check this: https://lists.x.org/archives/xorg-devel/2016-June/050294.html