[WiP / Orange Pi One] Support for the upcoming Orange Pi One?

[tkaiser]

Still no u-boot patch: 'sources/u-boot/branchless# find . -name sy8106a.c' returns nothing. Thx, Zador. Will try PL08 out on the weekend and keep you informed. 

[Igor]

root@production:~/sources/u-boot/branchless# patch -p1 < /root/lib/patch/u-boot/u-boot-dev/sy8106a.patch 
patching file board/sunxi/Kconfig
patching file board/sunxi/board.c
patching file configs/orangepi_pc_defconfig
patching file drivers/power/Kconfig
patching file drivers/power/Makefile
patching file drivers/power/sy8106a.c
patching file include/configs/sunxi-common.h
patching file include/sy8106a.h

If you override TAG that doesn't mean you are in DEV branch so the patch must be in DEFAULT ... and it works. I also made wrong conclusion. Copy patch to default.

[tkaiser]

If you override TAG that doesn't mean you are in DEV branch so the patch must be in DEFAULT ... and it works. I also made wrong conclusion. Copy patch to default.

 

 

Nah, that's too much for me/today. I'm really confident that someone else takes care of this patch to be applied for all SY8106A capable devices.

 

I'm currently trying to burn my house down (unattended Orange Pi One benchmark runs with activated overvolting), try to relax and try also to stay away from the boards until sunday.

 

BTW: Jean-Luc from cnx-software.com might probably pick up the Orange Pi One overvolting issue once more (might depend on the results of the tests I run currently regarding potential damage to the boards), so it might be good to have as much images/boards ready when he awakens (his timezone is ITC AFAIK) 

[tkaiser]

Something like PL08 or PL09 looks unused enough in all orange*.fex files and in H3 datasheet.

 

I took PL08 and it works: https://github.com/igorpecovnik/lib/pull/154

 

You're hero of the day

[tkaiser]

I finished a small series of tests regarding the new voltage regulator: TL;DR: There went something really wrong -- try to avoid voltage switching on Orange Pi One!

 

On Orange Pi One the new voltage regulator should switch the Vcore voltage between 1.1V (624 MHz) and 1.3V (everything above). What seems to happen in reality is that there's something seriously going wrong. The adjusted voltages seem to be way higher which leads to insane overclocking/overheating when we allow the SY8113B step-down converter to switch to the higher voltage.

 

On top we have a small problem regarding thermal readouts from the SoC. When combining mainline u-boot with the outdated lichee 3.4.x kernel reported internal temperatures are a bit too low (most probably due to some clock mismatches since higher temperatures are reported with lower DRAM freq -- pretty unlikely).

 

I started a set of tests constantly increasing CPU load and comparing thermal readouts and throttling between

• u-boot 2011.09 (boot0) as used on Xunlong's and loboris' OS images for H3
• mainline u-boot as used with Armbian and OpenELEC for H3

With fex settings that don't allow Orange Pi One to switch to the higher voltage everything is almost ok. Temperature differences aren't that much and throttling seems to work ok in both situations:

 

Disabled dvfs combined with boot0:

 

 

 

Disabled dvfs combined with mainline u-boot:

 

 

 

When we allow voltage switching it gets weird. It seems the higher voltage is way beyond everything that's sane (still to be confirmed by someone with Orange Pi One and a Multimeter walking through the available testpoints on the PCB). The same benchmarks lead to heavy overheating now. With the somewhat calibrated temperature readouts when using boot0 the kernel decides already at 816MHz to kill all CPU cores but one!

 

When using mainline u-boot together with kernel 3.x then the few degrees make a huge difference. Here thermal throttling jumps in when H3 is running at 1008 MHz and CPU cores are killed way too late (when running cpuburn-a7 which does exactly what the name describes):

 

Enabled dvfs combined with boot0:

 

 

Enabled dvfs combined with mainline u-boot:

 

 

Simple conclusion: Do not allow voltage switching on the Orange Pi One and stay on the lower voltage! Armbian's settings already take care.

[szaflik]

Hello,

 

I've got some crash in dmesg on latest 5.01 Jessie (OrangePi One) build:

[   69.023650] BUG: Bad page state in process loadcpufreq  pfn:5301d
[   69.023677] page:c0df1414 count:0 mapcount:-16384 mapping:  (null) index:0x14
[   69.023687] page flags: 0x0()
[   69.023696] Modules linked in: w1_therm w1_gpio wire w1_sunxi gpio_sunxi
[   69.023768] [<c0016cdc>] (unwind_backtrace+0x0/0xe8) from [<c06d7840>] (dump_stack+0x20/0x24)
[   69.023801] [<c06d7840>] (dump_stack+0x20/0x24) from [<c00df084>] (bad_page+0xec/0x11c)
[   69.023824] [<c00df084>] (bad_page+0xec/0x11c) from [<c00df49c>] (get_page_from_freelist+0x24c/0x530)
[   69.023848] [<c00df49c>] (get_page_from_freelist+0x24c/0x530) from [<c00e04d8>] (__alloc_pages_nodemask+0x21c/0x8ac)
[   69.023878] [<c00e04d8>] (__alloc_pages_nodemask+0x21c/0x8ac) from [<c00fc1d4>] (do_wp_page+0x4ec/0x7a4)
[   69.023909] [<c00fc1d4>] (do_wp_page+0x4ec/0x7a4) from [<c00fd8bc>] (handle_pte_fault+0x52c/0x7e4)
[   69.023934] [<c00fd8bc>] (handle_pte_fault+0x52c/0x7e4) from [<c00fdc88>] (handle_mm_fault+0x114/0x150)
[   69.023959] [<c00fdc88>] (handle_mm_fault+0x114/0x150) from [<c001b43c>] (do_page_fault+0x118/0x344)
[   69.023984] [<c001b43c>] (do_page_fault+0x118/0x344) from [<c00083c0>] (do_DataAbort+0x44/0xa8)
[   69.024005] [<c00083c0>] (do_DataAbort+0x44/0xa8) from [<c000dc58>] (__dabt_usr+0x38/0x40)
[   69.024020] Exception stack(0xd4cd1fb0 to 0xd4cd1ff8)
[   69.024033] 1fa0:                                     00000183 00000000 00000000 00000181
[   69.024049] 1fc0: 00000183 be9d31e0 b6f3e390 be9d31f0 b6ef9000 b6f3e850 00000181 00000181
[   69.024068] 1fe0: 00000078 be9d31e0 b6e806d5 b6e8079a 600d0030 ffffffff
[   69.024081] Disabling lock debugging due to kernel taint

