martinayotte

With the SDIO changes for better strength done by @TonyMac32, it seems that the laggyness is gone !

As per @TonyMac32 suggestion, I changed sdmmc pins to get higher strength, and committed that yesterday, it seems to fix the issue.
Tony had also the HDMI working last night, but he didn't committed that yet, too tired to avoid going to sleep ...

I've received my OrangePi-RK3399 recently ...
Just for trials, before doing any real development, I gave a try with a NanoPC-T4 4.19.y image compiled a month ago, and it worked "as is", even eMMC and WiFi is running fine.
That it is a good starting point !
 
Of course, to be able to boot from SDCard, we need to short the eMMC clock using the test point TP50265 :
 

I've received my OrangePi-RK3399 recently ...
Just for trials, before doing any real development, I gave a try with a NanoPC-T4 4.19.y image compiled a month ago, and it worked "as is", even eMMC and WiFi is running fine.
That it is a good starting point !
 
Of course, to be able to boot from SDCard, we need to short the eMMC clock using the test point TP50265 :
 

When I copy/pase links from AliExpress or eBay, I always shortening them manually to before the first "?" and check if link still relevant ...

When I copy/pase links from AliExpress or eBay, I always shortening them manually to before the first "?" and check if link still relevant ...

When I copy/pase links from AliExpress or eBay, I always shortening them manually to before the first "?" and check if link still relevant ...

Rockpro64 has now overlays framework ...

@zador.blood.stained spend even more time than me on the overlays. I've worked more on the CONFIGFS side for RunTime-UserSpace overlays ...

I've just added the CONFIGFS patch for RunTime/UserSpace overlay loading, since "meson64-dev" is using Mainline, it was simply question of doing a copy of the patch ...
Building image currently, I will test in maybe 15 mins... Then, maybe write a little overlay for UART1 ...
 

What I found by digging Ayufan build script and comparing Rockchip Wiki, is that Ayufan doesn't place the u-boot-itb at sector 0x4000, but at sector 0x200, probably to avoid waste of space ...
I'm about to do final commit in Armbian script, you will then have to simply do a build of the image.
 
My commit will use "flow #2", but maybe the glitch in "flow #1" is maybe related to sector location too ...
 
EDIT : Here is the commit https://github.com/armbian/build/commit/c3e46a5d863ebc4d00d666b3a19eed00e3d0c17d
 
EDIT2 : I've tested the "nand-sata-install" on eMMC, and it is working fine too ...

What I found by digging Ayufan build script and comparing Rockchip Wiki, is that Ayufan doesn't place the u-boot-itb at sector 0x4000, but at sector 0x200, probably to avoid waste of space ...
I'm about to do final commit in Armbian script, you will then have to simply do a build of the image.
 
My commit will use "flow #2", but maybe the glitch in "flow #1" is maybe related to sector location too ...
 
EDIT : Here is the commit https://github.com/armbian/build/commit/c3e46a5d863ebc4d00d666b3a19eed00e3d0c17d
 
EDIT2 : I've tested the "nand-sata-install" on eMMC, and it is working fine too ...

I think I got it working ... But doing it manually, not within Armbian build scripts ...
I will check if I can integrate that into them ...

I think I got it working ... But doing it manually, not within Armbian build scripts ...
I will check if I can integrate that into them ...

I think I got it working ... But doing it manually, not within Armbian build scripts ...
I will check if I can integrate that into them ...

Check this patch initially committed by @zador.blood.stained in NEXT around March 2017, it is maybe worth to do the same in DEV ...
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/spidev-remove-warnings.patch
 

Glad to hear that ...

@chwe I've read your post before souper , I didn't read the whole story ...
During souper, watching TV, the same subject comes there in the news ...
In summary from Canadian's news, this chinese scientist is braking ethic rules a lot, the reportage says that if he would do what it did in Canada, he could ended-up with 10 years of prison.
I hope those "newly baken childs" won't become "monsters" since "crisp" isn't safe at all !

Just as a PoC, I've burned a recent Armbian OPiPC image on a SDCard, then mounted it, copy the /boot folder from an recent BeagleBoneBlack image on top of existing /boot folder, along with /lib/modules/4.14.79 and kernel from a BeagleBone build I've done using the https://github.com/beagleboard/linux branch. I've copied U-boot sectors from BBB image into by SDCard. I've also remove the /boot/boot.scr from original Armbian since it has precedence over BeagleBone /boot/uEnv.txt. 
I've then inserted in my old BBB, booted it ! It worked !!!
The only thing that didn't work as is, is the USB WiFi that I'm using : with old way /etc/network/interface, it didn't connect to my AP by itself, I had to use "wpa_supplicant" ...
I'm now having an BeagleBian Stretch ...
 
EDIT : I've then use "nand-sata-install", which worked luckily since this old BBB first version has only 2GB eMMC ... But it seems that u-boot is bad, I had to restore the U-boot sectors again, but that didn't work ... I will dig the issue, maybe u-boot geometry doesn't start at byte 8192 ...
 
EDIT2:  I've finally got the eMMC working after I've discovered that even eMMC is only enabled using an overlay named /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo, so I added in my experimental image.

Check the ESP32 Forum, there are plenty of people who use the ethernet interface. There is also some boards that have them out-of-the-box :
https://www.olimex.com/Products/IoT/ESP32/ESP32-EVB/open-source-hardware
 

The service is "armbian-resize-filesystem" ...

Built, installed, and tested ...
sun8i-h3-orangepi-lite.dts-4.18.17

In addition for all we've done previously, I've discovered by comparing with OPiOne DTS, which was already working, that OPiLite didn't have "okay" on both usb@01c1a000 and usb@01c1a400...

The simplest way is to use gpio sysfs ...
echo 20 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio20/direction echo 1 > /sys/class/gpio/gpio20/value  

As I've said earlier, it 20mA per pin ! I've also said that if you sums up many pins, it is up to the quality of the PCB design if it could handle that, for your example 40 pins multiply 20mA, this means that the VCC would need to supply a total 800mA to the SoC, if VCC lines on PCB are not huge enough, this will produce a voltage drop on those lines and maybe the SoC will brownout and reset/crash.