martinayotte

Ok, guys ! I found my hardware issue : I've been caught myself with an SDCard that becames crappy ! For the xradio issue, I don't know if it was also related, but I've created image with Zador stuff, although I had to tweak a bit the DT, and it is now working fine. @Zador, the tweak needed is related to the fact that PL7 was already defined in PiOne, but due was slipped into pio instead of r_pio (same issue found few weeks ago for PiPC https://github.com/igorpecovnik/lib/commit/31c3133cf65af66197b0e78f92eae835615a90b1 ) I will commit this fix in few minutes along some removal in PiZero since we can reuse the PL7 from PiOne, simply by using same names. EDIT : here is the first fix : https://github.com/igorpecovnik/lib/commit/5fff38add9873b50bc71d540573e4294bc97c10d, and here the redundancy cleanup : https://github.com/igorpecovnik/lib/commit/fdaadb42d7587371a7cb7f1184ade5915cd77924#diff-ef59beeea2dd85451fb9bf2905fb7ebf and https://github.com/igorpecovnik/lib/commit/369d3928e7154ac12c34f0e2bc4ce0e24636cb4e#diff-ef59beeea2dd85451fb9bf2905fb7ebf

@dgp, yes, I was trying to integrate xradio in armbian build process, it was the default configs. But since zador is faster than me, I think my effort are now useless. @zador, thanks for committing those changes, I will gave it a try when I get chance. (especially that this morning, my PiZero didn't even boot at all, I hope it doesn't end up to be hardware issue)

Hi dgp, Here is the relevant fragment of the log : ... and here is the /proc/interrupts

@dpg, I've tried to integrate your xradio work into my branch, it compiled properly. Using your sun8i-h2-orangepi-zero.dts, it was hanging on the CPU throotling, I don't know why. So, I decided to merge only xradio stuff into plain copy of sun8i-h3-orangepi-one.dts. No more hand, but a flood of mmc error when network is started, such as : Dec 28 17:04:12 localhost kernel: [ 40.171288] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !! Dec 28 17:04:12 localhost kernel: [ 40.177230] sunxi-mmc 1c10000.mmc: data error, sending stop command Dec 28 17:04:12 localhost kernel: [ 40.183531] sunxi-mmc 1c10000.mmc: send stop command failed Dec 28 17:04:12 localhost kernel: [ 40.189150] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !! Dec 28 17:04:12 localhost kernel: [ 40.195093] sunxi-mmc 1c10000.mmc: data error, sending stop command Dec 28 17:04:12 localhost kernel: [ 40.201387] sunxi-mmc 1c10000.mmc: send stop command failed Dec 28 17:04:12 localhost kernel: [ 40.206982] xradio_wlan mmc1:0001:1: Failed to read control register. Looking more at this big syslog, I could see that it has actually got it IP from DCHP, but it is a bit after that it start flooding. Do you have any ideas why I'm unable to make it working ?

"Raspbian instructions" ? How Raspbian can support AllWinner XR819 chip ?

Is it the keyboard or the card reader that produce such crash ? Because it would be sad to disable USB in U-Boot, since it could me legitimate to have a USB boot device.

I will probably give it a try too, because lot of things changed/committed since last time I've tried few weeks ago ...

I would not say alive, but rather "artificial keep-alive" Bullet links 55/56/57 clearly says that Debian/Ubuntu/OpenSuse thrown the towel about OO since 2012.

As Zador said, last OpenOffice release was 5 years ago, ALL distros shifted to LibreOffice since then ... From https://en.wikipedia.org/wiki/OpenOffice.org EDIT : Here is a piece of the History :

Effectively :

Maybe you should look at LibreOffice

Mine is warm too, no excessive heat present ...

Yes, I think it is actually an EEPROM, but it is not sure the write procedure is well known or even implemented in current mainline kernel. If you really need some EEPROM for your own purposes, the PiZero has an SPIFlash on board, and for other boards, some I2C EEPROM or SPIFlash can be easily added externally.

There is this guide : http://linux-sunxi.org/Fex_Guide

What do you mean ? Do you wish to send something from your C or Python application to this serial output ? Or you wish to see the debug output from the kernel without using a USB-Serial dongle ? For the first case, simply use normal open()/read()/write()/close() APIs, for Python, you need to install python-serial. For the second case, no need to talk to serial, simply look at dmesg and/or /var/log/syslog.

I've done the quick test on PiZero : attached dupont jumper as loopback on miso/mosi, loaded my usual spidev-overlay.dtbo, and ran ./spidev-test with success.

if you do "cat /proc/cmdline", you will probably see that serial debug is attached as /dev/ttyS0.

If you are talking about this youtube https://m.youtube.com/watch?v=MzxLYGWQddA, the guy didn't even investigate ... I've the I2C working, and for SPI I will probably need to tweak DT, since I'm working exclusively with Mainline. (So, I can't provide recipe for FEX, since I don't use Legacy)

I've sent the following email to Pantelis Antoniou : This is because I feel that new development needs to occur to fill some current gaps : - new clocks not registered dynamically properly. - new alias not registered dynamically properly. My current use-case is adding new UARTs using sc16is7xx, I got it working, but only by defining new clocks in the main DTB, it wasn't working if defined into the DT Overlay.

Good ! Pinout was also described in the schematic.

On A20, the eFuse can be read since the EEPROM is defined in the DTS. But it doesn't seems to be defined in the H3. Some details for eFuse can be found here : http://linux-sunxi.org/SID_Register_Guide EDIT : I've added the following on H3 OPiPC DT and got it working : sid: eeprom@01c14200 { compatible = "allwinner,sun7i-a20-sid"; reg = <0x01c14200 0x200>; }; To read content : hexdump -C /sys/devices/platform/soc/1c14200.eeprom/sunxi-sid0/nvmem

Of course ! you need to make sure they are properly set in Legacy Fex or Mainline DT as plain GPIO and remove the UART2 definition if present. Same can be done with I2C and/or SPI if you don't need them.

Yes, the sunxi_gpio_init() should be called first. Then, setting pinmode is done by sunxi_gpio_set_cfgpin(). sunxi_gpio_output() is the equivalent to digitalWrite(). The code in above link is a bit hard to understand without the schematic of the project. It seems that it is talking to an external shift register with clock/data/latch, probably an 74HC595. The OT_DIRECT_POS/OT_DIRECT_NEG seems to be equivalent of SUNXI_GPIO_OUTPUT/SUNXI_GPIO_INPUT. Personally, I will re-write this code from scratch instead of trying to port it as is.

In the link I provided, although it is a Python library, but under the hood, it still written in C. So, for GPIO, you can use pyA20/gpio/gpio_lib.h and pyA20/gpio/gpio_lib.c directly. For blink example of PiZero RED LED on PA17, here are the methods needed : sunxi_gpio_init(); sunxi_gpio_set_cfgpin(SUNXI_GPA(17), SUNXI_GPIO_OUTPUT); while(1) { sunxi_gpio_output(SUNXI_GPA(17), 1); sleep(1); sunxi_gpio_output(SUNXI_GPA(17), 0); sleep(1); }

For all my Oranges, I'm using https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 Be aware that on PiZero, the STATUS_LED is not on PA15 but on PA17, therefore you will need to tweak mapping.h to change that.