[tkaiser]

I've got some crash in dmesg on latest 5.01 Jessie (OrangePi One) build

 

Well, without further information it's a bit hard to get a clue what's going wrong.

 

You could try to replace both script.bin and kernel package with the latest versions and report back. The process is outlined some posts before on page 3 of this thread and the packages are (caution: this only works if you also replace /boot/bin/orangepione.bin since this is the unified kernel that works on all H3 models but needs a little fex tweak)

 

orangepione.bin   (md5sum: b8397d78f76f1517fd496fae7b4b7bc2)

kernel_5.01_h3_unified.tgz   (md5sum: d0fc5f32b5f5291d324cb65b838d8432)

 

@Igor: sy8106a.patch seems to break u-boot compilation at the moment but I would believe you already know that? And then I can confirm that our desktop image provides no Mali acceleration currently (framerates horribly low but maybe I just missed something)

 

 

 

 

 

 

But at least my peripherals work now!

[Igor]

@Igor: sy8106a.patch seems to break u-boot compilation at the moment but I would believe you already know that? And then I can confirm that our desktop image provides no Mali acceleration currently (framerates horribly low but maybe I just missed something)

 

Actually I haven't try to compile. Was already half sleeping at the time ... will check up.

 

Not working MALI could be related to kernel command line, again We are setting some no_video_memory ... etc by default.

[tkaiser]

Not working MALI could be related to kernel command line, again We are setting some no_video_memory ... etc by default.

 

