martinayotte

Hi Zador, No worries, I've used the 4.8 version I've already done in sunxi-dev and it works, so I will submit PR in few minutes. The only thing that would be appreciated is to let authors know when such things are disactivated instead of leaving them figure out several days later It is still doesn't work for me as a workaround. But it is working is the SRAM Stack patch is unpatched. So, I've prepared the unpatch_sun50i_sram_stack_issue.patch for my next PR. Yes, thanks for that fix. No more need to manually type the boot.cmd in u-boot shell ... EDIT : PR done ! (and since Igor gave me github rights, PR merged ...) I've also added a /proc/cpuinfo patch to allow compatibility of RPi.GPIO-PineA64 against the older Longsleep kernel, by adding Processor/Hardware entries.

Hi Zador, Thanks for the hints, I've recompiled with having this patch Reverted : https://github.com/linux-sunxi/u-boot-sunxi/commit/1a83fb4a17d959d7b037999ab7ed7e62429abe34 U-Boot is now comes up, but with errors about ethernet, and fallback to prompt. It seems that it doesn't look at the boot.scr. It complains about "Unrecognized filesystem" but when prompt come up, I can easily do "ls mmc 0 /boot" ont the Ext4. It is like it doesn't know Ext4 until getting to the prompt. So, I've copy/paste boot.cmd commands, and it boot succesfully, but it is a tedious task on every reboot Here are the ethernet errors (BTW, all forums are different : how to make this output as spoiler ?) : Those few manual copy/paste lines at the end making the boot process occurred successfully ... (on a SideNote, I'm seeing that my DT ConfigFS patches are not apply in this PineA64 flavor, I will have to dig that too ... Grrrr ! first investigation is that you disabled it 3 days ago : https://github.com/igorpecovnik/lib/commit/735dee1d4da978331ed018c948938b2473f9c90e Could tell me what was wrong there ? ... And please, send notice when such thing occurs ... )

Hi Zador, Thanks for the info, unfortunately, the multiple reset doesn't work for me. Is it working for you ? According to the most "interesting" part, lowering the clock should be the way to go, but I haven't figured out where it should be done. EDIT : I found that, but this is already commited ... https://patchwork.ozlabs.org/patch/627962/

I've decided to give a try for a Mainline PineA64 Armbian Full Image build. Unfortenately, it seems that U-Boot is not in good shape, it stall right at the beginning without even trying to load kernel : HELLO! BOOT0 is starting! boot0 commit : 045061a8bb2580cb3fa02e301f52a015040c158f boot0 version : 4.0.0 set pll start set pll end rtc[0] value = 0x00000000 rtc[1] value = 0x00000000 rtc[2] value = 0x00000000 rtc[3] value = 0x00000000 rtc[4] value = 0x00000000 rtc[5] value = 0x00000000 DRAM driver version: V1.1 rsb_send_initseq: rsb clk 400Khz -> 3Mhz PMU: AXP81X ddr voltage = 1500 mv DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3) DRAM clk = 672 MHz DRAM zq value: 003b3bbb DRAM single rank full DQ OK DRAM size = 2048 MB DRAM init ok dram size =2048 card boot number = 0, boot0 copy = 0 card no is 0 sdcard 0 line count 4 [mmc]: mmc driver ver 2015-05-08 20:06 [mmc]: sdc0 spd mode error, 2 [mmc]: Wrong media type 0x00000000 [mmc]: ***Try SD card 0*** [mmc]: HSSDR52/SDR25 4 bit [mmc]: 50000000 Hz [mmc]: 29664 MB [mmc]: ***SD/MMC 0 init OK!!!*** sdcard 0 init ok The size of uboot is 00068000. sum=ab1a8b8a src_sum=ab1a8b8a Succeed in loading uboot from sdmmc flash. boot0: start load other image boot0: Loading BL3-1 Loading file 0 at address 0x40000000,size 0x00000200 success boot0: Loading scp Loading file 2 at address 0x00040000,size 0x0000b200 success set arisc reset to de-assert state Ready to disable icache. Jump to secend Boot. NOTICE: BL3-1: Running in SRAM A2 (@0x44000) NOTICE: Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):f11ecb4 NOTICE: BL3-1: Built : 14:12:39, Aug 19 2016 NOTICE: Configuring AXP PMIC NOTICE: PMIC: already configured for RSB NOTICE: PMIC: setup successful INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9 Any body can explain that stall ? Notes : the kernel build itself is Ok, because I've taken an already working Pine64 image and placed the new Kernel in it and it is booting and working properly.

To be able to boot from eMMC while the SDCard is still inserted, you will need to have a custom U-Boot that doesn't look at SDCard/mmc0 device at all. Standard U-Boot always consider the SDCard as the primary boot devices while eMMC is only a fallback when no SDCard present. Another possible workaround is that you still have the /boot partition on the SDCard, but having it configured to use eMMC as the RootFS, so that SDCard space will be almost recovered for data. To do that, simply boot from eMMC without any SDCard, then insert a copy of your previous SDCard, format the partition, and re-copy the /boot from eMMC to SDCard.

So, the problem isn't there ! I'm running out of ideas... Maybe you will have to try again the nand_sata_install to see if it still fail.

can you show what you have in your /etc/fstab (the one located in the eMMC, not the one on SDCard) ?

With this log, it is clearly showing that mmcblk2p1 is mounted. So, why are you saying that it is not working ?

Do you mean you were using this one https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 Maybe the missing pins could be added in orangepi_PC_gpio_pyH3-master/pyA20/gpio/mapping.h

I've done a PR for applying those Dynamic DT Overlays patches into "sunxi-next". Next thing to do is to apply it also into "sunxi-dev". EDIT : "sunxi-dev" done ! it was a bit more work since part of the patches were not required anymore in 4.8.x

Since initial state, as zador mentioned, is "input, no pullup", you will need to add pullup or pulldown depending of what Pmos/Nmos you choose and the initial state you wish to have.

Thanks Zador for your feedback ! I'm not fluent with the whole build process, so I will have to figure out how to get those overlays sample copied from /bin to /lib/firmware/overlays of the final image. BTW, today, I've decided to revamp my OlinuXinoA20-Micro with full image. I saw that patching mechanism used /patch/kernel/sunxi-* instead of /patch/kernel/sun8i-* for H3 didn't bring by patches, so I will have to port my Dynamic DT Overlays patches for that target too. It should be trivial, I hope so, I will see tomorrow ...

That is a bit of myth in some people's thinkings. If they were acting like that, it would means that LED is in conducting mode. Same thing applied when LED is connected in Sink mode, it doesn't act as PullUp, otherwise it will glow ...

Unfortunately, I don't see much comments about my recent works ... http://forum.armbian.com/index.php/topic/1633-dynamic-device-tree-overlays/ http://forum.armbian.com/index.php/topic/1537-397-maintainfix-dts-entries-for-some-devices-such-i2cspiw1/ Did someone has chances to give it try or I'm the only one using it to load overlays ? As asked in the PRs (which didn't have much comments either, even if officially merged), where should Armbian image should provide DT overlays samples ? Should it be a bit like BeagleBone locating them somewhere like /lib/firmware/overlays ? (I've now having some overlays ready such i2c-enable.dtbo, spi-enable.dtbo and w1-gpio-overlay.dtbo. Others such mcp-enable.dtbo, gpio-keys.dtbo and matrix-keypad.dts could be added soon if well tested.)

Ok ! I dig a bit more ... In fact, the commit above done 9 months ago in Mainline is legitimate and it only cause a bug/mistake in the orangepi_PC_gpio_pyH3 to come to the surface and been discovered : diff orangepi_PC_gpio_pyH3-master/pyA20/spi/spi.c.bak orangepi_PC_gpio_pyH3-master/pyA20/spi/spi.c 239c239 < config.speed = 100000; --- > config.speed = 10000000; As you can see, the author was setting "transfer speed" default to 100kHz instead of 10MHz ... I won't blame duxingkei33 who simply ported the original pyA20 from Olimex to H3, but Stefan Mavrodiev author of the Olimex one. EDIT : I've opened issue on both github : https://github.com/OLIMEX/OLINUXINO/issues/39 https://github.com/duxingkei33/orangepi_PC_gpio_pyH3/issues/4

I've took some time to dig the issue and I've found something by diffing my old 4.4.5 and my 4.6.2 : diff sources/linux-vanilla/v4.4.5/drivers/spi/spi-sun6i.c sources/linux-sun8i-mainline/orange-pi-4.6/drivers/spi/spi-sun6i.c 220,221c220,221 < if (mclk_rate < (2 * spi->max_speed_hz)) { < clk_set_rate(sspi->mclk, 2 * spi->max_speed_hz); --- > if (mclk_rate < (2 * tfr->speed_hz)) { > clk_set_rate(sspi->mclk, 2 * tfr->speed_hz); 239c239 < div = mclk_rate / (2 * spi->max_speed_hz); --- > div = mclk_rate / (2 * tfr->speed_hz); 246c246 < div = ilog2(mclk_rate) - ilog2(spi->max_speed_hz); --- > div = ilog2(mclk_rate) - ilog2(tfr->speed_hz); Mainline guys introduced the usage of "transfer speed" instead of using "spi max speed". Until now, I didn't find where the "transfer speed" is initialized, and probably it is never initialized. So, workaround for now, is to revert to the "spi max speed" ...

Boot from sdcard, redo nand_sata_install again, it is doesn't work, you can fix it manually but doing something like : dd if=/usr/lib/linux-u-boot-dev-orangepipcplus_5.17_armhf/u-boot-sunxi-with-spl.bin of=/dev/mmcblk2 bs=1024 seek=8 (I've wrote /dev/mmcblk2 because I'm using Mainline kernels, but on Legacy, it could be /dev/mmcblk1 instead, I'm not sure)

In the OPi+2E, the driver is the F one, since it is the SDIO variant : 8189fs

In fact, I've also used an small ST7735 display on one of my OPiPC, it was working fine in 4.4.4 and 4.4.5, but when I've upgraded in 4.5.x and even later 4.6.x, it was horribly slow (displaying a clock even skip some seconds sometimes). Unfortunately, I didn't get chance to narrow the reasons and didn't spent too much time on the case, since it wasn't my priority and "time is still the missing ingredient". I presume it is a bug introduced somehow in clock management of Mainline.

That's explain everything ... If I remember when I faced the same issue, I've explicitly copied the current MAC into the 8189fs.conf file, so I "fixed" the issue by placing a 00:e0:4c manually. In mainline, it looks like the same code, because in fact, when I commit it, the sources was merged with Hans changes, but origins are common. I see that the random init is using this code : *((u32 *)(&mac[2])) = rtw_random32(); mac[0] = 0x00; mac[1] = 0xe0; mac[2] = 0x4c; So, Yes, the firstrun should place the same RealTek prefix.

I'm using Mainline 4.6.2, and this /etc/modprobe.d/8189fs.conf works for me, it keep the same MAC at every reboot. But I don't know if the same happen in Legacy kernel.

Maybe there was something missing in 5.14, but in 5.17 the firstrun script is creating the file : /etc/modprobe.d/8189fs.conf, it should looks like : options 8189fs rtw_initmac=00:e0:4c:f5:16:d8

Yes, I've seen that too. In a build log, I found that error : [[[0;32m o.k. [[0m] Checking toolchain [[[0;33m gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux [[0m] [[[0;32m .... [[0m] Downloading [[[0;32m .... [[0m] Verifying [[[0;35m warn [[0m] Verification failed

For GPIO, take a look at https://github.com/duxingkei33/orangepi_PC_gpio_pyH3

I'm not sure to following you ... Do you means a NIC that wasn't defined in the top level DTB ? This scenario are pretty rare, but you it should be doable if top level expose everything needed. But I don't see the advantages, especially if this NIC needs to be present all the time. Overlays are best suit for things that require to be loaded/unloaded dynamically. Currently, I have I2C, SPI and W1 sample overlays.