Building Openwrt for Huawei HG8145V

Hi everyone,

I am working on porting OpenWrt to a legacy Huawei HG8145V (Board Silkscreen: HG8245A ver 2, SoC: HiSilicon SD5116). I have obtained root shell access via the Dopra Linux environment and am now attempting a full conversion. I recently bricked the KernelA partition and am currently seeking the UART pinout for recovery.
Current System State (Dopra Linux)
Plaintext
`WAP(Dopra Linux) # df -h

Filesystem Size Used Available Use% Mounted on
/dev/root 24.4M 24.4M 0 100% /
tmpfs 119.6M 0 119.6M 0% /dev
tmpfs 512.0M 4.0K 512.0M 0% /dev/shm
none 10.0M 0 10.0M 0% /tmp
none 512.0M 420.0K 511.6M 0% /var
none 4.0K 0 4.0K 0% /mnt
none 16.0M 4.0K 16.0M 0% /var/osgi
none 30.0M 0 30.0M 0% /var/felix-temp
none 2.0M 0 2.0M 0% /tmp/QoE
/dev/ubi0_13 16.7M 8.8M 7.9M 53% /mnt/jffs2 WAP(Dopra`

`MTD Partition Table (/proc/mtd)
WAP(Dopra Linux) # cat /proc/mtd

dev: size erasesize name
mtd0: 00100000 00020000 "startcode"
mtd1: 07f00000 00020000 "ubifs"
mtd2: 00000000 00000000 "reserved"
mtd3: 0009b000 0001f000 "ubootA"
mtd4: 0009b000 0001f000 "ubootB"
mtd5: 0003e000 0001f000 "flash_configA"
mtd6: 0003e000 0001f000 "flash_configB"
mtd7: 0003e000 0001f000 "slave_paramA"
mtd8: 0003e000 0001f000 "slave_paramB"
mtd9: 00307000 0001f000 "kernelA"
mtd10: 00307000 0001f000 "kernelB"
mtd11: 01c18000 0001f000 "rootfsA"
mtd12: 01c18000 0001f000 "rootfsB"
mtd13: 0003e000 0001f000 "wifi_paramA"
mtd14: 0003e000 0001f000 "wifi_paramB"
mtd15: 0003e000 0001f000 "system_param"
mtd16: 0141a000 0001f000 "file_system"`
U-Boot Analysis (Extracted Strings from /dev/mtd3)
I managed to run strings via a busybox binary on /dev/mtd3. Key bootloader parameters found:
Boot Command Logic: ubi read 0x%x %s 0x%x; bootm 0x%x 0x%x
Recovery Logic: Main area (A) is not OK! Reboot! and Main area (B) is not OK! Reboot!
Default Bootargs: mem=120M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=cramfs mtdparts=hi_sfc:1M(boot),2M(kernel),7M(rootfs),-(conf)
Tools found: loaduboot , tftpboot, rarpboot.
Kernel/Process Info
The system runs several proprietary Huawei services (ssmp, omci, clid, mu).
Kernel Command Line: noalign mem=247M flashsize=0x8000000 console=ttyAMA1,115200 ubi.mtd=1 root=/dev/mtdblock11 rootfstype=squashfs mtdparts=hinand:0x100000(startcode),0x7f00000(ubifs),-(reserved) pcie0_sel=x1 maxcpus=2 l2_cache=l2x0 coherent_pool=4M flash_control=nfc user_debug=0x1f panic=1 skb_priv=128 debug_ll=on
The GoalUART Pinout: I need to identify the serial header for this "ver 2" board (photos attached) to interrupt the boot and force KernelB.
OpenWrt Port: I previously tried running an OpenWrt rootfs in a chroot environment via tmpfs. The shell worked, but LuCI failed (error photo attached).
Storage: I want to eventually merge the A/B structure into a single ubifs on mtd1 to allow enough space for AdGuard Home.
Some more things here

/mnt/jffs2/busybox strings /dev/mtd3 | grep boot
bootfile
*** Warning: no boot file name; using '%s'
bootargs
ERROR: booting os '%s' (%d) is not supported
bootm
boot application image from memory
- boot application image stored in memory
passing arguments 'arg ...'; when booting a Linux kernel,
Sub-commands to do part of the bootm sequence. The sub-commands must be
'mtdids' - linux kernel mtd device id <-> u-boot device id mapping
Automatic boot of image at addr 0x%08lx ...
bootdevice
** No boot device **
nboot
boot from NAND device
Automatic boot of image at addr 0x%08lX ...
[0;31m flash check is error,before load the uboot please do not reset !

Any advice on the UART location or a compatible OpenWrt subtarget for the SD5116 would be appreciated.

Usually isn't supported by Linux, this is most likely a dead end.

1 Like

You'll likely want to just get an oscilloscope to have a look at the footprints that I've highlighted on the image.

I'd probably start with what looks like an RJ11 connector towards the bottom of the image. I assume the already populated RJ11 didn't have any signals of interest on it when you checked?
It should be easy to identify if there is a ground pin (since it'll be the one with the traces to the local ground plane).

1 would be a second FXS (analogue phone) connector, my bets would be on 2. The HiSilicon stuff will probably throw a spanner into the works though.

1 Like

The HiSilicon SD5116 is just an ARM Cortex-A9, so the CPU itself is supported.
It would be a pretty large amount of work if having to sort out the clock registers, and everything else from scratch however...

But there is 'some' support for various HiSilicon things in mainline (which might not apply to the SD5116 albeit)

I don't disagree that it's likely a better idea to just find a more supported device.
But if everyone took the easier option, we'd not have the wide range of currently supported devices at all...

@Naitik06
With Root Shell, if you can get devmem access that would very much help.. that would let you read / write current memory/IO values.
You'll likely also want to get a dump of the firmware that you're running, and try to push it through Ghidra or similar, then try to identify how it's setting up the clocks, memory, console, and flash access... then into the networking stuff..

guys I already mentioned the kernel was accidentally erased kernel_A only kernel_B is perfectly fine.
Issue here is it is not switching to B part so I am unable to boot currently.
I have my exams currently so just holding this stuff for work and just recieving suggestions for work I have to do after my exams
All kind of help is appreciated

@slh there is a 5th one too near the blue capacitor see another set of 4 pins not visible good in image here at bottom right side below reset key above power jack

My guess is/ remains 2, but that's not a guarantee - no way around measuring voltages, inspecting the traces going towards that pin header - and then just trying.

1 Like

@bevanweiss You are right
Actually I saw a thread for HG8245H
I am confused firmware at some places mentions HG8245H