Ok, I think the whole trusty/desktop approach needs a rework (X running not as root, optimised settings). There are also packages missing in trusty (sunxi-tools and man just to mention two). I will stay on trusty the next time (just to get an idea what's missing when trying to finalise armbianmonitor) but won't pay any attention to desktop/GUI/acceleration issues. Maybe someone else who's interested in this area might jump in so we end up with a performant desktop as well...

 

It would be also great if we get volunteers/maintainers of stuff like WiringOP on board (providing it as a .deb and so on) but for now I'm already happy that we got safe thermal/dvfs settings for the One and everything up and running with a single kernel image to start providing upgradeable images (we have to take care now since without exchanging script.bin a kernel update will render Ethernet unuseable on PC/2/One)

[gilsken]

Hi,

I've just tried the last debian jessie in your release 5.01 on my orange pi pc and so far it's everything fine except that only one usb port is working and after installing the lxde I can't change my screen desktop resolution to FullHD 1920*1800.

 

Maybe it comes from my board or myself.

[tkaiser]

except that only one usb port is working and after installing the lxde I can't change my screen desktop resolution to FullHD 1920*1800.

 

The USB issue is a bit strange (and normally a sign for wrong fex/script.bin settings). Changing resolution unfortunately requires also fex changes at the moment. In case you're a bit experienced then follow the steps on page 3 of this thread to install most recent fixes for 5.01 from this morning (also replace script.bin!) and then you would've to use bin2fex and fex2bin to convert /boot/bin/orangepipc.bin into a temporary fex file, then adjust the following (replace 4 with 10 two times) and convert back to orangepipc.bin afterwards:

screen0_output_mode = 10
screen1_output_type = 3
screen1_output_mode = 10

10 is 1080p (the default was 4 = 720p): http://linux-sunxi.org/Fex_Guide#disp_init_configuration

 

Later we will provide a utility called h3disp that adjusts that on the fly and we'll also try to get display config dynamically working so that every display resolution can be used. But at the moment our OS images are just preliminary test images and i doubt you'll have fun using X windows (at least my experience based on a short test this morning -- unbelievable slow since we didn't took care about desktop optimisation already)

[jmarcelino]

Hi all,

I'm very new to Armbian, actually got interested due to the Orange Pi One. Looks like a cool project 

 

I compiled a Jessie build on Feb 14 which was working well on the One board and after reading the latest messages decided to try a newer build. 

However both the image on the site (  Jessie  ) and compiled from github (with all the latest commits) don't seem to boot.

 

Serial console just shows the below and hangs before showing a login prompt. Ethernet also never comes up.

After reverting to the Feb 14 image everything works well again.

 

 

 

 U-Boot 2016.01-armbian (Feb 19 2016 - 03:34:21 -0500) Allwinner Technology

 

CPU:   Allwinner H3 (SUN8I)

DRAM:  512 MiB

MMC:   SUNXI SD/MMC: 0

*** Warning - bad CRC, using default environment

 

In:    serial

Out:   serial

Err:   serial

Net:   No ethernet found.

starting USB...

No controllers found

Hit any key to stop autoboot:  0

switch to partitions #0, OK

mmc0 is current device

Scanning mmc 0:1...

Found U-Boot script /boot/boot.scr

2089 bytes read in 328 ms (5.9 KiB/s)

## Executing script at 43100000

** File not found /boot/.next **

** Unrecognized filesystem type **

** File not found .next **

35832 bytes read in 747 ms (45.9 KiB/s)

4768776 bytes read in 10329 ms (450.2 KiB/s)

Kernel image @ 0x48000000 [ 0x000000 - 0x48c408 ]

Using machid 0x1029 from environment

 

Starting kernel ...

 

[sun8i_fixup]: From boot, get meminfo:

        Start:  0x40000000

        Size:   512MB

ion_carveout reserve: 160m@0 256m@0 130m@1 200m@1

ion_reserve_common: ion reserve: [0x56000000, 0x60000000]!

 

 

 

 

Any ideas or something I can try? I understand things are still shifting around but some of the replies above make me think this should be working on the One board at the moment.

Cheers

[tkaiser]

Serial console just shows the below and hangs before showing a login prompt. Ethernet also never comes up.

 

I would suspect that's the issue I described above: New unified kernel without fex tweaks. For the new kernel on Orange Pi PC/2/One two additional lines in the fex file are needed:

[gmac_phy_power]
gmac_phy_power_en   = port:PL08<1><default><default><0>

I updated an 5.00 image successfully with the debs and orangepione.bin from here: http://forum.armbian.com/index.php/topic/617-wip-support-for-the-upcoming-orange-pi-one/?p=5224

 

So please give this a try first and when building stuff on your own remember that you'll also need a modified script.bin containing the stuff above to work on PC/2/One from now on.

[Igor]

First change console to serial and loglevel to 8 that we will see something in the bootlog.

[tkaiser]

First change console to serial and loglevel to 8 that we will see something in the bootlog.

 

Maybe it's a good idea to enable this by default on the H3 images unless we consider them stable? And maybe adding "disp.screen0_output_mode=10" to boot.cmd (see new pull request)

[jmarcelino]

I would suspect that's the issue I described above: New unified kernel without fex tweaks. For the new kernel on Orange Pi PC/2/One two additional lines in the fex file are needed:

[gmac_phy_power]
gmac_phy_power_en   = port:PL08<1><default><default><0>

 

I think this setting is already in the tree? My latest build has this already.

 

First change console to serial and loglevel to 8 that we will see something in the bootlog.

 

 

Thanks, just did that. Appreciate your help and patience while I learn the ropes.. 

 

I'm now seeing that the board is "crashing" in different ways, on one run I got this:

 

 

 

[ 0.645510] sunxi_cmatest_init enter

[ 0.770065] sunxi_cmatest_init success

[ 0.774462] loop: module loaded

[ 0.836636] sunxi_spi_chan_cfg()1355 - [spi-0] has no spi_regulator.

[ 0.836650] sunxi_spi_chan_cfg()1355 - [spi-1] has no spi_regulator.

[ 0.836685] tun: Universal TUN/TAP device driver, 1.6

[ 0.836693] tun: © 1999-2004 Max Krasnyansky

[ 0.837659] PPP generic driver version 2.4.2

[ 0.837837] PPP BSD Compression module registered

[ 0.837846] PPP Deflate Compression module registered

[ 0.838648] PPP MPPE Compression module registered

[ 0.838661] NET: Registered protocol family 24

[ 0.838721] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver

[ 0.858798] sunxi-ehci sunxi-ehci.1: SW USB2.0 'Enhanced' Host Controller (EHCI) Driver

[ 0.858831] sunxi-ehci sunxi-ehci.1: new USB bus registered, assigned bus number 1

[ 0.932288] sunxi-ehci sunxi-ehci.1: irq 104, io mem 0xf1c1a000

[ 1.140040] sunxi-ehci sunxi-ehci.1: USB 0.0 started, EHCI 1.00

[ 1.257188] hub 1-0:1.0: USB hub found

[ 1.261382] hub 1-0:1.0: 1 port detected

[ 1.286122] sunxi-ehci sunxi-ehci.2: SW USB2.0 'Enhanced' Host Controller (EHCI) Driver

[ 1.295036] sunxi-ehci sunxi-ehci.2: new USB bus registered, assigned bus number 2

[ 1.304000] sunxi-ehci sunxi-ehci.2: irq 106, io mem 0xf1c1b000

[ 1.330039] sunxi-ehci sunxi-ehci.2: USB 0.0 started, EHCI 1.00

[ 1.337139] hub 2-0:1.0: USB hub found

[ 1.341326] hub 2-0:1.0: 1 port detected

[ 1.346071] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver

[ 1.372992] sunxi-ohci sunxi-ohci.1: SW USB2.0 'Open' Host Controller (OHCI) Driver

[ 1.381529] sunxi-ohci sunxi-ohci.1: new USB bus registered, assigned bus number 3

[ 1.389953] sunxi-ohci sunxi-ohci.1: irq 105, io mem 0xf1c1a400

[ 1.454556] hub 3-0:1.0: USB hub found

[ 1.458726] hub 3-0:1.0: 1 port detected

[ 1.483470] sunxi-ohci sunxi-ohci.2: SW USB2.0 'Open' Host Controller (OHCI) Driver

[ 1.491996] sunxi-ohci sunxi-ohci.2: new USB bus registered, assigned bus number 4

[ 1.500434] sunxi-ohci sunxi-ohci.2: irq 107, io mem 0xf1c1b400

[ 1.564601] hub 4-0:1.0: USB hub found

[ 1.568769] hub 4-0:1.0: 1 port detected

[ 1.573512] Initializing USB Mass Storage driver...

[ 1.579068] usbcore: registered new interface driver usb-storage

[ 1.585751] USB Mass Storage support registered.

[ 1.590932] usbcore: registered new interface driver ums-alauda

[ 1.597541] usbcore: registered new interface driver ums-cypress

[ 1.604272] usbcore: registered new interface driver ums-datafab

[ 1.610995] usbcore: registered new interface driver ums_eneub625

[ 1.617893] usbcore: registered new interface driver ums-freecom

[ 1.624619] usbcore: registered new interface driver ums-isd200

[ 1.631239] usbcore: registered new interface driver ums-jumpshot

[ 1.638034] usbcore: registered new interface driver ums-karma

[ 1.644565] usbcore: registered new interface driver ums-onetouch

[ 1.651402] usbcore: registered new interface driver ums-realtek

[ 1.658105] usbcore: registered new interface driver ums-sddr09

[ 1.664734] usbcore: registered new interface driver ums-sddr55

[ 1.671410] usbcore: registered new interface driver ums-usbat

[ 1.678211] file system registered

[ 1.683798] android_usb gadget: Mass Storage Function, version: 2009/09/11

[ 1.691466] android_usb gadget: Number of LUNs=3

[ 1.696590] lun0: LUN: removable file: (no medium)

[ 1.702016] lun1: LUN: removable file: (no medium)

[ 1.707428] lun2: LUN: removable file: (no medium)

[ 1.713164] android_usb gadget: android_usb ready

[ 1.718604] uinput result 0 , vmouse_init

[ 1.723871] mousedev: PS/2 mouse device common for all mice

[ 1.730293] ls_fetch_sysconfig_para: type err device_used = 0.

[ 1.736958] =========script_get_err============

[ 1.742026] ltr_init: ls_fetch_sysconfig_para err.

[ 1.747890] sunxi-rtc sunxi-rtc: rtc core: registered sunxi-rtc as rtc0

[ 1.755292] i2c /dev entries driver

[ 1.759426] IR RC5(x) protocol handler initialized

[ 1.764874] sunxi cedar version 0.1

[ 1.768881] [cedar]: install start!!!

[ 1.773152] [cedar]: install end!!!

[ 1.777256] sunxi_i2c_do_xfer()980 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x18)

[ 1.786614] sunxi_i2c_do_xfer()980 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x19)

