Search the Community
Showing results for 'AR100'.
-
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.
-
Allwinner H3 NanoPiNEO - hi temps on mainline vs. vendor build
Igor replied to sfx2000's topic in Allwinner sunxi
Try this This talks to AR100 -
Allwinner H3 NanoPiNEO - hi temps on mainline vs. vendor build
sfx2000 replied to sfx2000's topic in Allwinner sunxi
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). -
Allwinner H3 NanoPiNEO - hi temps on mainline vs. vendor build
sfx2000 replied to sfx2000's topic in Allwinner sunxi
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. -
Allwinner H3 NanoPiNEO - hi temps on mainline vs. vendor build
chwe replied to sfx2000's topic in Allwinner sunxi
here you go: http://linux-sunxi.org/AR100 Still think the AR100 could be somehow interesting. -
Allwinner H3 NanoPiNEO - hi temps on mainline vs. vendor build
Igor replied to sfx2000's topic in Allwinner sunxi
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. -
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?
-
https://forum.armbian.com/search/?q=ar100 Someone will need to dig in.
-
Orange Pi PC2 (H5) overheating after a shutdown
sametkocatepe replied to Moklev's topic in Allwinner sunxi
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.
-
Hi, guys. I need some help in understanding of usage AR100 (OpenRISC) coprocessor inside H3 SoC for the own real-time tasks. Now i'm using mainline kernel built with RT-PREEMPT patch. I'm using it with Machinekit (LinuxCNC) software to control stepper drivers/motors via GPIO step/dir pulses. But step pulses frequency is too slow (about 17 kHz) because the RT kernel latency is about 30 us. I think we can use the built-in coprocessor for the realtime GPIO toggling. The AR100 and main Cortex-A7 can talk to each other with built-in MSGBox. And the question is - how to launch my own firmware on the AR100 core?
-
@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