Nick

No problem, assuming dev works about as well as next did yesterday that should be fine for me. I've just spent the day being completely confused as to why things worked perfectly yesterday and now I get a screen full of errors I'm downloading / building dev now so hopefully all will be well

Hello all, I've been struggling to build Armbian for the Orange Pi Pc all day today, it worked fine yesterday then today nothing. I've just been looking through the repo at github and it appears that all of the patches for building sun8i-h3.dtsi etc have been moved to linux-dev does this mean that from now on we need to build the dev kernel not the next kernel for H3 devices?

Ahh ok, if I get stuck again I'll try it in a bit. I'm mostly trying to just get SPI working at the moment, Ethernet would have been a nice bonus. I've not managed to make Armbian compile at all yet today :-( But I've just noticed that 5.06 has come thorough so I might have more luck with that :-)

Thanks for that, I'll try it now. I'm assuming that that doesn't solve the missing dtsi issue though? I'll keep an eye on linux-sunxi, I do read through the chats logs from time to time, they are very interesting. I have this weeks security now to digest first though :-) Edit branch 4.5 doesn't appear to work either CC drivers/net/phy/b53/b53_phy_fixup.o drivers/net/phy/b53/b53_phy_fixup.c: In function ‘b53_phy_fixup’: drivers/net/phy/b53/b53_phy_fixup.c:32:27: error: ‘struct phy_device’ has no member named ‘bus’ struct mii_bus *bus = dev->bus; ^ drivers/net/phy/b53/b53_phy_fixup.c:34:9: error: ‘struct phy_device’ has no member named ‘addr’ if (dev->addr != B53_PSEUDO_PHY) ^ make[4]: *** [drivers/net/phy/b53/b53_phy_fixup.o] Error 1 make[3]: *** [drivers/net/phy/b53] Error 2 make[2]: *** [drivers/net/phy] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 [ error ] ERROR in function compile_kernel [ common.sh:224 ]

I was really happy to see the new patches come in :-) Sadly sun8i-h3.dtsi seems to have disappeared. I don't know if it is missing from the kernel source or if it is added in by Armbian but it's no longer in sources/linux-vanilla/v4.4.5/arch/arm/boot/dts Edit: It does appear to be a kernel issue not an Armbian issue, I've just downloaded the last Linux tarball, extracted the dtsi file and dropped it into armbian/sources which improved things somewhat. However, 0002-ARM-dts-sun8i-Add-Orange-Pi-PC-support.patch still fails. I'll look at that next.

Yes 4.4.5, Zador helped me to get it running on a banana pi m1+ using Linux next and Jessie. I've just checked spidev.c on my build VM and it doesn't contain the lines that you have added, however it appears that they are added via spi-sun4i.c and spi-sun6i.c Here is an example form spi-sun6i.c static const struct of_device_id sun6i_spi_match[] = { { .compatible = "allwinner,sun6i-a31-spi", }, {} }; MODULE_DEVICE_TABLE(of, sun6i_spi_match); I haven't read through the full driver code yet, but I would imagine that they are pulled in at some point and added to the struct.

That's great work, thank you. I'll test them later and hopefully all will be well. I am a little confused as to why those lines aren't already in the driver though? I have successful run the spidev driver on the A20, which uses the sun4i-a10 model without having to patch spidev.

No I haven't I did a quick forum search but I (stupidly) ignored that one as my brain saw orange pi one and discounted it. I'll have a read through tonight and see if I can pick up any nuggets. Would you prefer me to contribute anything I find to that thread or carry on with this one?