[ 1.795964] sunxi_i2c_do_xfer()980 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x1a)

[ 1.805310] sunxi_i2c_do_xfer()980 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x29)

[ 1.814655] sunxi_i2c_do_xfer()980 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x2a)

[ 1.824001] sunxi_i2c_do_xfer()980 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x2b)

[ 1.833346] sunxi_i2c_do_xfer()980 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x4c)

[ 1.842690] sunxi_i2c_do_xfer()980 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x4d)

[ 1.852035] sunxi_i2c_do_xfer()980 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x4e)

[ 1.861226] sunxi_wdt_init_module: sunxi WatchDog Timer Driver v1.0

[ 1.868339] sunxi_wdt_probe: devm_ioremap return wdt_reg 0xf1c20ca0, res->start 0x01c20ca0, res->end 0x01c20cbf

[ 1.879505] sunxi_wdt_probe: initialized (g_timeout=16s, g_nowayout=0)

[ 1.886965] wdt_enable, write reg 0xf1c20cb8 val 0x00000000

[ 1.893163] timeout_to_interv, line 167

[ 1.897415] interv_to_timeout, line 189

[ 1.901683] wdt_set_tmout, write 0x000000b0 to mode reg 0xf1c20cb8, actual timeout 16 sec

[ 1.911182] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com

[ 1.920651] [cpu_freq] ERR:get cpu extremity frequency from sysconfig failed, use max_freq

[ 1.930137] [mmc]: SD/MMC/SDIO Host Controller Driver(v1.109 2014-12-4 20:51) Compiled in Feb 19 2016 at 07:23:58

[ 1.941575] [mmc]: get mmc0's sdc_power is null!

[ 1.946716] [mmc]: get mmc1's sdc_power is null!

[ 1.951849] [mmc]: get mmc1's 2xmode ok, val = 1

[ 1.956971] [mmc]: get mmc1's ddrmode ok, val = 1

[ 1.962207] [mmc]: MMC host used card: 0x3, boot card: 0x0, io_card 2

[ 1.970370] [mmc]: sdc0 set ios: clk 0Hz bm OD pm OFF vdd 3.3V width 1 timing LEGACY(SDR12) dt B

[ 1.981442] [ARISC ERROR] :wait hard syn message time out

[ 1.987526] [ARISC ERROR] :message addr : f004b840

[ 1.993044] [ARISC ERROR] :message state : 5

[ 1.997871] [ARISC ERROR] :message attr : 2

 

 

 

on another it seemed worse:

 

 

[ 2.013369] Process swapper/0 (pid: 1, stack limit = 0xd58362f8)

[ 2.013369] Stack: (0xd5837db0 to 0xd5838000)

[ 2.013369] 7da0: d5837de4 d5837dc0 c0377420 c0362240

[ 2.013369] 7dc0: 00000000 c080637e d59171c0 00010002 d5837e30 c09af150 d5837e04 d5837de8

[ 2.013369] 7de0: c037841c c03773c8 d504ac00 c09aec98 d504aec0 00000001 d5837e64 d5837e08

[ 2.013369] 7e00: c04fb874 c03783e8 00000002 c004eb78 d5837e54 d5837e20 d50236c8 00000001

[ 2.013369] 7e20: c09af158 c09af150 00000000 00000000 00304750 00000000 d5837e54 c09af158

