yoq
-
Posts
17 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by yoq
-
-
Alright, I rebased my changes on karabek's repository: https://github.com/dbeinder/xradio/tree/karabek_rebase
The powersave commit is now split, with the power-lowering fix in the first part, and enabling userspace control over powersave in the second.
After some more direct comparison, I'm starting to think the part about removing driver-level TX rate selection doesn't make a measurable difference, in either throughput or dropped packets.
But since my much simpler code doesn't seem to make it worse either, I think that was just hacks built around the CW11x0 and simply never removed.
But as long as there is no upside, it's probably better not to diverge too much from the CW1200 mainline version, so I left that in a separate branch for now: https://github.com/dbeinder/xradio/commits/karabek_rebase_minstrel -
I repharsed that sentence, I was talking about WiFi powersave polling, check my github comments for more details. In the current version, it is active but somewhat broken, and in idle uses about 200mW more than it needs to. On the other hand if you switch powersave mode fully off, the XR819 uses 300mW more in idle than the current driver. My patches enable setting powersave mode from userspace with iwconfig, and so power consumption can go up quite a bit if powersave is not ON by default.
OPZ idle at 816MHz, WiFi driver not loaded: 610mW
Connected to WiFi network & idle/no traffic:Current XR819 driver armbian/karabek: 910mW (slightly broken powersave)
My patch: 700mW (powersave ON)
My patch: 1220mW (powersave OFF, enables low latency incoming pings)
Unfortunately, I believe kernel modules are not redistributable as compiled binaries, I think they only load if the kernel version matches perfectly. -
I know most of you probably don't want to hear any more about this chip, but I recently fixed quite a few long standing issues.
It's not perfect yet, but it improves scanning/reliable reconnect, incoming frames missed in powersave, ping times,and rate selection.
Here's the patch set:https://github.com/fifteenhex/xradio/pull/12Edit: rebased from karabek: https://github.com/dbeinder/xradio/commits/karabek_rebase
And some important comments about powersave: https://github.com/fifteenhex/xradio/pull/11#issuecomment-616226880
In short, relative to the current version, with powersave on, idle consumption is lower by 200mW, but with powersave off, it is 300mW higher- so that should be a consideration if you want to integrate this into Armbian builds for tiny boards like OPZero.
Of course a 65MBit chip will never be fast, but I'd say it is pretty usable as an IoT node now. This hasn't seen much testing, so your comments are appreciated. -
On the H2 (the same is true for most modern ARM chips) there is almost no benefit to lowering the clock rate by itself if the CPU has idle periods.
If the CPU is IDLE, it pretty much halts and will use the same amount of power, no matter the clock rate. The savings really come from changing the core voltage, which can be lower at low clock rates. With a proper power management controller, the voltage can be matched to the clock in many steps, but on the ZeroPi there are only 2 states: 1.1V and 1.3V. It switches to the higher voltage when the CPU is clocked higher than 816MHz, so on the OPZ you lose almost nothing by limiting the range of the ondemand governor to 816MHz - 1008MHz.
Unless you have a realtime application that never allows the CPU to sleep, I don't think there is any point to a lower clock than 816MHz.
-
Did you make sure there isn't also getty running on ttyS3?
-
UART2 with TX/RX should work out of the box if you enable the "uart2" overlay in armbianEnv.txt. I see you also have uart3 activated, afaik this port is not routed out on a OPZ.
RTS/CTS for UART2 is missing at the moment, but you can add it to the device tree manually. Create the file "uart2_rtscts_fix.dts" in your home folder:/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { uart2_rts_cts: uart2_rts_cts { pins = "PA2", "PA3"; function = "uart2"; }; }; }; };
Then run this to compile and add the custom overlay it to the device tree:
armbian-add-overlay uart2_rtscts_fix.dts
You need to keep param_uart2_rtscts=1, and on the next reboot, the error should be gone.
Edit: Oh and systemd likes to start a getty shell on all serial ports, so you may need to kill that service to make the port usable:
systemctl stop serial-getty@ttyS2.service
-
You can free up a core using isolcpus kernel parameter and then move your task on the unused core using taskset:
simply set it by adding extraargs=isolcpus=1 to your /boot/armbianEnv.txt
https://codywu2010.wordpress.com/2015/09/27/isolcpus-numactl-and-taskset/ -
-
I spent some time investigating this, I think it is a hardware/production issue. There is a calibration value in the eFuse, set during chip production. That value is currently not used in mainline, but in the affected hardware, it does not correct the offset anyway. In my good boards, it only caused a small change that looks reasonable. But the problematic boards are off by 20-30 degrees.
I wrote a small python3 script to access the hardware directly, it will print a dump of the THS registers, interpret the raw value into a temperature with all the formulas that were published one time or another, and apply the eFuse factory-calibration value. To see the effect, wait a few seconds and run again.
import time import os import mmap from sys import exit dev_mem_rw = os.open("/dev/mem", os.O_RDWR | os.O_SYNC) #send reset pulse to the THS subsystem if False: ccu_base = 0x01C20000 mmap_base = int(ccu_base/mmap.PAGESIZE)*mmap.PAGESIZE ccu_registers = mmap.mmap(dev_mem_rw, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE, offset=mmap_base) ccu_offset = ccu_base - mmap_base rst_reg3 = ccu_offset + 0x2D0 # bus soft rst reg3 current_state = ccu_registers[rst_reg3+1] ccu_registers[rst_reg3+1] = current_state & 0xFE ccu_registers[rst_reg3+1] = current_state print("Reset THS peripheral") ths_base = 0x01C25000 mmap_base = int(ths_base/mmap.PAGESIZE)*mmap.PAGESIZE ths_offset = ths_base - mmap_base ths_ctrl_reg0 = ths_offset + 0x00 # ctrl reg0 ths_ctrl_reg1 = ths_offset + 0x04 # ctrl reg1 ths_cdat_reg = ths_offset + 0x14 # ADC cal data ths_ctrl_reg2 = ths_offset + 0x40 # ctrl reg2 ths_int_ctrl = ths_offset + 0x44 # interrupt ctrl ths_stat_reg = ths_offset + 0x48 # status reg ths_alarm_ctrl = ths_offset + 0x50 # alarm ctrl ths_shdn_ctrl = ths_offset + 0x60 # shutdown ctrl ths_filter_ctrl = ths_offset + 0x70 # filter reg ths_cdata_reg = ths_offset + 0x74 # calibration data register ths_data_reg = ths_offset + 0x80 # thermal sensor data register ths_registers = mmap.mmap(dev_mem_rw, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE, offset=mmap_base) regs = { "ctrl0": ths_ctrl_reg0, "ctrl1": ths_ctrl_reg1, "cdat": ths_cdat_reg, "ctrl2": ths_ctrl_reg2, "int_ctrl": ths_int_ctrl, "stat": ths_stat_reg, "alarm": ths_alarm_ctrl, "shdn": ths_shdn_ctrl, "filter": ths_filter_ctrl, "cdata": ths_cdata_reg, "data": ths_data_reg } def dmp(): for name, r in regs.items(): b = ths_registers[r:r+4] x = int.from_bytes(b, byteorder='little') print(f"{name:10}{b[3]:02X} {b[2]:02X} {b[1]:02X} {b[0]:02X}\t{x}") adc_data = ths_registers[ths_data_reg:ths_data_reg+2] adc_value = int.from_bytes(adc_data, byteorder='little') print(f"ADC value: {adc_value}") t_ds = (adc_value-2794)/(-14.882) print(f"H2/H3 datasheet formula: {t_ds:.1f}C") t_h5 = -0.1191 * adc_value + 223 print(f"H5 datasheet formula: {t_h5:.1f}C") t_bsp1 = -0.1180 * adc_value + 256 print(f"BSP v4.9 formula: {t_bsp1:.1f}C") t_bsp2 = -0.1211 * adc_value + 217 print(f"mainline & xunlong kernel: {t_bsp2:.1f}C") with open("/sys/devices/virtual/thermal/thermal_zone0/temp", "r") as f: t_kernel = int(f.read()) / 1000.0 print(f"Running Kernel: {t_kernel:.1f}C") print("\nTHS Registers:") dmp() cal_value = int.from_bytes(ths_registers[ths_cdata_reg:ths_cdata_reg+4], "little") print(f"\nCurrent THS calibration value: 0x{cal_value:3x}") with open("/sys/bus/nvmem/devices/sunxi-sid0/nvmem", "rb") as f: f.seek(0x34) fuse_cal_value = int.from_bytes(f.read(4), "little") print(f"EFuse THS calibration value: 0x{fuse_cal_value:3x}") if cal_value != fuse_cal_value: ths_registers[ths_cdata_reg:ths_cdata_reg+4] = fuse_cal_value.to_bytes(4, "little") delta = (fuse_cal_value-cal_value)*0.1211 print(f"Applied calibration value from EFuse, this causes a change of {delta:.1f} deg C") #ths_registers[ths_ctrl_reg0:ths_ctrl_reg0+4] = (0xFF).to_bytes(4, "little") # 16x averaging #ths_registers[ths_filter_ctrl:ths_filter_ctrl+4] = (0x07).to_bytes(4, "little") # ADC calibration, seems to do nothing? #ths_registers[ths_ctrl_reg1:ths_ctrl_reg1+4] = ((1 << 17) | (0 << 20)| (0 << 21)).to_bytes(4, "little") # stop #ths_registers[ths_ctrl_reg2:ths_ctrl_reg2+4] = (4128769-1).to_bytes(4, "little") # start #ths_registers[ths_ctrl_reg2:ths_ctrl_reg2+4] = (4128769).to_bytes(4, "little")
You'll have to run it as root because it accesses the memory directly.
H2+ datasheet: http://wiki.friendlyarm.com/wiki/images/0/08/Allwinner_H2%2B_Datasheet_V1.2.pdf (THS is on page 255)
I left in some stuff in the script to control the hardware, if anyone wants to play with it without messing with the kernel
Good board, SoC temperature measured with thermocouple at 46°C:ADC value: 1414 H2/H3 datasheet formula: 92.7C H5 datasheet formula: 54.6C BSP v4.9 formula: 89.1C mainline & xunlong kernel: 45.8C Running Kernel: 45.6C THS Registers: ctrl0 00 00 00 FF 255 ctrl1 00 00 00 00 0 cdat 00 00 00 00 0 ctrl2 00 3F 00 01 4128769 int_ctrl 00 00 71 00 28928 stat 00 00 00 00 0 alarm 05 A0 06 84 94373508 shdn 04 E9 00 00 82378752 filter 00 00 00 06 6 cdata 00 00 08 00 2048 data 00 00 05 86 1414 Current THS calibration value: 0x800 EFuse THS calibration value: 0x817 Applied calibration value from EFuse, this causes a change of 2.8 deg C
Affected LTS board, SoC temperature on top: 47°C:
ADC value: 1626 H2/H3 datasheet formula: 78.5C H5 datasheet formula: 29.3C BSP v4.9 formula: 64.1C mainline & xunlong kernel: 20.1C Running Kernel: 20.0C THS Registers: ctrl0 00 00 00 FF 255 ctrl1 00 00 00 00 0 cdat 00 00 00 00 0 ctrl2 00 3F 00 01 4128769 int_ctrl 00 00 71 00 28928 stat 00 00 00 00 0 alarm 05 A0 06 84 94373508 shdn 04 E9 00 00 82378752 filter 00 00 00 06 6 cdata 00 00 08 00 2048 data 00 00 06 5A 1626 Current THS calibration value: 0x800 EFuse THS calibration value: 0x7fb Applied calibration value from EFuse, this causes a change of -0.6 deg C
-
I don't think I had to run anything else than the 3 lines I posted and reboot.
-
Thanks, that turned out be a good place to look. On a hunch, I tried swapping out wpa_supplicant for iwd as the wifi daemon for NetworkManager, and that did the trick.
apt install iwd systemctl disable wpa_supplicant echo -e "\n[device]\nwifi.backend=iwd\n" >> /etc/NetworkManager/NetworkManager.confI may just stick with iwd, but the root cause is probably that the aging xradio driver is missing support for some ioctl and it may just be a matter of time until a future release of iwd will send that one too.
-
I've done some work on kernel drivers and uboot in the past, that would not be a problem.
My point is that the XR819 worked on Armbian as good as the chip allows two months ago, and now the driver doesn't even initialize properly.
The fact that it stopped working on the old 4.19 kernel branch too, makes me think this is probably not a problem with kernel patches but with the system image.I'm happy to help, but I'm looking for some pointers.
-
2 hours ago, Tido said:
pls use search forum, right hand top corner. Thank you
I did, and did not find anything relevant to this particular problem. Can you point me to it?
I'm not complaining about the general unreliability of the XR819, I am well aware. -
Is it possible that there have been some image changes that broke the XR819 wifi completely?
The available images for download on the Armbian page (5.3 server, and 5.4 minimal) as well as a custom built "legacy" branch linux-4.19 image all show the same behavior,
The wlan0 interface is not active and it's not possible to bring it up. And dmesg shows that module has been initialized but not much more.
Armbianmonitor support info:
5.3.9 official buster server image: http://ix.io/240Y
4.19.88 self-built, two days ago, legacy branch: http://ix.io/240U
Everything below is from the official image, but the 4.19 image shows the exact sameIt is definitely not a hardware issue, I have a SD card with a an older 4.19.72 image (when the branch was still called "next") that works just fine.
ifconfig -aSpoilerroot@orangepizero:~# ifconfig -a dummy0: flags=130<BROADCAST,NOARP> mtu 1500 ether 4e:d7:ef:97:fe:24 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.9.9.74 netmask 255.255.255.0 broadcast 10.9.9.255 inet6 fdaa::140d:159f:ef8e:f4ab prefixlen 64 scopeid 0x0<global> inet6 fe80::dad5:d85e:5d75:f4ef prefixlen 64 scopeid 0x20<link> ether 02:42:a5:9f:f1:6a txqueuelen 1000 (Ethernet) RX packets 214 bytes 21011 (20.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 134 bytes 18689 (18.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 39 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4098<BROADCAST,MULTICAST> mtu 1500 ether 3a:7d:bf:4b:79:83 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0ifconfig
Spoilerroot@orangepizero:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.9.9.74 netmask 255.255.255.0 broadcast 10.9.9.255 inet6 fe80::a827:65fd:f762:999a prefixlen 64 scopeid 0x20<link> inet6 fdaa::1fd5:49e8:c762:1287 prefixlen 64 scopeid 0x0<global> ether 02:42:a5:9f:f1:6a txqueuelen 1000 (Ethernet) RX packets 1493 bytes 114739 (112.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1372 bytes 251320 (245.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 38 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0root@orangepizero:~# ifconfig wlan0 up SIOCSIFFLAGS: Invalid argument root@orangepizero:~# rfkill list 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no root@orangepizero:~# journalctl -b | grep xradio Nov 19 08:08:00 orangepizero kernel: xradio_wlan mmc1:0001:1: Input buffers: 30 x 1632 bytes Nov 19 08:08:00 orangepizero kernel: xradio_wlan mmc1:0001:1: Firmware Label:XR_C01.08.0043 Jun 6 2016 20:41:04 Nov 19 08:08:28 orangepizero NetworkManager[1057]: <info> [1574150908.3204] rfkill0: found WiFi radio killswitch (at /sys/devices/platform/soc/1c10000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/ieee80211/phy0/rfkill0) (driver xradio_wlan) root@orangepizero:~# uname -a Linux orangepizero 5.3.9-sunxi #19.11.3 SMP Mon Nov 18 18:49:43 CET 2019 armv7l GNU/Linux
-
Thanks, this turned out to be much more involved than I expected.
To save the next person some time, here's what it took:
Activate the uart(s) and change stdout-path in the device tree, then add CONFIG_CONS_INDEX=3 (starts from 1) in configs/orangepi_zero_defconfig:diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts index d166ffc0..abcc1874 100644 --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts @@ -56,13 +56,15 @@ aliases { serial0 = &uart0; + serial1 = &uart1; + serial2 = &uart2; /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ ethernet0 = &emac; ethernet1 = &xr819; }; chosen { - stdout-path = "serial0:115200n8"; + stdout-path = "serial2:115200n8"; }; leds { @@ -172,13 +174,13 @@ &uart1 { pinctrl-names = "default"; pinctrl-0 = <&uart1_pins>; - status = "disabled"; + status = "okay"; }; &uart2 { pinctrl-names = "default"; pinctrl-0 = <&uart2_pins>; - status = "disabled"; + status = "okay"; }; &usb_otg { diff --git a/configs/orangepi_zero_defconfig b/configs/orangepi_zero_defconfig index ef0c6884..956f6a28 100644 --- a/configs/orangepi_zero_defconfig +++ b/configs/orangepi_zero_defconfig @@ -17,3 +17,4 @@ CONFIG_SUN8I_EMAC=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y +CONFIG_CONS_INDEX=3 \ No newline at end of file
But CONFIG_CONS_INDEX is currently missing the pinmux code for uart1/uart2 in u-boot, so this also needs to be patched:diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h b/arch/arm/include/asm/arch-sunxi/gpio.h index 40a3f845..e6048983 100644 --- a/arch/arm/include/asm/arch-sunxi/gpio.h +++ b/arch/arm/include/asm/arch-sunxi/gpio.h @@ -148,6 +148,7 @@ enum sunxi_gpio_number { #define SUN6I_GPA_SDC2 5 #define SUN6I_GPA_SDC3 4 #define SUN8I_H3_GPA_UART0 2 +#define SUN8I_H3_GPA_UART2 2 #define SUN4I_GPB_PWM 2 #define SUN4I_GPB_TWI0 2 @@ -188,6 +189,7 @@ enum sunxi_gpio_number { #define SUN8I_GPG_SDC1 2 #define SUN6I_GPG_TWI3 2 #define SUN5I_GPG_UART1 4 +#define SUN8I_H3_GPG_UART1 2 #define SUN6I_GPH_PWM 2 #define SUN8I_GPH_PWM 2 diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index effbd032..e022bee4 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -133,10 +133,18 @@ static int gpio_init(void) sunxi_gpio_set_cfgpin(SUNXI_GPG(3), SUN5I_GPG_UART1); sunxi_gpio_set_cfgpin(SUNXI_GPG(4), SUN5I_GPG_UART1); sunxi_gpio_set_pull(SUNXI_GPG(4), SUNXI_GPIO_PULL_UP); -#elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUN8I) +#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNXI_H3_H5) + sunxi_gpio_set_cfgpin(SUNXI_GPG(6), SUN8I_H3_GPG_UART1); + sunxi_gpio_set_cfgpin(SUNXI_GPG(7), SUN8I_H3_GPG_UART1); + sunxi_gpio_set_pull(SUNXI_GPG(7), SUNXI_GPIO_PULL_UP); +#elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUN8I) && !defined(CONFIG_MACH_SUNXI_H3_H5) sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN8I_GPB_UART2); sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN8I_GPB_UART2); sunxi_gpio_set_pull(SUNXI_GPB(1), SUNXI_GPIO_PULL_UP); +#elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUNXI_H3_H5) + sunxi_gpio_set_cfgpin(SUNXI_GPA(0), SUN8I_H3_GPA_UART2); + sunxi_gpio_set_cfgpin(SUNXI_GPA(1), SUN8I_H3_GPA_UART2); + sunxi_gpio_set_pull(SUNXI_GPA(1), SUNXI_GPIO_PULL_UP); #elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I) sunxi_gpio_set_cfgpin(SUNXI_GPL(2), SUN8I_GPL_R_UART); sunxi_gpio_set_cfgpin(SUNXI_GPL(3), SUN8I_GPL_R_UART); diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 47ea1243..46866c5d 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -255,7 +255,7 @@ extern int soft_i2c_gpio_scl; #else #define OF_STDOUT_PATH "/soc@01c00000/serial@01c28000:115200" #endif -#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I) +#elif CONFIG_CONS_INDEX == 2 && (defined(CONFIG_MACH_SUN5I) || defined(CONFIG_MACH_SUN8I)) #define OF_STDOUT_PATH "/soc@01c00000/serial@01c28400:115200" #elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUN8I) #define OF_STDOUT_PATH "/soc@01c00000/serial@01c28800:115200"
This will make U-Boot output to uart1/uart2, but the Linux kernel has a low level debug output (e.g. to write "uncompressing kernel...") which writes to uart0 and simply freezes if it hasn't been initialized by U-Boot. So you'll need to compile a custom kernel with (Kernel Hacking -> Low Level debug functions) turned off.
Then the linux console can be moved the normal way, using a boot param: e.g. console=ttyS2,115200 -
I'm trying to recompile U-Boot to move the serial console on my OP Zero from uart0 to uart2. I didn't have any trouble to move the linux console, but I'm struggling with U-Boot.
I tried creating a patch to change stdout-path in the device tree: https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts#L65ff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts index d166ffc..0e2e48d 100644 --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts @@ -55,7 +55,7 @@ compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus"; aliases { - serial0 = &uart0; + serial0 = &uart2; /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ ethernet0 = &emac; ethernet1 = &xr819; @@ -178,7 +178,7 @@ &uart2 { pinctrl-names = "default"; pinctrl-0 = <&uart2_pins>; - status = "disabled"; + status = "okay"; }; &usb_otg {I doesn't seem to make a difference if change the alias or stdout-path directly - with the changed tree I get this output on uart0:
U-Boot SPL 2019.04-armbian (Aug 16 2019 - 23:13:41 +0200) DRAM: 512 MiB Trying to boot from MMC1And then it just freezes, with no output on uart2 at all.
Does anyone have an idea where else I should look?
Orange Pi Zero LTS Incorrect Temps Reported
in Orange Pi Zero
Posted
I decompiled sun8i_thermal.ko, not sure what I was expecting...
This is the entirety of their "fix" compared to stock armbian: https://gist.github.com/dbeinder/6c4dac8df91fb4b1b1537bafa8136065/revisions
Yep, that's just a +30C offset shoved straight into the function, couldn't even be bothered with putting it into the struct for H2/H3, never mind chip detection...
> "BREAKING: Our engineer has solved the incorrect temperature Report about Zero LTS boards"
Good job, Xunlong, nice one