[U-Boot] U-Boot 2018.07 Still Broken for Allwinner H3 SoCs
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
See log:
U-Boot SPL 2018.07 (Jul 10 2018 - 10:21:03 +0800) DRAM: 1024 MiB Trying to boot from MMC1
U-Boot 2018.07 (Jul 10 2018 - 10:21:03 +0800) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680) Model: Libre Computer Board ALL-H3-CC H3 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... Unable to use mmc 0:1... Failed (-5) In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) 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 385 bytes read in 8 ms (46.9 KiB/s) ## Executing script at 43100000 6343768 bytes read in 295 ms (20.5 MiB/s) 18710 bytes read in 10 ms (1.8 MiB/s) ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. EHCI failed to shut down host controller. EHCI failed to shut down host controller. Loading Device Tree to 49ff8000, end 49fff915 ... OK
Starting kernel ...
data abort pc : [<7dfadc6c>] lr : [<7df82ed7>] reloc pc : [<4a02bc6c>] lr : [<4a000ed7>] sp : 79f5ce90 ip : 79f62b8a fp : 00000003 r10: 7dfc3d14 r9 : 79f61ed8 r8 : 00000400 r7 : 00000000 r6 : 42000000 r5 : 49ff8000 r4 : 00000000 r3 : 49ff8000 r2 : 49ff8000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode UK6_32 Code: e12fff1e e52de008 fa000001 e3a00000 (e49df008) Resetting CPU ...
resetting ...
On Tue, Jul 10, 2018 at 8:34 AM, Chen-Yu Tsai wens@csie.org wrote:
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
I'm able to boot with BPI-M2+, where I changed the configurations based on Libre Computer board. - remove/disable ehci0, ohci0 - enable ehci1, 2, 3 and ohci1, 2, 3 - remove/disable usb_otg node - disable MUSB_GADGET
Here is the log: U-Boot 2018.07-00008-g9b89c61c72-dirty (Jul 10 2018 - 11:37:46 +0530) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680) Model: Banana Pi BPI-M2-Plus DRAM: 1 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from FAT... Unable to use mmc 1:3... Failed (-5) In: serial Out: serial Err: serial Net: No ethernet found. starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 155 bytes read in 3 ms (49.8 KiB/s) 1: linux-4.17.0-rc3 Retrieving file: /zImage 3817968 bytes read in 175 ms (20.8 MiB/s) append: console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait Retrieving file: /sun8i-h3-bananapi-m2-plus.dtb 15691 bytes read in 4 ms (3.7 MiB/s) ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. EHCI failed to shut down host controller. EHCI failed to shut down host controller. Loading Device Tree to 49ff9000, end 49fffd4a ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc6-00415-g2f2b41a952de (jagan@jagan-XPS-13-9350) (gcc version 6.3.1 20170109 (Linaro GCC 6.3-2017.02)) #1 S8 [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
On Tue, Jul 10, 2018 at 2:13 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On Tue, Jul 10, 2018 at 8:34 AM, Chen-Yu Tsai wens@csie.org wrote:
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
I'm able to boot with BPI-M2+, where I changed the configurations based on Libre Computer board.
- remove/disable ehci0, ohci0
- enable ehci1, 2, 3 and ohci1, 2, 3
- remove/disable usb_otg node
- disable MUSB_GADGET
On BPI-M2+, with Sinovoip_BPI_M2_Plus_defconfig, cross-compiled using gcc version 7.3.0 (Debian 7.3.0-20)
U-Boot SPL 2018.07 (Jul 11 2018 - 10:32:26 +0800) DRAM: 1024 MiB Trying to boot from MMC2
U-Boot 2018.07 (Jul 11 2018 - 10:32:26 +0800) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680) Model: Banana Pi BPI-M2-Plus DRAM: 1 GiB
MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from FAT... Unable to use mmc 1:1... Failed (-5) In: serial Out: serial Err: serial Allwinner mUSB OTG (Peripheral) Net: phy interface7 eth0: ethernet@1c30000 Warning: usb_ether using MAC address from ROM , eth1: usb_ether starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 494 bytes read in 4 ms (120.1 KiB/s) ## Executing script at 43100000 5847064 bytes read in 268 ms (20.8 MiB/s) 16209 bytes read in 5 ms (3.1 MiB/s) ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. EHCI failed to shut down host controller. Loading Device Tree to 49ff9000, end 49ffff50 ... OK
Starting kernel ...
data abort pc : [<3f600018>] lr : [<7df79ed7>] reloc pc : [<0b687018>] lr : [<4a000ed7>] sp : 79f53658 ip : 79f59c82 fp : 00000400 r10: 7dfc2d70 r9 : 79f58ed8 r8 : 79fb2ca8 r7 : 00000000 r6 : 42000000 r5 : 49ff9000 r4 : 00000000 r3 : 00000006 r2 : 49ff9000 r1 : 00000006 r0 : 00000006 Flags: nzcv IRQs off FIQs off Mode UK6_32 Code: 00012003 00013003 00014003 00015003 (00016003) Resetting CPU ...
resetting ...
That PC looks really weird.
ChenYu
Here is the log: U-Boot 2018.07-00008-g9b89c61c72-dirty (Jul 10 2018 - 11:37:46 +0530) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680) Model: Banana Pi BPI-M2-Plus DRAM: 1 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from FAT... Unable to use mmc 1:3... Failed (-5) In: serial Out: serial Err: serial Net: No ethernet found. starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 155 bytes read in 3 ms (49.8 KiB/s) 1: linux-4.17.0-rc3 Retrieving file: /zImage 3817968 bytes read in 175 ms (20.8 MiB/s) append: console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait Retrieving file: /sun8i-h3-bananapi-m2-plus.dtb 15691 bytes read in 4 ms (3.7 MiB/s) ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. EHCI failed to shut down host controller. EHCI failed to shut down host controller. Loading Device Tree to 49ff9000, end 49fffd4a ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc6-00415-g2f2b41a952de (jagan@jagan-XPS-13-9350) (gcc version 6.3.1 20170109 (Linaro GCC 6.3-2017.02)) #1 S8 [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
On Wed, Jul 11, 2018 at 11:53 AM, Chen-Yu Tsai wens@csie.org wrote:
On Tue, Jul 10, 2018 at 2:13 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On Tue, Jul 10, 2018 at 8:34 AM, Chen-Yu Tsai wens@csie.org wrote:
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
I'm able to boot with BPI-M2+, where I changed the configurations based on Libre Computer board.
- remove/disable ehci0, ohci0
- enable ehci1, 2, 3 and ohci1, 2, 3
- remove/disable usb_otg node
- disable MUSB_GADGET
On BPI-M2+, with Sinovoip_BPI_M2_Plus_defconfig, cross-compiled using gcc version 7.3.0 (Debian 7.3.0-20)
OK. I dropped back to GCC 6.4.1 from Linaro's 2017.11 release. It now works. Will try Linaro's other toolchains later.
ChenYu
On Wed, Jul 11, 2018 at 12:28 PM, Chen-Yu Tsai wens@csie.org wrote:
On Wed, Jul 11, 2018 at 11:53 AM, Chen-Yu Tsai wens@csie.org wrote:
On Tue, Jul 10, 2018 at 2:13 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On Tue, Jul 10, 2018 at 8:34 AM, Chen-Yu Tsai wens@csie.org wrote:
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
I'm able to boot with BPI-M2+, where I changed the configurations based on Libre Computer board.
- remove/disable ehci0, ohci0
- enable ehci1, 2, 3 and ohci1, 2, 3
- remove/disable usb_otg node
- disable MUSB_GADGET
On BPI-M2+, with Sinovoip_BPI_M2_Plus_defconfig, cross-compiled using gcc version 7.3.0 (Debian 7.3.0-20)
OK. I dropped back to GCC 6.4.1 from Linaro's 2017.11 release. It now works. Will try Linaro's other toolchains later.
OK, I used Linaro GCC 6.3-2017.02
On Tue, Jul 10, 2018 at 4:04 AM, Chen-Yu Tsai wens@csie.org wrote:
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
I'm still seeing this issue in 2018.09 RC1, what's the status of a fix for this?
See log:
U-Boot SPL 2018.07 (Jul 10 2018 - 10:21:03 +0800) DRAM: 1024 MiB Trying to boot from MMC1
U-Boot 2018.07 (Jul 10 2018 - 10:21:03 +0800) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680) Model: Libre Computer Board ALL-H3-CC H3 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... Unable to use mmc 0:1... Failed (-5) In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) 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 385 bytes read in 8 ms (46.9 KiB/s) ## Executing script at 43100000 6343768 bytes read in 295 ms (20.5 MiB/s) 18710 bytes read in 10 ms (1.8 MiB/s) ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. EHCI failed to shut down host controller. EHCI failed to shut down host controller. Loading Device Tree to 49ff8000, end 49fff915 ... OK
Starting kernel ...
data abort pc : [<7dfadc6c>] lr : [<7df82ed7>] reloc pc : [<4a02bc6c>] lr : [<4a000ed7>] sp : 79f5ce90 ip : 79f62b8a fp : 00000003 r10: 7dfc3d14 r9 : 79f61ed8 r8 : 00000400 r7 : 00000000 r6 : 42000000 r5 : 49ff8000 r4 : 00000000 r3 : 49ff8000 r2 : 49ff8000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode UK6_32 Code: e12fff1e e52de008 fa000001 e3a00000 (e49df008) Resetting CPU ...
resetting ... _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi,
On Wed, Aug 1, 2018 at 9:22 PM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jul 10, 2018 at 4:04 AM, Chen-Yu Tsai wens@csie.org wrote:
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
I'm still seeing this issue in 2018.09 RC1, what's the status of a fix for this?
This is a bug in binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=23571 It has been fixed upstream.
See log:
U-Boot SPL 2018.07 (Jul 10 2018 - 10:21:03 +0800) DRAM: 1024 MiB Trying to boot from MMC1
U-Boot 2018.07 (Jul 10 2018 - 10:21:03 +0800) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680) Model: Libre Computer Board ALL-H3-CC H3 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... Unable to use mmc 0:1... Failed (-5) In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) 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 385 bytes read in 8 ms (46.9 KiB/s) ## Executing script at 43100000 6343768 bytes read in 295 ms (20.5 MiB/s) 18710 bytes read in 10 ms (1.8 MiB/s) ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. EHCI failed to shut down host controller. EHCI failed to shut down host controller. Loading Device Tree to 49ff8000, end 49fff915 ... OK
Starting kernel ...
data abort pc : [<7dfadc6c>] lr : [<7df82ed7>] reloc pc : [<4a02bc6c>] lr : [<4a000ed7>] sp : 79f5ce90 ip : 79f62b8a fp : 00000003 r10: 7dfc3d14 r9 : 79f61ed8 r8 : 00000400 r7 : 00000000 r6 : 42000000 r5 : 49ff8000 r4 : 00000000 r3 : 49ff8000 r2 : 49ff8000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode UK6_32 Code: e12fff1e e52de008 fa000001 e3a00000 (e49df008) Resetting CPU ...
resetting ... _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Tue, Jul 10, 2018 at 4:04 AM, Chen-Yu Tsai wens@csie.org wrote:
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
I'm still seeing this issue in 2018.09 RC1, what's the status of a fix for this?
This is a bug in binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=23571 It has been fixed upstream.
For reference the Fedora binutils maintainer (and also one of the upstream developers made the following note about the fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1624751#c3 --- It should also be noted that this problem can be avoided in the U-Boot linker script if the align expression is put on the left of the colon. Like this:
.__secure_start #ifndef CONFIG_ARMV7_SECURE_BASE ALIGN(CONSTANT(COMMONPAGESIZE)) #endif : { KEEP(*(.__secure_start)) }
This has the advantage that the solution will work with older versions of the binutils package. ---
So you may wish to fix it like that so it's not dependent on versions of binutils.
Peter
On Tue, Sep 4, 2018 at 8:22 PM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jul 10, 2018 at 4:04 AM, Chen-Yu Tsai wens@csie.org wrote:
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
I'm still seeing this issue in 2018.09 RC1, what's the status of a fix for this?
This is a bug in binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=23571 It has been fixed upstream.
For reference the Fedora binutils maintainer (and also one of the upstream developers made the following note about the fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1624751#c3
It should also be noted that this problem can be avoided in the U-Boot linker script if the align expression is put on the left of the colon. Like this:
.__secure_start#ifndef CONFIG_ARMV7_SECURE_BASE ALIGN(CONSTANT(COMMONPAGESIZE)) #endif : { KEEP(*(.__secure_start)) }
This has the advantage that the solution will work with older versions of the binutils package.
Thanks. Apparently ALIGN and other commands should come before the colon. I suppose the linker just ignores commands in incorrect places, or just tries its best to comply. Anyway, I'm the one that got it wrong the first time around.
So you may wish to fix it like that so it's not dependent on versions of binutils.
Will do.
ChenYu
On Wed, Sep 5, 2018 at 11:23 AM Chen-Yu Tsai wens@csie.org wrote:
On Tue, Sep 4, 2018 at 8:22 PM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jul 10, 2018 at 4:04 AM, Chen-Yu Tsai wens@csie.org wrote:
This is on a Libre Computer ALL-H3-CC H3 variant. Still running a bisect, but v2018.07-rc1 is a working version. From the EHCI error messages, I'm thinking it might be related to the USB changes lately. Not sure if any other SoCs (ex. A64) are broken or not at the moment.
I'm still seeing this issue in 2018.09 RC1, what's the status of a fix for this?
This is a bug in binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=23571 It has been fixed upstream.
For reference the Fedora binutils maintainer (and also one of the upstream developers made the following note about the fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1624751#c3
It should also be noted that this problem can be avoided in the U-Boot linker script if the align expression is put on the left of the colon. Like this:
.__secure_start#ifndef CONFIG_ARMV7_SECURE_BASE ALIGN(CONSTANT(COMMONPAGESIZE)) #endif : { KEEP(*(.__secure_start)) }
This has the advantage that the solution will work with older versions of the binutils package.
Thanks. Apparently ALIGN and other commands should come before the colon. I suppose the linker just ignores commands in incorrect places, or just tries its best to comply. Anyway, I'm the one that got it wrong the first time around.
According to the ld documents, ALIGN before the colon is an expression specifying an address for the section [1], while ALIGN after the colon is a section attribute for a forced alignment [2].
A third way to accomplish our goal, have the __secure_start symbol within the .__secure_start section aligned, is to have
. = ALIGN(CONSTANT(COMMONPAGESIZE));
before
KEEP(*(.__secure_start))
This is used to align the __secure_stack_end symbol [3].
All these methods accomplish the goal, but have subtle differences. In particular, the third method aligns the symbols themselves, but not the start of the section.
ChenYu
[1] https://sourceware.org/binutils/docs-2.31/ld/Output-Section-Address.html [2] https://sourceware.org/binutils/docs-2.31/ld/Output-Section-Attributes.html [3] https://elixir.bootlin.com/u-boot/latest/source/arch/arm/cpu/u-boot.lds#L91
So you may wish to fix it like that so it's not dependent on versions of binutils.
Will do.
ChenYu
participants (3)
-
Chen-Yu Tsai -
Jagan Teki -
Peter Robinson