chwe
-
Posts
1432 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by chwe
-
-
12 hours ago, shippy said:
Wouldn't it be nice if the main contributors who already are spending time answering lots of redundant questions start a wiki that is periodically updated to address main developments ? But then read my remark about techs.
the wiki is filled with a lot of useful information.. Multimedia related stuff is just not part of the main development...
@JMCC started to focus on it and I appreciate it. For me the main goal of the project is still a stable debian/ubuntu. As you figured out by yourself, the whole multimedia stuff is somehow limited for linux on arm.. More or less all SoCs armbian supports (besides the marvell ones) where made for Android devices and therefore all those 'nice specs' you read are often meant for android.
Update a wiki needs a lot of time. Support over forum needs time and maintaining Armbian needs a lot of time... We're not perfect and there's space for improvement so feel free to contribute.
For example by writing the stuff related to multimedia use cases in the documentation and send it as a PR (which will then show up in docs.armbian.com).
https://github.com/armbian/documentation
12 hours ago, shippy said:In any case most of my questions ( after #1 question) have been answered in this thread and via further research elsewhere.
There's nothing wrong about doing your own research. As for a lot of things opinions and facts are mixed everywhere, so a high google-fu helps to get a broader picture about he situation.
12 hours ago, shippy said:Bottom line is that these chip vendors are way behind with Linux kernel updates. Not much progress over last 3 years.
I don't think so, as @zador.blood.stained explained for non multimedia related stuff, there's a lot of progress.. And even for the multimedia related stuff, it starts to make fun when you choose the right SoC (e.g. RK3288 where @JMCC did the hard work bringing this to armbian and RockChip delivered the stuff so that it's possible to use it) and probably Allwinner in the future where bootlin brings hardware accelerated video decoding to mainline.
9 hours ago, shippy said:Compared to potential profits, such software development would be pennies to the dollar: always a matter of comparison, price vs performance.
I think this is true for android... but not really for linux, the average multimedia/tv box user doesn't care if there's Linux or Android in the background as long as it works.. Only those who want to avoid google products for whatever reason.
It was a good move from the RPi folks to bring up multimedia related stuff quite from the beginning (in terms of selling more devices), in terms of their 'educational goals', doing all this stuff in the blackbox called threadX is a bit questionable.. There's no chance to understand what happens there cause it's closed source. IMO, in terms of opensource RockChip does it better and linux-sunxi does it best (!= Allwinner).
9 hours ago, shippy said:There are reasons RPi has taken off despite high prices, Orange/Banana/ other Pis have not. And they include not just good chipset to board vendor relations, but also market vision, e.g., Amlogic and Rockchip vs Allwinner in the Android Box market.
The RPi foundation is good in explaining why an RPi is so much better than everything else (no matter if it's true or not)... They manage the community well so that the average RPi user doesn't move to an other SBC and when he moves, he doesn't understand why *random feature* doesn't work out of the box. People forget that this was true for RPi as well in the past... Their backwards compatibility back to the RPi1 is their biggest value but also their biggest problem. The board-design doesn't allow a proper powering and they stick to the VC as long as they don't want to loose everything they benefit from. In terms of their 'educational goal' the RPi is powerful enough, but the group which pays their paychecks will maybe start to look for other boards when their next major update suck too (only 1 USB2 which is responsible for network too, powering through microUSB which I think will start to make problems for their newest version, no cryptoengine and limited to 1GB ram etc.). But cause it is interesting on software side (every bigger software company develops for the RPi when they make something for SBCs, e.g. googles AIY kits, wolfram matematica even microsoft IoT
) people may stick to it.
5 hours ago, shippy said:RPi has always been expensive and the $5 RPi0 was just a joke.
The only thing the RPi is not... is expensive.. Compared to the longterm software-support you get the RPi is cheap as hell. Despite the industrial grade boards, I don't know many boardmakers which deliver a decent BSP kernel over such a long time.
6 hours ago, shippy said:$5-6 ESP32, with way better SBC specs. ESP8266 is a marvel at $1.50, but ESP32 is just hyped, IMHO.
ESPs are not SBCs (or at least not what I would define as a SBC)... Cause I don't care about bluetooth I should prefere the ESP8266 over the ESP32 (cause cheaper).. But I don't, I prefer to program those things in micropython and 128kb vs. 512kb ram make a huge difference there... It's all about use case. If you only handle one or two sensor, or if you care about power consumption or if you don't want to dig into datasheets on this small things someone wrote an arduino (or micropython) lib accessing the right registers over SPI, I2C for driving those sensors whereas you have to adjust them for a normal Linux useage. My normal setup is an OPi0 as an IoT server (obviously, I don't use the built in WiFi cause it's crap) for collecting all the data and make it accessible for my phone, notebook etc. and some ESP8266/32 for all my sensor nodes I need. It's all about what you need and not what's most powerful for it's price.. ESPs are long term available and the IoT server software runs on every SBC so I'm more or less independent from boardmakers.
-
it would make sense to figure out what's inside your network adapter (e.g. chipset)..
27 minutes ago, root said:Anyone here playing with USB network adapters?
for the one he tested:
QuoteSince I want Lite's both USB host ports for disks, I used the OTG port and a Micro USB to USB adapter: a simple iperf test against a GbE device showed 270/300 Mbits/sec (depending on direction).
do you need a second ETH port?
-
1 hour ago, JuniorJPDJ said:
If we have everything to get it officially supported I don't understand why it didn't become supported and there are no official builds :/
Possible reasons:
- lack of resources (every new board needs testing and maintaining and we still suffer from both)
- board is of minor interest (armbian is mainly for SBCs not TV boxes)
- lack of samples for the maintainer (building images for boards which can't be tested ends often in a lot more support questions which can't be answered cause no dev has the board not at hand to reproduce the issue)
- no schematics available
On 2.3.2018 at 5:28 PM, winit_a said:thank you for information
how to check tv box emmc version?might be a reason too.. Even SBC boardmakers make sometimes changes to SBCs which end in a complete mess cause there are no informations what they changed from revision to revision. For a cheap TV box which wasn't build for that propose, the situation get's even worse. They adjust their fex and since there aren't any updates it will work fine.. but how should a project like armbian deal with such a change? As soon as two hardware revisions are incompatible to each other, it needs more than one image, information for the end user which image he should use (and for sure, more support questions will came up cause the user picked the wrong image) and maintaining one TV box which not that exciting features ends in maintaining at least two other images. The only TV box which is officially supported by Armbian is the Beelink X2 which found the way to mainline (from device tree side).
Images for the box can be built with armbians buildscript and in case something doesn't work as expected, this thread fits perfect to discuss the issues.
btw @winit_a opening the box, look for the second largest chip on the board which doesn't look like ramchips and google for some text you found on it might be a reasonable approach.
the one, on the leftside to the two ram chips next to UART looks like an eMMC (don't sure if my eyes are good enough, but it looks like something KLM8... is written to it which is probably cheap Samsung 8GB eMMC. As far as I know cheap nand on such boards are never BGA chips (so you should see some pads going to the NAND.
-
As far as I see, AES should be enabled by default no matter which kernel you use (dev or default).
but as Igor suggested, testing might be much faster than waiting until someone has confirmed it. Especially when you have tested other images the efforts to test Armbians nightly is a minor effort..
-
4 minutes ago, q-bert said:
Is AES / crypto enabled?
btw. We have some special features on our site called: SEARCH
an amazing tool to find informations about the things you search for...
-
27 minutes ago, nachoparker said:
I was asked a few questions regarding kernel configuration ( see attached file ). Seems like defconf doesn't cover all options.
Happens when the kernel which we use gets updated and adjustments from a dev weren't made to make sure this changes work for building a new image (or in this case only in the development branch of our buildscript). A nice example what's done 'behind the scenes' and how much efforts it needs to keep the project running.
(keep in mind, this has to be done for ~30 different kernels)
38 minutes ago, nachoparker said:I tried the defaults and the resulting image doesn't boot.
If you dive into development, I strongly suggest that you have a USB-UART console at hand to provide a boot-log. The image doesn't boot is not enough information to help you solving the issues you have.
22 minutes ago, Igor said:I am not sure master is updated for Rock64.
would it make sense to check out with specific tags for the master branch to make sure 'everything works'? I'm a complete git noob and not sure if tags are used by the repos we use.
Seems that RK uses tags, this might slow down the 'update speed' a little bit, but would avoid such issues (e.g. keep development branch at master and our master at the last tag provided by the kerneldeveloper - for bsp kernels).
-
1 hour ago, Rashmi said:
please help me its urgent
since this sensor was never mentioned in this thread, don't expect that someone has a fast solution. We do not provide support for every 3th party hardware gadget which is available...
https://github.com/adafruit/Adafruit-Fingerprint-Sensor-Library
http://www.rhydolabz.com/wiki/?p=15770
https://github.com/bastianraschke/pyfingerprint
might be your starting points...
Edit:
by using google.. you would have one hour more for your urgent problem...
-
I played a bit with the SenseHAT from the RPi guys. Doesn't work fully but I get the first things working.
What does run:
- Joystick
- 8x8 led matrix (partly, seems that there are some parts of the framebuffer not fully working)
What doesn't run:
- all the sensors attached on the board
What's missing:
- load it devicetree overlay (at the moment it's coded into the main dts)
- how-to what's needed to get it working on your tinker too
I'll keep you updated.
-
ahh saw my mistake.. I drive the LED directly from the GPIO (I know this not recommended, but it's sunday and I'm lazy
)..
@TonyMac32 would be upset when he see how I treat my boards..
Edit: note to myself, I should read the comments people write to their code before complaining...
@martinayotte J'ai choisi la première voie..
-
super fast, like a drive-in service.
(and it works!)
btw. there's a small mistake in the ledtest example:
# Pin 12 set to output AIOAddGPIO(12, GPIO_OUT) # LED on AIOWriteGPIO(12, 0) time.sleep(3) # LED off AIOWriteGPIO(12, 1) AIORemoveGPIO(12) AIOShutdown() ...
led on should be 1 and led off should be 0..
As it is written now, the pin stays high after finishing the script.
-
Today I had some time playing with GPIOs once again.. and I thought I should give ArmbianIO a try.
Unfortunately, wrapper.sh failed on the very last step:
opi@orangepizero:~/ArmbianIO/python$ sudo ./wrapper.sh /usr/local/bin/pip Status: Preprocessing /tmp/tmp9Kozky.h Status: gcc -E -U __GNUC__ -dD "-Dinline=" "-D__inline__=" "-D__extension__=" "-D_Bool=uint8_t" "-D__const=const" "-D__asm__(x)=" "-D__asm(x)=" "-DCTYPESGEN=1" /tmp/tmp9Kozky.h Status: Parsing /tmp/tmp9Kozky.h Status: Processing description list. Status: Writing to armbianio/armbianio.py. Status: Wrapping complete. Directory '.' is not installable. File 'setup.py' not found.the files are generated but I saw that you removed setup.py from your github on feb. What did I wrong?
Calling the libary from command line (as long as I'm in the right folder) works, but it's not registered as a library to call it from scripts..
System: OPi0, Debian stretch mainline (4.14.18)
-
53 minutes ago, micktol said:
I installed omv with armbian-config is this the correct way?
it is.. In the past some of the tweaks where not applied when you install OMV that way, so starting from OMV image directly was the better way (don't know if this is still true). You can build OMV images on your own with armbians buildscript or download them directly from here: https://sourceforge.net/projects/openmediavault/
-
-
use @Larry Banks gpio lib (ArmbianIO). Write your backbone in C or python with CGI and you're fine... And then write a nice tutorial for:
https://forum.armbian.com/forum/26-research-guides-tutorials/
to overcome the
6 hours ago, TonyMac32 said:chicken and egg problem
for toggle 2-3 GPIOs, this shouldn't be such a hard task and probably a nice 'starting project'.
-
18 minutes ago, wocketpatch said:
I found another forum post that says root is disabled via SSH by default.
where did you found that?
Do you have a USB-UART dongle to see what happens during boot? I guess you never saw the first boot login where you have to change the root password?
-
7 minutes ago, unoboard said:
Raspberry has an overabundance of people sharing what they have created
There you go: https://forum.armbian.com/forum/26-research-guides-tutorials/
8 minutes ago, unoboard said:Should I learn to write some code and get the satisfaction of making it work by myself or should I wait for a future Armbian wave to catch?
It might be unlikely that someone create something that fulfills exactly your needs until you pay him to do the job.. So having a basic background of 'what the code does' and how you can adjust it to your needs might be helpful to speed up things...
The project you mentioned uses npm rpio, which is furthermore based on gpiomem (rootless mem access for GPIO pins), something armbian hasn't implemented (only for testings on the tinkerboard). This would need for sure a lot of adjustments before it works on your board.
-
Since we have now the development branch implemented in armbians build script, we may need some 'rules' and procedures how and when we merge things to master to ensure they don't break something but don't get lost in the dev branch forever. A small annotation for external contributors when they should send PRs to which branch could also be helpful.
-
Fluid dynamics is like diffusion... A lot of calculations with results which are never correct.. Like Fick's law...
2.54mm pitch holes would be useful for a mini breadboard for prototyping... It's obvious that the user has to cut out bigger holes when he needs it as for better ventilation.. or a solid Cu surface and building a 'sandwich' with the Cu-foams from the RPi thread and spread the heat through the whole mezzanine board...
-
1 hour ago, TonyMac32 said:
Chuck is a member of the Church of Darwin.
Chuck says to the PSU that it should step down to 5.2V
2 minutes ago, TonyMac32 said:@JMCC's slots for cooling, we'll see if the fab gets mad about that. ;-)
make 2.54mm holes and they can't judge you.. people can drill out the hole they need..
4 minutes ago, TonyMac32 said:Thicker traces for power and an improved area around the header pins to reduce the drop there as well
Do you feed all possible VCC pins?
symbol and written (center positive)... Does it come from the american 'don't dry your dog in the microwave' warning' (an evergreen joke when we were young...
)
-
problem is.. chuck can handle everything... It must be DAU approved ('dümmster anzunehmender User' - dumbest possible user) to be a good board..
-
6 hours ago, jkljkl1197 said:
No one have new about Sony IMX219 support?
it's everything there to try it on your own..
I decided that I need a break from the tinker cam cause it's frustrating to get oop as a first boot message.. Since my buildmachine is only limited usable. I build on a old desktop machine which doesn't have a screen and everything is through ssh --> copying to my notebook prior to flashing it to SD-Card (wifi card is broken, and the stick which is attached to it performs very bad), I'm not that motivated to build as much images as possible to nail down the problem. And I'm not experienced enough to figure out the problems without a 'try and error' approach..
So any help and findings what might help is appreciated..
-
seems that RK patched the kernel to 4.4.120
Spoiler[ warn ] * [l][c] 04-patch-4.4.114-115.patch [ failed ] [ warn ] * [l][c] 04-patch-4.4.115-116.patch [ failed ] [ warn ] * [l][c] 04-patch-4.4.116-117.patch [ failed ] [ warn ] * [l][c] 04-patch-4.4.117-118.patch [ failed ] [ warn ] * [l][c] 04-patch-4.4.118-119.patch [ failed ] ... [ warn ] * [l][c] 220_uart4_fix.patch [ failed ] ... scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * Pin controllers * Debug PINCTRL calls (DEBUG_PINCTRL) [N/y/?] n AMD GPIO pin control (PINCTRL_AMD) [N/y/?] n One-register-per-pin type device tree based pinctrl driver (PINCTRL_SINGLE) [N/m/y/?] n Pinctrl and GPIO driver for RK805 PMIC (PINCTRL_RK805) [N/m/y/?] (NEW) y * * Multimedia support * Multimedia support (MEDIA_SUPPORT) [Y/n/m/?] y * * Multimedia core support * Cameras/video grabbers support (MEDIA_CAMERA_SUPPORT) [Y/n/?] y Analog TV support (MEDIA_ANALOG_TV_SUPPORT) [N/y/?] n Digital TV support (MEDIA_DIGITAL_TV_SUPPORT) [Y/n/?] y AM/FM radio receivers/transmitters support (MEDIA_RADIO_SUPPORT) [N/y/?] n Software defined radio support (MEDIA_SDR_SUPPORT) [N/y/?] n Remote Controller support (MEDIA_RC_SUPPORT) [N/y/?] n HDMI CEC support (MEDIA_CEC_SUPPORT) [N/y/?] n Media Controller API (MEDIA_CONTROLLER) [N/y/?] n Enable advanced debug functionality on V4L2 drivers (VIDEO_ADV_DEBUG) [N/y/?] n Enable old-style fixed minor ranges on drivers/video devices (VIDEO_FIXED_MINOR_RANGES) [N/y/?] n DVB Network Support (DVB_NET) [Y/n/?] y maximum number of DVB/ATSC adapters (DVB_MAX_ADAPTERS) [8] 8 Dynamic DVB minor allocation (DVB_DYNAMIC_MINORS) [N/y/?] n * * Media drivers * * * Media USB Adapters * Media USB Adapters (MEDIA_USB_SUPPORT) [Y/n/?] y * * Webcam devices * USB Video Class (UVC) (USB_VIDEO_CLASS) [Y/n/m/?] y UVC input events device support (USB_VIDEO_CLASS_INPUT_EVDEV) [N/y/?] n * * GSPCA based webcams * GSPCA based webcams (USB_GSPCA) [N/m/y/?] n USB Philips Cameras (USB_PWC) [N/m/y/?] n CPiA2 Video For Linux (VIDEO_CPIA2) [N/m/y/?] n USB ZR364XX Camera support (USB_ZR364XX) [N/m/y/?] n USB Syntek DC1125 Camera support (USB_STKWEBCAM) [N/m/y/?] n USB Sensoray 2255 video capture device (USB_S2255) [N/m/y/?] n USBTV007 video capture support (VIDEO_USBTV) [N/m/y/?] n * * Analog/digital TV USB devices * Auvitek AU0828 support (VIDEO_AU0828) [M/n/y/?] m Auvitek AU0828 v4l2 analog video support (VIDEO_AU0828_V4L2) [Y/n/?] y * * Digital TV USB devices * Support for various USB DVB devices v2 (DVB_USB_V2) [Y/n/m/?] y Afatech AF9015 DVB-T USB2.0 support (DVB_USB_AF9015) [M/n/y/?] m Afatech AF9035 DVB-T USB2.0 support (DVB_USB_AF9035) [M/n/y/?] m Anysee DVB-T/C USB2.0 support (DVB_USB_ANYSEE) [M/n/y/?] m Alcor Micro AU6610 USB2.0 support (DVB_USB_AU6610) [M/n/y/?] m AzureWave 6007 and clones DVB-T/C USB2.0 support (DVB_USB_AZ6007) [M/n/y/?] m Intel CE6230 DVB-T USB2.0 support (DVB_USB_CE6230) [M/n/y/?] m E3C EC168 DVB-T USB2.0 support (DVB_USB_EC168) [M/n/y/?] m Genesys Logic GL861 USB2.0 support (DVB_USB_GL861) [M/n/y/?] m MxL111SF DTV USB2.0 support (DVB_USB_MXL111SF) [M/n/y/?] m Realtek RTL28xxU DVB USB support (DVB_USB_RTL28XXU) [M/n/y/?] m DVBSky USB support (DVB_USB_DVBSKY) [M/n/y/?] m Siano SMS1xxx based MDTV receiver (SMS_USB_DRV) [N/m/y/?] n Technisat/B2C2 Air/Sky/Cable2PC USB (DVB_B2C2_FLEXCOP_USB) [M/n/y/?] m Enable debug for the B2C2 FlexCop drivers (DVB_B2C2_FLEXCOP_USB_DEBUG) [N/y/?] n Abilis AS102 DVB receiver (DVB_AS102) [M/n/y/?] m * * Webcam, TV (analog/digital) USB devices * Empia EM28xx USB devices support (VIDEO_EM28XX) [N/m/y] n * * V4L platform devices * V4L platform devices (V4L_PLATFORM_DRIVERS) [Y/n/?] y SoC camera support (SOC_CAMERA) [Y/n/m/?] y platform camera support (SOC_CAMERA_PLATFORM) [M/n/y/?] m Rockchip cif isp10 camera sensors (VIDEO_RK_CIF_ISP10) [Y/n/m/?] y * * Memory-to-memory multimedia devices * Memory-to-memory multimedia devices (V4L_MEM2MEM_DRIVERS) [Y/n/?] y Deinterlace support (VIDEO_MEM2MEM_DEINTERLACE) [N/m/y/?] n SuperH VEU mem2mem video processing driver (VIDEO_SH_VEU) [N/m/y/?] n Rockchip Raster 2d Grapphic Acceleration Unit (VIDEO_ROCKCHIP_RGA) [Y/n/m/?] y Rockchip ROCKCHIP VPU driver (VIDEO_ROCKCHIP_VPU) [Y/n/m/?] y * * Media test drivers * Media test drivers (V4L_TEST_DRIVERS) [Y/n] y Virtual Video Test Driver (VIDEO_VIVID) [N/m/y/?] n Virtual Memory-to-Memory Driver (VIDEO_VIM2M) [N/m/y/?] n * * DVB platform devices * DVB platform devices (DVB_PLATFORM_DRIVERS) [Y/n/?] y STMicroelectronics C8SECTPFE DVB support (DVB_C8SECTPFE) [M/n/y/?] m Support for Rockchip TSP (ROCKCHIP_TSP) [N/y/?] (NEW) n * * Supported MMC/SDIO adapters * Siano SMS1xxx based MDTV via SDIO interface (SMS_SDIO_DRV) [N/m/y/?] n Cypress firmware helper routines (CYPRESS_FIRMWARE) [M/y] m * * Media ancillary drivers (tuners, sensors, i2c, frontends) * Autoselect ancillary drivers (tuners, sensors, i2c, frontends) (MEDIA_SUBDRV_AUTOSELECT) [Y/n/?] y * * Sensors used on soc_camera driver * * * soc_camera sensor drivers * imx074 support (SOC_CAMERA_IMX074) [N/m/y/?] n mt9m001 support (SOC_CAMERA_MT9M001) [N/m/y/?] n mt9m111, mt9m112 and mt9m131 support (SOC_CAMERA_MT9M111) [N/m/y/?] n mt9t031 support (SOC_CAMERA_MT9T031) [N/m/y/?] n mt9t112 support (SOC_CAMERA_MT9T112) [N/m/y/?] n mt9v022 and mt9v024 support (SOC_CAMERA_MT9V022) [N/m/y/?] n ov2640 camera support (SOC_CAMERA_OV2640) [N/m/y/?] n ov5642 camera support (SOC_CAMERA_OV5642) [N/m/y/?] n ov6650 sensor support (SOC_CAMERA_OV6650) [N/m/y/?] n ov772x camera support (SOC_CAMERA_OV772X) [N/m/y/?] n ov9640 camera support (SOC_CAMERA_OV9640) [N/m/y/?] n ov9740 camera support (SOC_CAMERA_OV9740) [N/m/y/?] n rj54n1cb0c support (SOC_CAMERA_RJ54N1) [N/m/y/?] n tw9910 support (SOC_CAMERA_TW9910) [N/m/y/?] n ov8858 driver adapt to rockchip cif isp platform (VIDEO_OV8858) [N/m/y/?] n ov2710 driver adapt to rockchip cif isp platform (VIDEO_OV2710) [N/m/y/?] n ov4689 driver adapt to rockchip cif isp platform (VIDEO_OV4689) [N/m/y/?] n imx323 driver adapt to rockchip cif isp platform (VIDEO_IMX323) [N/m/y/?] n ov7750 driver adapt to rockchip cif isp platform (VIDEO_OV7750) [N/m/y/?] n tc358749xbg driver adapt to rockchip cif isp platform (VIDEO_TC358749XBG) [N/m/y/?] n adv7181 driver adapt to rockchip cif isp platform (VIDEO_ADV7181) [N/m/y/?] n ov7675 driver adapt to rockchip cif isp platform (VIDEO_OV7675) [N/m/y/?] n nt99230 driver adapt to rockchip cif isp platform (VIDEO_NT99230) [N/m/y/?] n ov13850 driver adapt to rockchip cif isp platform (VIDEO_OV13850) [N/m/y/?] n camsys driver (CAMSYS_DRV) [N/m/y] n rockchip supported soc cameras (ROCK_CHIP_SOC_CAMERA) [N/m/y] n * * ALSA for SoC audio support * ALSA for SoC audio support (SND_SOC) [Y/n/m/?] y SoC Audio for the Atmel System-on-Chip (SND_ATMEL_SOC) [N/m/y/?] n Synopsys I2S Device Driver (SND_DESIGNWARE_I2S) [N/m/y/?] n * * SoC Audio for Freescale CPUs * * * Common SoC Audio options for Freescale CPUs: * Asynchronous Sample Rate Converter (ASRC) module support (SND_SOC_FSL_ASRC) [N/m/y/?] n Synchronous Audio Interface (SAI) module support (SND_SOC_FSL_SAI) [N/m/y/?] n Synchronous Serial Interface module (SSI) support (SND_SOC_FSL_SSI) [N/m/y/?] n Sony/Philips Digital Interface (S/PDIF) module support (SND_SOC_FSL_SPDIF) [N/m/y/?] n Enhanced Serial Audio Interface (ESAI) module support (SND_SOC_FSL_ESAI) [N/m/y/?] n Digital Audio Mux module support (SND_SOC_IMX_AUDMUX) [N/m/y/?] n ASoC support for Rockchip (SND_SOC_ROCKCHIP) [Y/n/m/?] y Rockchip I2S Device Driver (SND_SOC_ROCKCHIP_I2S) [Y/?] y Rockchip I2S/TDM Device Driver (SND_SOC_ROCKCHIP_I2S_TDM) [N/m/y/?] (NEW) n Rockchip PDM Controller Driver (SND_SOC_ROCKCHIP_PDM) [N/m/y/?] n Rockchip SPDIF Device Driver (SND_SOC_ROCKCHIP_SPDIF) [Y/n/m/?] y ASoC support for Rockchip boards using a DA7219 codec (SND_SOC_ROCKCHIP_DA7219) [N/m/y/?] n ASoC support for Rockchip built-in HDMI and CODEC IC (SND_SOC_ROCKCHIP_HDMI_ANALOG) [Y/n/m/?] y ASoC support for Rockchip built-in HDMI and DP (SND_SOC_ROCKCHIP_HDMI_DP) [N/m/y/?] n ASoC support for Rockchip boards using a MAX98090 codec (SND_SOC_ROCKCHIP_MAX98090) [Y/n/m/?] y ASoC support for Rockchip multicodecs (SND_SOC_ROCKCHIP_MULTICODECS) [N/m/y/?] (NEW) y ASoC support for Rockchip boards using a RT5645/RT5650 codec (SND_SOC_ROCKCHIP_RT5645) [Y/n/m/?] y ASoC support for Rockchip boards RT5651 TC358749 HDMIIN (SND_SOC_ROCKCHIP_RT5651_TC358749) [N/m/y/?] n ASoC support for Rockchip CDN DP common codec (SND_SOC_ROCKCHIP_CDNDP) [N/m/y/?] n * * Allwinner SoC Audio support * Allwinner A10 Codec Support (SND_SUN4I_CODEC) [N/m/y/?] n XTFPGA I2S master (SND_SOC_XTFPGA_I2S) [N/m/y/?] n * * CODEC drivers * Build generic ASoC AC97 CODEC driver (SND_SOC_AC97_CODEC) [N/m/y] n Analog Devices ADAU1701 CODEC (SND_SOC_ADAU1701) [N/m/y] n AKM AK4104 CODEC (SND_SOC_AK4104) [N/m/y] n AKM AK4554 CODEC (SND_SOC_AK4554) [N/m/y] n AKM AK4613 CODEC (SND_SOC_AK4613) [N/m/y] n AKM AK4642 CODEC (SND_SOC_AK4642) [N/m/y] n AKM AK5638 CODEC (SND_SOC_AK5386) [N/m/y] n Realtek ALC5623 CODEC (SND_SOC_ALC5623) [N/m/y] n Cirrus Logic CS35L32 CODEC (SND_SOC_CS35L32) [N/m/y] n Cirrus Logic CS42L51 CODEC (I2C) (SND_SOC_CS42L51_I2C) [N/m/y] n Cirrus Logic CS42L52 CODEC (SND_SOC_CS42L52) [N/m/y] n Cirrus Logic CS42L56 CODEC (SND_SOC_CS42L56) [N/m/y] n Cirrus Logic CS42L73 CODEC (SND_SOC_CS42L73) [N/m/y] n Cirrus Logic CS4265 CODEC (SND_SOC_CS4265) [N/m/y] n Cirrus Logic CS4270 CODEC (SND_SOC_CS4270) [N/m/y] n Cirrus Logic CS4271 CODEC (I2C) (SND_SOC_CS4271_I2C) [N/m/y] n Cirrus Logic CS4271 CODEC (SPI) (SND_SOC_CS4271_SPI) [N/m/y] n Cirrus Logic CS42448/CS42888 CODEC (I2C) (SND_SOC_CS42XX8_I2C) [N/m/y] n Cirrus Logic CS4349 CODEC (SND_SOC_CS4349) [N/m/y] n CX2072X CODEC (SND_SOC_CX2072X) [N/m/y] n CX20810 is a voice capture ic. (SND_SOC_CX20810) [N/m/y/?] n dummy codec (SND_SOC_DUMMY_CODEC) [N/m/y] (NEW) y bt sco audio (SND_SOC_BT_SCO) [N/m/y] n Everest Semi ES8316 CODEC (SND_SOC_ES8316) [N/m/y] n Everest Semi ES8323 CODEC (SND_SOC_ES8323) [Y/n/m] y Everest Semi ES8328 CODEC (SND_SOC_ES8328) [N/m/y] n Everest Semi ES8328 CODEC I2C (SND_SOC_ES8328_I2C) [N/m/y] n Everest Semi ES8396 CODEC (SND_SOC_ES8396) [N/m/y] n GTM601 UMTS modem audio codec (SND_SOC_GTM601) [N/m/y] n gva codec (SND_SOC_GVA_CODEC) [N/m/y] n Voice Processor support for FM1288 (SND_SOC_FM1288) [N/m/y/?] n Texas Instruments PCM1681 CODEC (SND_SOC_PCM1681) [N/m/y] n Texas Instruments PCM1792A CODEC (SND_SOC_PCM1792A) [N/m/y] n Texas Instruments PCM512x CODECs - I2C (SND_SOC_PCM512x_I2C) [N/m/y] n Texas Instruments PCM512x CODECs - SPI (SND_SOC_PCM512x_SPI) [N/m/y] n Rockchip RK312X CODEC (SND_SOC_RK312X) [N/m/y] n Rockchip RK3228 CODEC (SND_SOC_RK3228) [N/m/y] n Rockchip RK3308 CODEC (SND_SOC_RK3308) [N/m/y] (NEW) n Rockchip RK3328 CODEC (SND_SOC_RK3328) [N/m/y] n Rockchip RK817 CODEC (SND_SOC_RK817) [N/m/y] n Realtek RT5616 CODEC (SND_SOC_RT5616) [Y/n/m] y Realtek ALC5631/RT5631 CODEC (SND_SOC_RT5631) [N/m/y] n Realtek ALC5640 CODEC (SND_SOC_RT5640) [Y/n/m] y Realtek ALC5651 CODEC (SND_SOC_RT5651) [N/m/y] n Freescale SGTL5000 CODEC (SND_SOC_SGTL5000) [N/m/y] n SiRF SoC internal audio codec (SND_SOC_SIRF_AUDIO_CODEC) [N/m/y] n S/PDIF CODEC (SND_SOC_SPDIF) [Y/n/m] y Analog Devices SSM2602 CODEC - SPI (SND_SOC_SSM2602_SPI) [N/m/y] n Analog Devices SSM2602 CODEC - I2C (SND_SOC_SSM2602_I2C) [N/m/y] n Analog Devices ssm4567 amplifier driver support (SND_SOC_SSM4567) [N/m/y] n STA326, STA328 and STA329 speaker amplifier (SND_SOC_STA32X) [N/m/y] n STA350 speaker amplifier (SND_SOC_STA350) [N/m/y] n codec Audio support for STI SAS codec (SND_SOC_STI_SAS) [N/m/y] n Texas Instruments TAS2552 Mono Audio amplifier (SND_SOC_TAS2552) [N/m/y] n Texas Instruments TAS5086 speaker amplifier (SND_SOC_TAS5086) [N/m/y] n Texas Instruments TAS5711/TAS5717/TAS5719 power amplifiers (SND_SOC_TAS571X) [N/m/y] n Toshiba TC358749X HDMI in Audio codec (SND_SOC_TC358749X) [M/n/y] m NXP Semiconductors TFA9879 amplifier (SND_SOC_TFA9879) [N/m/y] n Texas Instruments TLV320AIC23 audio CODEC - I2C (SND_SOC_TLV320AIC23_I2C) [N/m/y] n Texas Instruments TLV320AIC23 audio CODEC - SPI (SND_SOC_TLV320AIC23_SPI) [N/m/y] n Texas Instruments TLV320AIC31xx CODECs (SND_SOC_TLV320AIC31XX) [N/m/y] n Texas Instruments TLV320AIC3x CODECs (SND_SOC_TLV320AIC3X) [N/m/y] n TI Headset/Mic detect and keypress chip (SND_SOC_TS3A227E) [Y] y Wolfson Microelectronics WM8510 CODEC (SND_SOC_WM8510) [N/m/y] n Wolfson Microelectronics WM8523 DAC (SND_SOC_WM8523) [N/m/y] n Wolfson Microelectronics WM8523 CODEC (SND_SOC_WM8580) [N/m/y] n Wolfson Microelectronics WM8711 CODEC (SND_SOC_WM8711) [N/m/y] n Wolfson Microelectronics WM8728 DAC (SND_SOC_WM8728) [N/m/y] n Wolfson Microelectronics WM8731 CODEC (SND_SOC_WM8731) [N/m/y] n Wolfson Microelectronics WM8737 ADC (SND_SOC_WM8737) [N/m/y] n Wolfson Microelectronics WM8737 DAC (SND_SOC_WM8741) [N/m/y] n Wolfson Microelectronics WM8750 CODEC (SND_SOC_WM8750) [N/m/y] n Wolfson Microelectronics WM8753 CODEC (SND_SOC_WM8753) [N/m/y] n Wolfson Microelectronics WM8770 CODEC (SND_SOC_WM8770) [N/m/y] n Wolfson Microelectronics WM8776 CODEC (SND_SOC_WM8776) [N/m/y] n Wolfson Microelectronics WM8804 S/PDIF transceiver I2C (SND_SOC_WM8804_I2C) [N/m/y] n Wolfson Microelectronics WM8804 S/PDIF transceiver SPI (SND_SOC_WM8804_SPI) [N/m/y] n Wolfson Microelectronics WM8903 CODEC (SND_SOC_WM8903) [N/m/y] n Wolfson Microelectronics WM8962 CODEC (SND_SOC_WM8962) [N/m/y] n Wolfson Microelectronics WM8978 codec (SND_SOC_WM8978) [N/m/y] n Texas Instruments TPA6130A2 headphone amplifier (SND_SOC_TPA6130A2) [N/m/y] n ASoC Simple sound card support (SND_SIMPLE_CARD) [Y/n/m/?] y * * CPU selection * RK3126/8 (CPU_RK312X) [Y/n] (NEW) n RK3036 (CPU_RK3036) [Y/n] (NEW) n RK3066/8 (CPU_RK30XX) [Y/n] (NEW) n RK3188 (CPU_RK3188) [Y/n] (NEW) n RK3288 (CPU_RK3288) [Y/n] (NEW) y RK3228/9 (CPU_RK322X) [Y/n] (NEW) n RV1107/8 (CPU_RV110X) [Y/n] (NEW) n * * NVMEM Support * NVMEM Support (NVMEM) [Y/n/m/?] y Rockchip eFuse Support (ROCKCHIP_EFUSE) [Y/n/m/?] y Rockchip OTP Support (ROCKCHIP_OTP) [N/m/y/?] (NEW) n * * Cryptographic API * Cryptographic API (CRYPTO) [Y/?] y * * Crypto core or helper * RSA algorithm (CRYPTO_RSA) [N/m/y/?] n Cryptographic algorithm manager (CRYPTO_MANAGER) [Y/?] y Userspace cryptographic algorithm configuration (CRYPTO_USER) [N/m/y/?] n Disable run-time self tests (CRYPTO_MANAGER_DISABLE_TESTS) [Y/n/?] y GF(2^128) multiplication functions (CRYPTO_GF128MUL) [Y/?] y Null algorithms (CRYPTO_NULL) [Y/?] y Parallel crypto engine (CRYPTO_PCRYPT) [N/m/y/?] n Software async crypto daemon (CRYPTO_CRYPTD) [N/m/y/?] n Software async multi-buffer crypto daemon (CRYPTO_MCRYPTD) [N/m/y/?] n Authenc support (CRYPTO_AUTHENC) [Y/?] y Testing module (CRYPTO_TEST) [N/m/?] n * * Authenticated Encryption with Associated Data * CCM support (CRYPTO_CCM) [Y/?] y GCM/GMAC support (CRYPTO_GCM) [Y/?] y ChaCha20-Poly1305 AEAD support (CRYPTO_CHACHA20POLY1305) [N/m/y/?] n Sequence Number IV Generator (CRYPTO_SEQIV) [Y/?] y Encrypted Chain IV Generator (CRYPTO_ECHAINIV) [M/n/y/?] m * * Block modes * CBC support (CRYPTO_CBC) [Y/?] y HEH support (CRYPTO_HEH) [N/m/y/?] n CTR support (CRYPTO_CTR) [Y/?] y CTS support (CRYPTO_CTS) [N/m/y/?] n ECB support (CRYPTO_ECB) [Y/?] y LRW support (CRYPTO_LRW) [N/m/y/?] n PCBC support (CRYPTO_PCBC) [N/m/y/?] n XTS support (CRYPTO_XTS) [N/m/y/?] n Key wrapping support (CRYPTO_KEYWRAP) [N/m/y/?] n * * Hash modes * CMAC support (CRYPTO_CMAC) [Y/?] y HMAC support (CRYPTO_HMAC) [Y/?] y XCBC support (CRYPTO_XCBC) [N/m/y/?] n VMAC support (CRYPTO_VMAC) [N/m/y/?] n * * Digest * CRC32c CRC algorithm (CRYPTO_CRC32C) [Y/?] y CRC32 CRC algorithm (CRYPTO_CRC32) [N/m/y/?] n CRCT10DIF algorithm (CRYPTO_CRCT10DIF) [Y/?] y GHASH digest algorithm (CRYPTO_GHASH) [Y/?] y Poly1305 authenticator algorithm (CRYPTO_POLY1305) [N/m/y/?] n MD4 digest algorithm (CRYPTO_MD4) [Y/m/?] y MD5 digest algorithm (CRYPTO_MD5) [Y/?] y Michael MIC keyed digest algorithm (CRYPTO_MICHAEL_MIC) [Y/?] y RIPEMD-128 digest algorithm (CRYPTO_RMD128) [N/m/y/?] n RIPEMD-160 digest algorithm (CRYPTO_RMD160) [N/m/y/?] n RIPEMD-256 digest algorithm (CRYPTO_RMD256) [N/m/y/?] n RIPEMD-320 digest algorithm (CRYPTO_RMD320) [N/m/y/?] n SHA1 digest algorithm (CRYPTO_SHA1) [Y/?] y SHA224 and SHA256 digest algorithm (CRYPTO_SHA256) [Y/?] y SHA384 and SHA512 digest algorithms (CRYPTO_SHA512) [Y/n/m/?] y Tiger digest algorithms (CRYPTO_TGR192) [N/m/y/?] n Whirlpool digest algorithms (CRYPTO_WP512) [N/m/y/?] n * * Ciphers * AES cipher algorithms (CRYPTO_AES) [Y/?] y Anubis cipher algorithm (CRYPTO_ANUBIS) [N/m/y/?] n ARC4 cipher algorithm (CRYPTO_ARC4) [Y/?] y Blowfish cipher algorithm (CRYPTO_BLOWFISH) [N/m/y/?] n Camellia cipher algorithms (CRYPTO_CAMELLIA) [N/m/y/?] n CAST5 (CAST-128) cipher algorithm (CRYPTO_CAST5) [N/m/y/?] n CAST6 (CAST-256) cipher algorithm (CRYPTO_CAST6) [N/m/y/?] n DES and Triple DES EDE cipher algorithms (CRYPTO_DES) [Y/?] y FCrypt cipher algorithm (CRYPTO_FCRYPT) [N/m/y/?] n Khazad cipher algorithm (CRYPTO_KHAZAD) [N/m/y/?] n Salsa20 stream cipher algorithm (CRYPTO_SALSA20) [N/m/y/?] n ChaCha20 cipher algorithm (CRYPTO_CHACHA20) [N/m/y/?] n SEED cipher algorithm (CRYPTO_SEED) [N/m/y/?] n Serpent cipher algorithm (CRYPTO_SERPENT) [N/m/y/?] n Speck cipher algorithm (CRYPTO_SPECK) [N/m/y/?] (NEW) n TEA, XTEA and XETA cipher algorithms (CRYPTO_TEA) [N/m/y/?] n Twofish cipher algorithm (CRYPTO_TWOFISH) [N/m/y/?] n * * Compression * Deflate compression algorithm (CRYPTO_DEFLATE) [Y/?] y Zlib compression algorithm (CRYPTO_ZLIB) [N/m/y/?] n LZO compression algorithm (CRYPTO_LZO) [N/m/y/?] n 842 compression algorithm (CRYPTO_842) [N/m/y/?] n LZ4 compression algorithm (CRYPTO_LZ4) [M/n/y/?] m LZ4HC compression algorithm (CRYPTO_LZ4HC) [N/m/y/?] n * * Random Number Generation * Pseudo Random Number Generation for Cryptographic modules (CRYPTO_ANSI_CPRNG) [N/m/y/?] n * * NIST SP800-90A DRBG * NIST SP800-90A DRBG (CRYPTO_DRBG_MENU) [Y/?] y Enable Hash DRBG (CRYPTO_DRBG_HASH) [N/y/?] n Enable CTR DRBG (CRYPTO_DRBG_CTR) [N/y/?] n Jitterentropy Non-Deterministic Random Number Generator (CRYPTO_JITTERENTROPY) [Y/?] y User-space interface for hash algorithms (CRYPTO_USER_API_HASH) [Y/n/m/?] y User-space interface for symmetric key cipher algorithms (CRYPTO_USER_API_SKCIPHER) [Y/n/m/?] y User-space interface for random number generator algorithms (CRYPTO_USER_API_RNG) [N/m/y/?] n User-space interface for AEAD cipher algorithms (CRYPTO_USER_API_AEAD) [N/m/y/?] n * * Hardware crypto devices * Hardware crypto devices (CRYPTO_HW) [Y/n/?] y * * Asymmetric (public-key cryptographic) key type * Asymmetric (public-key cryptographic) key type (ASYMMETRIC_KEY_TYPE) [Y/n/m/?] y Asymmetric public-key crypto algorithm subtype (ASYMMETRIC_PUBLIC_KEY_SUBTYPE) [Y/n/m/?] y RSA public-key algorithm (PUBLIC_KEY_ALGO_RSA) [Y/?] y X.509 certificate parser (X509_CERTIFICATE_PARSER) [Y/n/m/?] y PKCS#7 message parser (PKCS7_MESSAGE_PARSER) [Y/n/m/?] y PKCS#7 testing key type (PKCS7_TEST_KEY) [N/m/y/?] n Support for PE file signature verification (SIGNED_PE_FILE_VERIFICATION) [N/y/?] n * * Certificates for signature checking * Provide system-wide ring of trusted keys (SYSTEM_TRUSTED_KEYRING) [Y/n/?] y Additional X.509 keys for default system keyring (SYSTEM_TRUSTED_KEYS) [] * * ARM Accelerated Cryptographic Algorithms * ARM Accelerated Cryptographic Algorithms (ARM_CRYPTO) [N/y/?] n # # configuration written to .config # HOSTCC scripts/kconfig/mconf.o HOSTCC scripts/kconfig/lxdialog/checklist.o HOSTCC scripts/kconfig/lxdialog/util.o HOSTCC scripts/kconfig/lxdialog/inputbox.o HOSTCC scripts/kconfig/lxdialog/textbox.o HOSTCC scripts/kconfig/lxdialog/yesno.o HOSTCC scripts/kconfig/lxdialog/menubox.o HOSTLD scripts/kconfig/mconf scripts/kconfig/mconf Kconfigdefault-config might also need some adjustments...
-
Shame on me, I completely missed that we provide legacy kernels for A64 boards and overseen that @stretto uses a legacy image...
Maybe read through this one:
https://forum.pine64.org/showthread.php?tid=2309
Could therefore be a starting point...
-
https://github.com/armbian/sunxi-DT-overlays/blob/master/sun50i-h5/sun50i-h5-analog-codec.dtsfrom: https://github.com/armbian/sunxi-DT-overlays/tree/master/sun50i-h5might be a starting pointEdit: And probably this one too:
SBC choice
in Off-topic
Posted
so better don't use the built in wifi from the nanopi duo..
As soon as it comes to control drones I suggest that you do this independent from your hacker tool.. Guess what happens if your SoC is busy from penetrating a network while you need to control your drone? 
For flight control I would stick with the 2.4GHz stuff made for drones.. First, it works well over long range (or at least at the specified range) and second the overhead for control commands is a way smaller than with normal wifi.
If this needs to be done on the same SoC, it might be worth to look for the small beagle bones (pocket or so) which are RT capable and some project for drone projects are available in opensource (but it is a single core SoC and probably not that powerful for the wifi penetrating stuff you want to achieve)