This maybe something that just isn't available yet, but if I can help with the development I am happy to. I have created the following patches as a starting point but they don't yet work. Looking at the source code for the spidev module and comparing it to the H3 datasheet, it would appear that the H3 uses the sun6i spi register addresses. Though the datasheet lists the RX and TX buffers as 64 bytes whereas the sun6i spidev driver implements 128byte buffers. I'm assuming that this wont be a problem at least for testing as long as I don't try and transfer or receive more than 64 bytes. As you can see from the dtsi patch, I have updated the module memory location and the IRQ & DMA channels. The clock gating appears to already be configured in the H3 dtsi file so hopefully that is correct. --- /arch/arm/boot/dts/sun8i-h3.dtsi 2016-03-14 19:04:16.977158383 +0000 +++ ./sun8i-h3.dtsi 2016-03-14 21:49:55.806634593 +0000 @@ -591,5 +591,37 @@ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>; }; + spi0_clk: clk@01c200a0 { + #clock-cells = <0>; + compatible = "allwinner,sun4i-a10-mod0-clk"; + reg = <0x01c200a0 0x4>; + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>; + clock-output-names = "spi0"; + }; + spi0: spi@01c68000 { + compatible = "allwinner,sun6i-a31-spi"; + reg = <0x01c68000 0x1000>; + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ahb_gates 20>, <&spi0_clk>; + clock-names = "ahb", "mod"; + dmas = <&dma SUN4I_DMA_DEDICATED 23>, + <&dma SUN4I_DMA_DEDICATED 23>; + dma-names = "rx", "tx"; + status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; + }; + spi0_pins_a: spi0@0 { + allwinner,pins = "PC2", "PC0", "PC1"; + allwinner,function = "spi0"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; + }; + spi0_cs0_pins_a: spi0_cs0@0 { + allwinner,pins = "PC3"; + allwinner,function = "spi0"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; + }; }; }; --- /arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts 2016-03-14 19:04:17.013140384 +0000 +++ ./sun8i-h3-orangepi-pc.dts 2016-03-14 21:50:23.646635423 +0000 @@ -104,3 +104,21 @@ /* USB VBUS is always on */ status = "okay"; }; + +&spi0 { + pinctrl-names = "default"; + pinctrl-0 = <&spi0_pins_a>, + <&spi0_cs0_pins_a>; + status = "okay"; + spi0_0 { + #address-cells = <1>; + #size-cells = <0>; + + compatible = "spidev"; + + reg = <0>; + spi-max-frequency = <500000>; + }; +}; + + At the moment the only feedback that I get is no /dev/spi* is there anyway of getting some debugging info from the driver printk's maybe?

Sorted.

Hi tkaiser, I did read the GitHub link last night, it was very interesting. I think one of the advantages that the Raspberry Pi brand has is that not only are the foundation pushing the hardware forward but that they also have a fairly decent grasp (at least when compared to the hundreds of piClone manufacturers) of the software and inner workings of the SoC. That last point is one of the things that I love about the Armbian project / community, you guys really do know your stuff and push everything to be the best / highest quality that it can be. It's just a shame that Allwinner and often the board mfrs let you down repeatedly. I've learnt so much in a very short space of time about boot processes, dtb files and alot more from just reading this forum and asking a few questions, that's before I even consider how helpful it is to have a stable OS to work with. I'm looking forward to learning even more and having alot of fun working with these boards which I don't think I would be having if I were trying to work with the stock images from the Mfrs!

For some reason the reboot command doesn't appear to reboot the H3. Is this because it doesn't have a PMIC in the same way that the A20's do or is it just a case of the correct assembly instruction not being called?

Ok, I think I may have stumbled on the solution by accident last night, no surprises in that it looks like the cause was me being an idiot as usual... I use ctrl-r and bash's history alot and it would appear that sometimes I've been trying to write the .raw file to /dev/sdb1 instead of /dev/sdb. As expected the Pi fails to boot, my Kubuntu desktop can't mount the fs etc. etc. The interesting thing is that testdisk appears to be able to fix this up! I need to confirm all of this with a few more tests but if that's the case then not only problem solved, but also how awesome is testdisk!!

I did a little more reading around some of the sources and you are right in that no one seems to have hit 97 / 100, they do also mention that internal sensors weren't used for exactly the reasons you have mentioned. To be fair, while I agree with your comment that trying to measure to 0.1°C in that type of situation is questionable at least, if that is just a screen shot from the camera then surely it is more dubious to go editing out the .3?? They did at least round it up for the headline, though I imagine that was more for creating hysteria than scientific interpretation This article https://www.reddit.com/r/raspberry_pi/comments/48i47b/planning_to_put_your_pi_3_in_a_case_make_sure/ mentions potential throttling code issues, which reminded me of the early H3 troubles but again I don't know enough to comment with any authority and I think the author may also be the same person responsible for the other article as well. Which may or may not be suspicious.

Tonight is the first time that I've used it, though I'm sure it wont be the last I tried as well and didn't get anywhere, but equally I don't know what I'm doing so I thought I would ask. It's a shame, but I can cope with using a USB adapter now that I have bought one that actually works

Not sure how much truth there is in this as I haven't had time to follow up on the sources, but interesting if true! http://www.open-electronics.org/the-raspberry-pi-3-gets-seriously-hot-clocking-up-to-100-c/

Useful to a point, it would be nice if it at least said "Hey I'm here, I'm not bricked, just waiting to be told what to do" Great to hear that you have FEL boot running, that's on my list of things to try, I was just waiting for Zador to get back to me with some info in one of my other threads. Have Montjoe's ethernet patches been included yet or are you still using a USB->Ethernet dongle?

Ok, so it appears that I may have panicked over nothing, can someone that knows about the boot process confirm that you really don't get any output at all if there isn't a valid SD card inserted?

I have an Orange Pi PC that I bought from eBay a while ago and it works absolutely fine, has done for a month or so now. I have just bought 5 more from Xunlong's Aliexpress store, they arrived very quickly, however they don't appear to boot... Power rails are fine, 24MHz clock is fine, reset line is fine, fel mode registers with my PC fine, however no UART output, no apparent attempt to boot from the SD card. If boot it with the SD card in, I get absolutely nothing, if I boot it without the SD card, it gets into FEL mode and I can talk to it with sunxi-fel nick@nick-desktop:~/sunxi-tools$ sudo ./sunxi-fel ver AWUSBFEX soc=00001680(H3) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000 I don't know if that is a recent and or buggy version? sudo ./sunxi-fel -v uboot ../u-boot-sunxi-with-spl.bin write 0x42000000 Writes Uboot to the SoC and all of a sudden it appears to try and boot, it fails due to missing kernel, boot file and so on, but at least I'm getting something on the UART now. My gut feeling is that the SoC is detecting the SD card (it only goes into FEL mode if the card isn't there) but that for some reason it's not even attempting to boot from it. I'm guessing that there is a setting that hasn't been configured properly at the factory or that the BROM is buggy but I don't know enough to even start debugging at that level.

For me, modifying configuration.sh to point at the correct defconfig file in uboot did the trick. orangepih3)#enabled #description H3 quad core (Orange Pi PC/One/2/Lite) #build 3wip LINUXFAMILY="sun8i" BOOTCONFIG="orangepi_pc_defconfig" MODULES="8189es #gpio_sunxi #w1-sunxi #w1-gpio #w1-therm #gc2035" MODULES_NEXT="" CPUMIN="480000" CPUMAX="1296000" GOVERNOR="interactive" Sadly I don't think this will solve Schwemmlandebene's problem :-(

New Line 37: make $CTHREADS $BOOTCONFIG CROSS_COMPILE=arm-linux-gnueabihf- Output for Armbian: [ o.k. ] Compiling uboot. Please wait. [ 2016.03-rc2 ] HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf *** *** Can't find default configuration "arch/../configs/orangepi_h3_defconfig"! *** make[1]: *** [orangepi_h3_defconfig] Error 1 make: *** [orangepi_h3_defconfig] Error 2 scripts/kconfig/conf --silentoldconfig Kconfig *** *** Configuration file ".config" not found! *** *** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig"). *** make[2]: *** [silentoldconfig] Error 1 make[1]: *** [silentoldconfig] Error 2 make: *** No rule to make target `include/config/auto.conf', needed by `include/config/uboot.release'. Stop. [ o.k. ] Target directory [ /home/nick/hg/p158-linux-images/output/debs/ ] [ o.k. ] Building deb [ linux-u-boot-next-orangepih3_5.05_armhf.deb ] [ error ] ERROR in function compile_uboot [ common.sh:146 ] [ error ] Building u-boot failed, check configuration [ o.k. ] Process terminated mv: cannot move ‘output/images/Armbian_5.05_Bananapipro_Debian_jessie_4.4.5.raw’ to ‘./Armbian_5.05_Bananapipro_Debian_jessie_4.4.5.raw’: Permission denied

Interesting that there are 2 different issues, sadly I don't know enough about uboot or the build process to look at this at least not tonight. I have just tried building BPI Pro and that seems to have built fine so it would appear to be board / SoC specific. Hopefully one of the devs will be along soon to help out :-)

Update, building Uboot just failed again after downloading all sources from scratch

I had Jessie Next fail while building Uboot just now, but that was for orangepih3. I'm in the process of cleaning out the directory tree and starting again from scratch in case there is anything left over from the BPI M1+ builds that I have been doing recently Already up-to-date. M debootstrap.sh Already on 'master' Your branch is up-to-date with 'origin/master'. [ o.k. ] Command line: setting BUILD_DESKTOP to [ no ] [ o.k. ] Command line: setting RELEASE to [ jessie ] [ o.k. ] Command line: setting BRANCH to [ next ] [ o.k. ] Command line: setting PROGRESS_DISPLAY to [ plain ] [ o.k. ] Command line: setting PROGESS_LOG_TO_FILE to [ yes ] [ o.k. ] Command line: setting BOARD to [ orangepih3 ] [ o.k. ] Command line: setting PROGRESS_DISPLAY to [ plain ] [ o.k. ] Command line: setting COMPRESS_OUTPUTIMAGE to [ no ] [ o.k. ] Command line: setting DEST_LANG to [ en_GB.UTF-8 ] [ o.k. ] Command line: setting EXTENDED_DEBOOTSTRAP to [ yes ] [ o.k. ] Command line: setting APT_PROXY_ADDR to [ nas-1.local:3142 ] [ o.k. ] Preparing [ host ] [ o.k. ] Using user configuration override [ userpatches/lib.config ] [ o.k. ] Starting Armbian build script [ @host ] [ o.k. ] Building [ Armbian 5.05 Orangepih3 Debian jessie next ] [ o.k. ] Syncing clock [ host ] [ o.k. ] source downloading [ @host ] [ o.k. ] ... creating a shallow clone [ u-boot v2016.03-rc2 ] Cloning into '/home/nick/hg/p158-linux-images/sources/u-boot/v2016.03-rc2'... remote: Counting objects: 12306, done. remote: Compressing objects: 100% (11140/11140), done. remote: Total 12306 (delta 2197), reused 4257 (delta 941) Receiving objects: 100% (12306/12306), 15.53 MiB | 5.00 KiB/s, done. Resolving deltas: 100% (2197/2197), done. Checking connectivity... done. [ o.k. ] ... updating [ linux-vanilla ] [ o.k. ] ... updating [ sunxi-tools ] [ o.k. ] ... updating [ rt8192cu ] [ o.k. ] ... updating [ sunxi-display-changer ] [ o.k. ] ... updating [ mt7601 ] [ o.k. ] Compiling sunxi tools [ @host & target ] [ o.k. ] Cleaning [ /home/nick/hg/p158-linux-images/sources/u-boot/v2016.03-rc2 ] [ o.k. ] Cleaning [ /home/nick/hg/p158-linux-images/sources/linux-vanilla/v4.4.5 ] [ o.k. ] Cleaning [ /home/nick/hg/p158-linux-images/output/debs ] [ o.k. ] Started patching process for [ kernel sunxi-next 4.4.5 ] [ o.k. ] Looking for user patches in [ userpatches/kernel/sunxi-next ] [ o.k. ] ... 0010-bananapi_m1_plus_dts.patch [ succeeded ] [ o.k. ] ... 0012-bananapi_r1_dts.patch [ succeeded ] [ o.k. ] ... 0013-lamobo_r1_dts.patch [ succeeded ] [ o.k. ] ... 14-bpi-spi.patch [ succeeded ] [ o.k. ] ... 15-bpi-disable-uart.patch [ succeeded ] [ o.k. ] ... OrangePI-01-h3-2733b9fa0ad18f1deb240d8d1ea92957d7f2270d.patch [ succeeded ] [ o.k. ] ... OrangePI-02-h3-3bff045590a3dd40341398b4ba15859fb9f7001e.patch [ succeeded ] [ o.k. ] ... OrangePI-03-h3-08c956b56c98e500ac79ac4957025c2c05460fad.patch [ succeeded ] [ o.k. ] ... OrangePI-04-h3-e49065f413b616b6c2fa794e20510f821361f08d.patch [ succeeded ] [ o.k. ] ... OrangePI-05-h3-1832b6cde1381ac783d5921c2c916bf1423aa60f.patch [ succeeded ] [ o.k. ] ... OrangePI-06-h3-4e776aacfc9f723783806246cea618f413db55e3.patch [ succeeded ] [ o.k. ] ... OrangePI-07-h3-c54e26726f75e388d39aa80e604774b0ea6d5a2f.patch [ succeeded ] [ o.k. ] ... OrangePI-08-h3-fe78c12c1a4f4f271d0cc8b2f5eb341c95f40c66.patch [ succeeded ] [ o.k. ] ... OrangePI-09-h3-cca1f932be385e576d975836895188fa55c52945.patch [ succeeded ] [ o.k. ] ... OrangePI-10-h3-3bde21d14f6521dc237a952ae2f6d3dea982f786.patch [ succeeded ] [ o.k. ] ... OrangePI-11-h3-303ed9315574a4764eba097b5c2fe00cd5a90e8f.patch [ succeeded ] [ o.k. ] ... OrangePI-12-h3-5b030647d83ab4680901d42cb115d9dc95b22440.patch [ succeeded ] [ o.k. ] ... OrangePI-13-h3-f31f74a2c3070ba35e9eea03f7afda86d3e715ee.patch [ succeeded ] [ o.k. ] ... OrangePI-14-h3-42bbc4bb30ac2e1abaf34357d6e122d8881d6d17.patch [ succeeded ] [ o.k. ] ... axp20x-sysfs-interface.patch [ succeeded ] [ o.k. ] ... bananapi-codec.patch [ succeeded ] [ o.k. ] ... bananapi-r1-switch-driver.patch [ succeeded ] [ o.k. ] ... bananapipro-wifi-codec-led-fix.patch [ succeeded ] [ o.k. ] ... brcmfmac_ap_banana_ct.patch [ succeeded ] [ o.k. ] ... cubieboard_enable_mmc0_trigger_to_green_LED.patch [ succeeded ] [ o.k. ] ... cubietruck_enable_mmc0_trigger_to_green_LED.patch [ succeeded ] [ o.k. ] ... headers-packing.patch [ succeeded ] [ o.k. ] ... orangepi-mini-codec.patch [ succeeded ] [ o.k. ] ... packaging-next.patch [ succeeded ] [ o.k. ] ... pcDuino3-nano-codec.patch [ succeeded ] [ o.k. ] ... spi_allow_transfer_larger.patch [ succeeded ] [ o.k. ] ... sunxi-audio-capture-allin1.patch [ succeeded ] [ o.k. ] ... support_for_second_mmc_cubieboard2.patch [ succeeded ] [ o.k. ] Started patching process for [ u-boot u-boot-next 2016.03-rc2 ] [ o.k. ] Looking for user patches in [ userpatches/u-boot/u-boot-next ] [ o.k. ] ... add-awsom-uboot.patch [ succeeded ] [ o.k. ] ... add-cubieboard4.patch [ succeeded ] [ warn ] ... bananapi-enable-ldo4.patch [ failed ] [ o.k. ] ... u-boot-02-support-cheap-mmc.patch [ succeeded ] [ o.k. ] Compiling uboot. Please wait. [ 2016.03-rc2 ] scripts/kconfig/conf --silentoldconfig Kconfig *** *** Configuration file ".config" not found! *** *** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig"). *** make[2]: *** [silentoldconfig] Error 1 make[1]: *** [silentoldconfig] Error 2 make: *** No rule to make target `include/config/auto.conf', needed by `include/config/uboot.release'. Stop. [ o.k. ] Target directory [ /home/nick/hg/p158-linux-images/output/debs/ ] [ o.k. ] Building deb [ linux-u-boot-next-orangepih3_5.05_armhf.deb ] [ error ] ERROR in function compile_uboot [ common.sh:146 ] [ error ] Building u-boot failed, check configuration [ o.k. ] Process terminated

Hi zador.blood.stained, Do you have a link to the NFS boot documentation by any chance? I saw the link to the commit logs, but nothing really that pointed me in the write direction. If there is something written down then I'll happily test it tonight.