martinayotte

Lot of learning in perspective, about Armbian u-boot flavor, but also with the above link.
Not an easy task, even for myself, not having done it before ...
 

You should purchase some ...
Personally, I've about 8 of them, some CH34x, some FTDI, some CP2102, some PL2303. So, when I need one, I don't have to unplugged one elsewhere !
They are cheap, between $1 and $2 ...

I'm Kever Yang from Rockchip BSP team, and I'm in charge of open source for Rockchip SoCs, you should able to see my patches to upstream U-Boot and kernel. Thanks very much to @tkaiser for share this thread to me, and I hope I can do some explanation here so that help developers understand what we are doing.
 
The github(https://github.com/rockchip-linux/) is owned by Rockchip,  and repos on github consider to be a 'Linux SDK' of some of Rockchip SoCs(mainly for RK3328, RK3288, RK3399 now), we have a wiki to provide basic document for it(http://opensource.rock-chips.com/), the github is now maintained by one of our product team. We hope this github can be a good reference to developers who interested in Rockchip platform.
 
I have to declare that Rockchip never try to stop community developers to report issue to Rockchip by github or by mail, but it's not correct to close issues without any comments, I'm sorry about what we have done and I promise it would never happen again. For some issues, we may not able to fix it, but people should get a saying if we have to close it. Rockchip always open to community, and, yes, we hope to get advice about github maintain.
 
Here is the information about Rockchip source code:
- Rockchip have only one common BSP maintained by BSP team, including U-Boot, kernel, rkbin(ddr, miniloader, trust), this is used in all Rockchip products and for many SoCs, so it including 4.4 base/LTS patches, upstream backport for some modules, vendor/rockchip solution for some modules because the requirement for production;
- Rockchip product team will test for product SDK release, but usually only for one SoC per SDK, and it will fix at that point before next version SDK. 
- Rockchip kernel is now 4.4, and will update to next LTS;    
  We try to use upstream source code as much as possible for all the modules, you can find this out by compare to our last version kernel 3.10, but still way to go.
- Rockchip kernel is used for Android and Linux OS;
- Github source code is a special 'Linux SDK', not like other 'fixed after release for one SoC' SDK, it keeps update and used for more than one SoCs, you can consider it to be a mirror of Rockchip internal BSP
     * that's why we not able to merge the pull request, we have to review all the source code internally;
     * the github release branch is  not maintained directly by BSP team, so it may not have maintained good enough now, I will sync with the maintainer, we will have better test, and better release flow;
- Rockchip don't have official community version BSP which only have everything from upstream, and won't going to have one in near future;
- Issue report(feature defeat, performance and etc) are always welcome, we want provide a better common kernel.
    We will fix issues really need to fix, people don't want to get a kernel always have the same issue.
- We focus on evb first for new SoCs, and some popular board will add later; this may be one of the conflict with the what community wants.
 
    About the common kernel for community, here is my suggestion:
- Community can chose one kernel version fork from Rockchip as common kernel, now the kernel4.4 already has good support for RK3288/RK3399/RK3328;
- Developing, apply patches for new board support, switch some of module to upstream driver, and so on;
- Upstream the new board support or feature support as much as you can, then rockchip kernel can support it when update to new kernel;
- If some feature/performance issue need to fix recently, community people can contact Rockchip/me, we will try to fix it if we can;
- maybe a mailing list is needed for better communication?

"sudo" is applied only on the left part of ">", right part still under normal user ...
Another way to do it is, but not really elegant :
 
echo "255" | sudo tee -a /sys/class/leds/orangepi\:red\:status/brightness
 
Another way could be :
 
echo "255" | sudo dd of=/sys/class/leds/orangepi\:red\:status/brightness

They are not provided on the GPIO header ...
Grab the schematic from https://forum.armbian.com/applications/core/interface/file/attachment.php?id=2
You will see that the only way to get those PA15/PA16 is to solder tiny wires on proper side of R59 and R132.
 
Ouups ! Schematic link doesn't work, here I'm adding it in attachment.
orangepi-plus-h3-v1_1.pdf

For some usage, doing "cat /sys/kernel/debug/gpio" will reveal if pin is in use by kernel driver.
But for some other usage such as I2C/SPI, you need to inspect Legacy FEX or Mainline DT.
 

The first one ! u-boot AND rootfs from eMMC.
( the second means u-boot only on eMMC and rootfs on SATA/USB )
 

Be aware that when "i2cdetect" scan the bus slowly, it is usually that you don't have any pullups on the bus ...

Incredible !
As I said in many other threads, USB-TTL-Serial USB dongle  as described at http://linux-sunxi.org/UART is a MUST for anyone who plays with any SoC boards !!!
Those are afordable, usually around $0.99 on eBay, you should keep several of the in inventory if you have several SoC boards ...
 

Incredible !
As I said in many other threads, USB-TTL-Serial USB dongle  as described at http://linux-sunxi.org/UART is a MUST for anyone who plays with any SoC boards !!!
Those are afordable, usually around $0.99 on eBay, you should keep several of the in inventory if you have several SoC boards ...
 

Incredible !
As I said in many other threads, USB-TTL-Serial USB dongle  as described at http://linux-sunxi.org/UART is a MUST for anyone who plays with any SoC boards !!!
Those are afordable, usually around $0.99 on eBay, you should keep several of the in inventory if you have several SoC boards ...
 

Almost any USB-TTL-Serial are priced around $0.99 on eBay, it is so cheap that noone should live without some (I've around 8 of then, different models), it is the most easy way to debug any SoC issues, especially when used in headless scenario.
 
 

Ok !
should be :
 

Ok !
should be :
 

I see that you are using /sys/class/gpio to access GPIOs.
But other libraries are using /dev/mem to do a "mmap" directly to SoC registers located at 0x01C20800, which is faster and allows also to access to Pn_PUL0/Pn_PUL1 registers at offset 0x1c and 0x20 respectively.
Maybe you can take a look at this library : https://github.com/duxingkei33/orangepi_PC_gpio_pyH3
 

Earlier in the current thread :
 

Personally, I would test with a separate SDCard, check several pieces of software before touching the SSD.
After been satisfy, then I would do the final ugrade...
 

Yes, for PC, https://github.com/duxingkei33/orangepi_PC_gpio_pyH3
For Zero, there someone who forked it and adjusted the mapping.h for few Zero pins differences, but I can't remember the link.
 
EDIT : I've finally found it for Zero : https://github.com/nvl1109/orangepi_PC_gpio_pyH3
 

I did some work several months ago, simply because I have several Olimex-A20-Micro. The patches were reyling on BBrezillon work, but I simply throw the towel maintaining them, mostly by lack of time and having other priority.
I agree that NAND is fading out, since even Olimex redesign their board to use eMMC, so I don't think it worth the effort...

All unused GPIOs are defaulted as normal GPIO, no needs to tweak DT.
And they can be tested easily using /sys/class/gpio ...
 

P.S. my friend purchased an OPi R1 and I may help him to make it mainlined ;-)

BTW, you have an ampersand missing :
nohup python /home/orangepi/scripts/botones.py > /tmp/botones.log 2>&1 & And you don't have any /tmp/botones.log created ? Strange  ! Add some print() in the python script ...
 
Try also to change the first line from " #!/usr/bin/env python" to " #!/usr/bin/python"

Did you configured the SPI itself in FEX using FEX Guide ?
 
http://linux-sunxi.org/Fex_Guide#spi_configuration
 
 

Along with "overlays=spi-jedec-nor", do you have "param_spinor_spi_bus=0" ?
Did you inspect "dmesg" to see any related errors ?
 

My OPiZeroPlus2-H3 is now updated to 4.13 !
I will commit those changes too ...