Wednesday, 2 August 2017

HI3518 Camera Module - Part 2 - Getting Ethernet Working


This is part 2 of a series of posts involving a cheap camera module based on the HI3518 SoC, which is available on sites such as Aliexpress. In part 1 I described how to build a new Linux OS image for the module to replace the stock version of Linux that comes pre-installed on the module. The post ended with me showing how to boot the new image, but unfortunately on doing so I found that the Ethernet was not working, and this did not appear to be simply down to the need to configure it in the Linux OS.

It turned out that an issue about the Ethernet not working had already been added to the hi35xx/hi35xx-buildroot repository.

The issue appeared to describe the same problem I experienced, particularly the comment made by briaeros, which said:

"The led is barely orange when buildroot is "on" (as if there are not enough power).
On Uboot , it's brightly orange at start, then stay only green. And on the original firmware the two leds are brightly on."

The comments mention that you have to make sure that you have configured the Ethernet driver to either MII or RMII depending on how the Ethernet Phy chip has been connected to the HI3518. It is not possible to tell from looking at the circuit board how the HI3518 has been connected to the Ethernet Phy chip (in the case of the module I have, a IP101GR) so instead I booted in to the original Linux OS and checked the script. From this I determined that the module was using RMII. I then tried setting the CONFIG_HIETH_MII_RMII_MODE_U and CONFIG_HIETH_MII_RMII_MODE_D options in the Linux kernel to 1 (see the Solution section for how) as suggested in the issue. However this did not have any effect.

The comments in the issue also suggested looking at the boot options passed to the Linux kernel by U-Boot. However, this did not helped in getting the Ethernet working.

This post covers the steps I took to get the Ethernet working.


At this point I wasn't sure what to try next, but as mentioned above it was notable that the Ethernet status LEDs looked different when in U-Boot and the original Linux OS when compared to the new Linux OS image. When I watched the LEDs as the system booted the new Linux OS I noticed that they stayed brightly lit until a specific point in the boot sequence, around the time a script called is run. I added some print statements to the and found that the LEDs changed while the script was being run, and specifically while the function net_rmii_mode was being run.

This function is responsible for setting up the pin state for the pins involved in communicating with the Ethernet Phy chip. It turned out the the function was changing the state of one of the pins, which was already configured correctly by U-Boot, to a state that was breaking the Ethernet.

The problem was caused by the muxctrl_reg28 register (0x200f0070) line which sets the function of the EPHY_CLK pin. This pin is responsible for providing a clock to the Phy chip in some setups but was not needed for my module. The original script set the pin to the EPHY_CLK but it only works if it is set to GPIO1_3, since the clock is instead provided by RMII_CLK.

There is more information on the possible configurations for the Ethernet Phy chip, particularly the choice of MII and RMII, in the Hi3518 Hardware Design User Guide. There is currently a version available at the following link:


The solution was to edit the and add it to the filesystem overlay. 

Also, I needed to set the following options to 1 in the Linux config menu:

hieth mii/rmii mode for up port (mii:0/rmii:1)
hieth mii/rmii mode for down port (mii:0/rmii:1)

which can be found under:

Device Drivers -> Network device support -> Ethernet (10 or 100Mbit) -> hieth(switch fabric) family network device support

I have made these changes on top of the changes made in blog post 1. You can check it out using:

git clone -b mark4h-blog-post-2 --depth=1


  1. Replies
    1. I create firmware from you GitHub repo.
      Ethernet work nice !

  2. I have a few questions for you, Sir.

    1. Do you have a plan to develop this firmware for HI3518E devices and do more experiments?

    2. Do you have a desire to try to create a firmware for HI3518E based on OpenWrt or LEDE? How do you feel about this idea? Can I move the development there?

    Thank you !

  3. awesome work! ill give this a try in a month or two when im done moving. having the default backdoors really pisses me off and my pi vpn really doesnt do well trying to pass the streams to a remote location. f'king with sophia settings through CMS is a nightmare when it comes to then trying to get an rstp stream to stay stable in ispy... reduce bandwidth it doesnt connect at all, why are there all the sudden 3 channels showing...etc. hope im not alone in that. its frustrating cause the image is great when it works and the price is awesome! id way rather throw g streamer or motion on it with a custom firmware. I've configured several pi cams in the past and pi cam plus usb webcams. It takes some time but the trouble shooting is way more str8 forward . I need to learn how to keep an sd paired with a pi and i might not have needed the hi3518s on short notice lol

  4. I've wrote something about the Hikam S6 (based on HI3518E):

  5. Thank you for sharing such informative information about Day night Sensor. This is very helpful blog on Day night Sensor. I will come here again for getting more information.