[ 2.013369] 7e40: c0a81500 c09aeacc c09aeacc 00000000 00000000 d5836000 d5837e74 d5837e68

[ 2.013369] 7e60: c0406690 c04fb718 d5837e9c d5837e78 c0405288 c0406678 00000000 c09af158

[ 2.013369] 7e80: c09af18c c09aeacc c0998a78 c09c5300 d5837ebc d5837ea0 c0405490 c04051c4

[ 2.013369] 7ea0: 00000000 00000000 c09aeacc c0405418 d5837ee4 d5837ec0 c04036e4 c0405424

[ 2.013369] 7ec0: d58f6f20 d5993af8 c035c0a8 c09aeacc d5993a40 00000000 d5837ef4 d5837ee8

[ 2.013369] 7ee0: c0404d44 c040366c d5837f24 d5837ef8 c04048e0 c0404d28 c082fc0b 00000003

[ 2.013369] 7f00: d5837f24 c09aeacc 00000003 c09af488 00000003 c09c5300 d5837f4c d5837f28

[ 2.013369] 7f20: c0405a98 c04047fc c04066d8 00000000 00000003 c09af488 00000003 c09c5300

[ 2.013369] 7f40: d5837f5c d5837f50 c0406be8 c04059f8 d5837f7c d5837f60 c091b62c c0406ba0

[ 2.013369] 7f60: 00000006 c0928874 c0947208 c091b504 d5837fbc d5837f80 c00086a4 c091b510

[ 2.013369] 7f80: 00000006 00000006 000000d2 c086ffd4 c004dbf8 00000006 c0928874 c0947208

[ 2.013369] 7fa0: c09c5300 c09c5300 000000d2 00000000 d5837ff4 d5837fc0 c08fe9f8 c0008610

[ 2.013369] 7fc0: 00000006 00000006 c08fe2c0 00000013 00000000 c08fe870 c000f16c 00000013

[ 2.013369] 7fe0: 00000000 00000000 00000000 d5837ff8 c000f16c c08fe87c bffbfdff dfffffff

[ 2.013369] [] (strcmp+0x10/0x40) from [] (pin_get_from_name+0x64/0x84)

[ 2.013369] [] (pin_get_from_name+0x64/0x84) from [] (pin_config_set+0x40/0xc4)

[ 2.013369] [] (pin_config_set+0x40/0xc4) from [] (sunxi_mci_probe+0x168/0xc44)

[ 2.013369] [] (sunxi_mci_probe+0x168/0xc44) from [] (platform_drv_probe+0x24/0x28)

[ 2.013369] [] (platform_drv_probe+0x24/0x28) from [] (driver_probe_device+0xd0/0x20c)

[ 2.013369] [] (driver_probe_device+0xd0/0x20c) from [] (__driver_attach+0x78/0x9c)

[ 2.013369] [] (__driver_attach+0x78/0x9c) from [] (bus_for_each_dev+0x84/0x98)

[ 2.013369] [] (bus_for_each_dev+0x84/0x98) from [] (driver_attach+0x28/0x30)

[ 2.013369] [] (driver_attach+0x28/0x30) from [] (bus_add_driver+0xf0/0x234)

[ 2.013369] [] (bus_add_driver+0xf0/0x234) from [] (driver_register+0xac/0x124)

[ 2.013369] [] (driver_register+0xac/0x124) from [] (platform_driver_register+0x54/0x68)

[ 2.013369] [] (platform_driver_register+0x54/0x68) from [] (sunxi_mci_init+0x128/0x148)

[ 2.013369] [] (sunxi_mci_init+0x128/0x148) from [] (do_one_initcall+0xa0/0x164)

[ 2.013369] [] (do_one_initcall+0xa0/0x164) from [] (kernel_init+0x188/0x24c)

[ 2.013369] [] (kernel_init+0x188/0x24c) from [] (kernel_thread_exit+0x0/0x8)

[ 2.013369] Code: e1a0c00d e92dd800 e24cb004 e4d03001 (e4d12001)

[ 3.235917] [mmc]: mmc 0 detect change, present 1

[ 3.241275] ---[ end trace caf2ec49524741cf ]---

[ 3.246432] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[ 3.246439]

[ 3.256570] CPU3: stopping

[ 3.259585] [] (unwind_backtrace+0x0/0xe8) from [] (dump_stack+0x20/0x24)

[ 3.266565] [] (dump_stack+0x20/0x24) from [] (handle_IPI+0x16c/0x2cc)

[ 3.266565] [] (handle_IPI+0x16c/0x2cc) from [] (gic_handle_irq+0x80/0x88)

[ 3.266565] [] (gic_handle_irq+0x80/0x88) from [] (__irq_svc+0x40/0x74)

[ 3.266565] Exception stack(0xd58eff68 to 0xd58effb0)

[ 3.266565] ff60: c0f48b38 00000000 0000000f 00000000 d58ee000 d58ee000

[ 3.266565] ff80: d58ee000 c09c5690 4000406a 410fc075 00000000 d58effbc d58effc0 d58effb0

[ 3.266565] ffa0: c000f2ac c000f2b0 60000013 ffffffff

[ 3.266565] [] (__irq_svc+0x40/0x74) from [] (default_idle+0x34/0x3c)

[ 3.266565] [] (default_idle+0x34/0x3c) from [] (cpu_idle+0xac/0xf8)

[ 3.266565] [] (cpu_idle+0xac/0xf8) from [] (secondary_start_kernel+0x118/0x13c)

[ 3.266565] [] (secondary_start_kernel+0x118/0x13c) from [<40667014>] (0x40667014)

[ 3.266565] CPU1: stopping

[ 3.266565] [] (unwind_backtrace+0x0/0xe8) from [] (dump_stack+0x20/0x24)

[ 3.266565] [] (dump_stack+0x20/0x24) from [] (handle_IPI+0x16c/0x2cc)

[ 3.266565] [] (handle_IPI+0x16c/0x2cc) from [] (gic_handle_irq+0x80/0x88)

[ 3.266565] [] (gic_handle_irq+0x80/0x88) from [] (__irq_svc+0x40/0x74)

[ 3.266565] Exception stack(0xd58b7f68 to 0xd58b7fb0)

[ 3.266565] 7f60: c0f38b38 00000000 0000000f 00000000 d58b6000 d58b6000

[ 3.266565] 7f80: d58b6000 c09c5690 4000406a 410fc075 00000000 d58b7fbc d58b7fc0 d58b7fb0

[ 3.266565] 7fa0: c000f2ac c000f2b0 60000013 ffffffff

[ 3.266565] [] (__irq_svc+0x40/0x74) from [] (default_idle+0x34/0x3c)

[ 3.266565] [] (default_idle+0x34/0x3c) from [] (cpu_idle+0xac/0xf8)

[ 3.266565] [] (cpu_idle+0xac/0xf8) from [] (secondary_start_kernel+0x118/0x13c)

[ 3.266565] [] (secondary_start_kernel+0x118/0x13c) from [<40667014>] (0x40667014)

[ 3.266565] CPU2: stopping

[ 3.266565] [] (unwind_backtrace+0x0/0xe8) from [] (dump_stack+0x20/0x24)

[ 3.266565] [] (dump_stack+0x20/0x24) from [] (handle_IPI+0x16c/0x2cc)

[ 3.266565] [] (handle_IPI+0x16c/0x2cc) from [] (gic_handle_irq+0x80/0x88)

[ 3.266565] [] (gic_handle_irq+0x80/0x88) from [] (__irq_svc+0x40/0x74)

[ 3.266565] Exception stack(0xd58e3f68 to 0xd58e3fb0)

[ 3.266565] 3f60: c0f40b38 00000000 0000000f 00000000 d58e2000 d58e2000

[ 3.266565] 3f80: d58e2000 c09c5690 4000406a 410fc075 00000000 d58e3fbc d58e3fc0 d58e3fb0

[ 3.266565] 3fa0: c000f2ac c000f2b0 60000113 ffffffff

[ 3.266565] [] (__irq_svc+0x40/0x74) from [] (default_idle+0x34/0x3c)

[ 3.266565] [] (default_idle+0x34/0x3c) from [] (cpu_idle+0xac/0xf8)

[ 3.266565] [] (cpu_idle+0xac/0xf8) from [] (secondary_start_kernel+0x118/0x13c)

[ 3.266565] [] (secondary_start_kernel+0x118/0x13c) from [<40667014>] (0x40667014)

[ 3.251135] [hotplug]: cpu(0) try to kill cpu(1)

[ 3.251135] [hotplug]: try to kill cpu:1 failed!

[ 3.251135] [hotplug]: cpu(0) try to kill cpu(2)

[ 3.251135] [hotplug]: try to kill cpu:2 failed!

[ 3.251135] [hotplug]: cpu(0) try to kill cpu(3)

[ 3.251135] [hotplug]: try to kill cpu:3 failed!

[ 3.251135] Rebooting in 10 seconds..

 

 

 

I'm guessing these are related to the voltage/speed changes?

[tkaiser]

I'm guessing these are related to the voltage/speed changes?

 

First thing I would check is whether /boot/script.bin is really linking to /boot/bin/orangepione.bin. You could also provide the whole boot output (put it on pastebin or use spoiler to hide it by default) also including u-boot messages since whether the correct script.bin was read can already be determinded there:

** File not found .next **
35704 bytes read in 684 ms (50.8 KiB/s)
4768760 bytes read in 4926 ms (945.3 KiB/s)

The size in the 2nd line has to match the size of /boot/bin/orangepione.bin.

 

Then I would immediately check the SD card you're booting off (just because I already wasted hours of my live searching problems in software when the hardware was to blame for. And fake/faulty SD cards are pretty common). Please check your card using either one of these tools before doing further investigation: https://github.com/igorpecovnik/lib/blob/master/documentation/user-faq.md#how-to-prepare-sd-card

[jernej]

I hope you don't mind if I join your party

 

There's still a bit to do. I'm already preparing h3disp (an utility that's only useful with 3.4.x since it will take script.bin and modify [hdmi_para] section to support different HDMI resolutions, patch the fex and convert back -- to be useable with Xunlong/loboris images too) but will first have a look into OpenELEC's/jernej's last patches that are display related since it would also be great to get fbset support to be able to use any display resolution possible.

My fbdev patch allows changing only to already supported resolutions on the fly, but you must be aware of two things:

1. video memory gets reserved at boot, so you can't change to resolution bigger than it was set at boot,

2. fbset changes only framebuffer resolution info, but doesn't actually switch to it in HW - that can be done via debugfs or disp2's ioctl interface

 

debugfs method:

sudo su
cd /sys/kernel/debug/dispdbg/
echo "switch" > command
echo "disp" > name
echo "4 5" > param
echo "1" > start

where 4 means HDMI output and 5 has the same meaning as in script.bin. For ioctl variant, which is more C friendly, you can check my Kodi patch.

 

Also one note on your unifying attempt and gmac patch / script.bin dilemma. Please check my github for updated patch. Idea behind it is that driver doesn't fail if there is no [gmac_phy_power] section in script.bin. That way you don't need to change script.bin at all.

 

And last but not least, if you want to use sy8106a patch on u-boot, you must update u-boot to version 2016.03-rc2.

[tkaiser]

I hope you don't mind if I join your party

 

Great, Igor already merged a pull request that's made totally of your stuff. Would also be great if someone else could look into your fallback for inappropriate script.bin settings (running out of time seriously)

 

I just wanted you to ask where the changes in script.bin regarding the GPIO pin definitions origin from? I thought the definition in loboris' script.bin would match already http://linux-sunxi.org/File:Xunlong_OrangePi_expansion_header_pinout.png

 

@Igor: With trusty we have a nasty reboot problem. System hangs prior to rebooting. I can remember there was a similiar problem with jessie a while ago? But this might bug people since they never see firstrun being finished properly.

 

EDIT: Woohoo, changing resolution through /sys/kernel/debug/dispdbg/ really worked (from 1080p down to 720p). But I guess we need to figure out correct /etc/fb.mode entries since the display's contents were rather garbled afterwards

[Igor]

@Igor: With trusty we have a nasty reboot problem. System hangs prior to rebooting. I can remember there was a similiar problem with jessie a while ago? But this might bug people since they never see firstrun being finished properly.

 

Yes, I also noticed on Pi+ but haven't got time to check up what's going on... we are going very fast

[zador.blood.stained]

@Igor: With trusty we have a nasty reboot problem. System hangs prior to rebooting. I can remember there was a similiar problem with jessie a while ago? But this might bug people since they never see firstrun being finished properly.

On Jessie it was related to default service stop timeout (90s) combined with wi-fi module unloading fail, so it was jessie and systemd specific problem, and shutdown/reboot still worked after that timeout.

 

I guess log from serial console should be the first thing to check.

[jernej]

Great, Igor already merged a pull request that's made totally of your stuff. Would also be great if someone else could look into your fallback for inappropriate script.bin settings (running out of time seriously)

 

I just wanted you to ask where the changes in script.bin regarding the GPIO pin definitions origin from? I thought the definition in loboris' script.bin would match already http://linux-sunxi.org/File:Xunlong_OrangePi_expansion_header_pinout.png

 

@Igor: With trusty we have a nasty reboot problem. System hangs prior to rebooting. I can remember there was a similiar problem with jessie a while ago? But this might bug people since they never see firstrun being finished properly.

 

I made it myself. It's simple. Pin can be defined either as GPIO or something else, e.g. I2C, but not both at the same time. On orange pi forum was one idea, that at least one SPI and one I2C should be defined by default instead of GPIO. That's it.

 

I also won't have much time for developing in following days, but I will be able to write some posts.

[tkaiser]

I made it myself. It's simple. Pin can be defined either as GPIO or something else, e.g. I2C, but not both at the same time. On orange pi forum was one idea, that at least one SPI and one I2C should be defined by default instead of GPIO. That's it.

 

Ok, i'm concerned about the situation that different OS images use different pin definitions (if unfortunate users try a tutorial for RPi and fail on OPi that's one thing but if they follow one for OPi just to realise that they've to check which OS image they use... you get the idea?)

 

I always thought there would a 'common' definition (most probably made by loboris) exist. Already containing of strange exceptions (1-Wire on GPIO connector 37 instead of 7 for example). But I thought it would be a good idea to stay with this since there exist other projects like WiringOP too.

 

Until now I never dig deep into this, I just wanted to avoid reinventing the wheel with Armbian and being incompatible to 'pseudo standards'. And now I'm even more confused

 

I think still we should try to define as much pins as possible like on RPi and maintain compatibility somewhat. But have no idea how... Will try your modifications out next week anyway.

 

In the end it would be nice to have a coloured picture of all 40 pins on the GPIO header with function names that match reality.

 

I guess log from serial console should be the first thing to check.

 

Unfortunately there's not that much to see (no change the last 10 minutes):

 

 

 

root@orangepione:~# shutdown -r now

Broadcast message from root@orangepione
        (/dev/ttyS0) at 18:34 ...

The system is going down for reboot NOW!
root@orangepione:~# Stopping fake hwclock: saving system time.
[ OK ]pping RPi-Monitor helper rpimonitor-helper        
find: `/sys/class/rc/*/': No such file or directory
rm: cannot remove '/var/run/rpimonitor-helper.pid': No such file or directory
rm: cannot remove '/var/run/rpimonitor-helper.pid': No such file or directory
[ ok ] Stopping ARM hardware info ...
haveged: haveged Stopping due to signal 15

[ OK ]pping RPi-Monitor rpimonitord        
[ OK ]pping rsync daemon rsync        
[ OK ]pping Network connection manager wicd        
[ OK ]ing all remaining processes to terminate...        
[ OK ] processes ended within 1 seconds... 

 

 

[tkaiser]

BTW: Since I'm still curious regarding thermal behaviour on the different Orange Pis I simplified installation of RPi-Monitor a bit.

 

This script should do everything automagically and you can enjoy RPi-Monitor on Port 8888 afterwards (won't be in conflict with our future armbianmonitor approach so feel free to get a clue what your device does even today!)

 

If you trust me the most easy way to install is as root

wget -q -O - http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-h3.sh | /bin/bash

But I would better download it and look through whether it's the same stuff as published here. Should also run flawlessly on any of the Debian based Xunlong or loboris images (many clueless Orange Pi One users over there in the forums might not have the slightest idea how they fry their boards without adopting sane dvfs settings)

[jmarcelino]

First thing I would check is whether /boot/script.bin is really linking to /boot/bin/orangepione.bin. You could also provide the whole boot output (put it on pastebin or use spoiler to hide it by default) also including u-boot messages since whether the correct script.bin was read can already be determinded there:

 

Then I would immediately check the SD card you're booting off (just because I already wasted hours of my live searching problems in software when the hardware was to blame for. And fake/faulty SD cards are pretty common). Please check your card using either one of these tools before doing further investigation: https://github.com/igorpecovnik/lib/blob/master/documentation/user-faq.md#how-to-prepare-sd-card

 

Thanks for all the tips. I checked the microSD card using F3 to make sure - it found no problems. In fact the same card has no problems in the Feb 14 build of Armbian, I can just flash the old image and it works perfectly. I'm aware of the fakes but this is a Sandisk Ultra 32Gb UHS-I U1 from a reputable company.

 

I also checked the script.bin and it is linking correctly to /boot/bin/orangepione.bin

 

I'm attaching three full logs since it crashes for apparently random reasons, the first two terminate with "unable to handle kernel paging request at address" errors while another starts throwing lots of MMC errors - but as I explained the SD card tests perfectly.

 

I then flashed this same card immediately after the tests with the old Feb 14 build and the Orange Pi One booted without a hickup.

 

Just to make sure I then repeated the same with another - brand new - SanDisk Ultra SD card with exactly the same result.

 

http://pastebin.com/3aBd6xrY

http://pastebin.com/K8vWQcXs

http://pastebin.com/Z8jymkbP

 

Not sure if it matters but I'm powering the Orange Pi One via the 5V and GND pins (1 and 3) on the 40 pin connector from a 3A power supply.

 

I'm happy to test out any other ideas as I'm keen to get this working.

 

Cheers

[tkaiser]

I'm happy to test out any other ideas as I'm keen to get this working.

 

Hmm... just some sort of 'brute force' attempt: Trying out an image that is known to work just to ensure that nothing in your build process corrupts anything: http://www.armbian.com/orange-pi-one/ Ok, realised that you already tried that. Unfortunately no idea what's going wrong. The image has been downloaded over a hundred times so I'm really clueless why it doesn't work for you.

[zador.blood.stained]

@jmarcelino

Only common things for all 3 crashes - error messages start right after

Starting LSB: Tune IDE hard disks...

which is, I believe, startup of hdparm service. Can you try removing hdparm (or removing /etc/init.d/hdparm startup script) and check if anything changes?

[jernej]

@tkaiser,

I saw your talk on IRC about camera module. Be aware that "SATA fix" also enabled CSI port (well, one pin on it). It could be that this was (part of) the problem. I can't test it, because I don't have a camera module.

 

I really don't know what to do about GPIO configuration. RPi is in advantage here because you don't need to set functionality at boot AFAIK. I'm very glad that mainline kernel is coming along

[jmarcelino]

which is, I believe, startup of hdparm service. Can you try removing hdparm (or removing /etc/init.d/hdparm startup script) and check if anything changes?

Thanks Zador,

Unfortunately removing it didn't help, but you're right about the consistent location of the errors, the problems seem to start around:

 

 

 

[  1.916105] [cpu_freq] ERR:get cpu extremity frequency from sysconfig failed, use max_freq

[    1.925590] [mmc]: SD/MMC/SDIO Host Controller Driver(v1.109 2014-12-4 20:51) Compiled in Feb 19 2016 at 11:58:42

[    1.937045] [mmc]: get mmc0's sdc_power is null!

[    1.942197] [mmc]: get mmc1's sdc_power is null!

[    1.947318] [mmc]: get mmc1's 2xmode ok, val = 1

[    1.952453] [mmc]: get mmc1's ddrmode ok, val = 1

[    1.957677] [mmc]: MMC host used card: 0x3, boot card: 0x0, io_card 2

[    1.965830] [mmc]: sdc0 set ios: clk 0Hz bm OD pm OFF vdd 3.3V width 1 timing LEGACY(SDR12) dt B

[    1.978456] Unable to handle kernel paging request at virtual address f5932d44

[    1.986467] pgd = c0004000

[    1.988394] [f5932d44] *pgd=00000000

[    1.988394] sunxi oops: enable sdcard JTAG interface

[    1.988394] sunxi oops: cpu frequency: 1200 MHz

[    1.988394] sunxi oops: ddr frequency: 624 MHz

[    1.988394] sunxi oops: gpu frequency: 105 MHz

[    1.988394] sunxi oops: cpu temperature: 217 

[    1.988394] Internal error: Oops: 5 [#1] PREEMPT SMP ARM

 

Do these values seem correct to you? This is using the latest build of the https://github.com/igorpecovnik/libtree.

 

I've also now tried a third, different brand and slower (Class 4) μSD card - hdparm removed - and the problem still persists but again slightly different output: http://pastebin.com/8wKpnwXz

 

I'll keep trying, maybe the next step is going back, reverting some of the patches to see which one caused these problems.

[tkaiser]

Be aware that "SATA fix" also enabled CSI port [...] I really don't know what to do about GPIO configuration.

 

Hmm... I applied your 'SATA fix' pretty late today so this seems not to be the culprit. I've to test on my own a bit more but fear that I'm not able to due to lack of spare time.

 

Regarding this GPIO thing. If we want to come up with something useful for all OPi users decisions have to be taken. Unfortunately I'm not that familiar with this stuff (user level -- I want to be able to use I2C, 1-Wire and SPI) so maybe the wrong people are talking here.

 

BTW: Do you guys (Igor and you) meet next week at Nuremberg or somewhere else (I ask since the only other guy called Jernej I know is from Slovenia -- one of the best times of my live being there working and constantly 'party hard')