[LEDE-DEV] [PATCH] ramips: Add support for the Unielec U7621-6

Piotr Dymacz pepe2k at gmail.com
Sun Nov 5 14:55:29 PST 2017


Hello Kristian,

On 05.11.2017 23:26, Kristian Evensen wrote:
> Hi Piotr and Mathias,
> 
> On Sun, Nov 5, 2017 at 10:24 PM, Piotr Dymacz <pepe2k at gmail.com> wrote:
>> Hello Kristian,
>>
>> On 04.11.2017 21:53, Kristian Evensen wrote:
>>>
>>> The Unielec U7621-6
>>>
>>> (http://www.unielecinc.com/q/news/cn/p/product/detail.html?qd_guid=pyrEjfTmYf)
>>> is an MT7621-based router with the following specifications:
>>
>>
>> I got the same board last week and had some initial support ready locally. I
>> pushed it now to my staging tree, please have a look:
>>
>> https://git.lede-project.org/?p=lede/pepe2k/staging.git;a=shortlog;h=refs/heads/ramips_unielec-u7621-06
>>
>> Maybe we can combine our patches and work out a common version.
>> Please, find also my comments below.
> 
> Sure, that sounds great. I will take a look and reply in a separate email.
> 
>> GPIOs 10, 11 and 12 control LEDs 3, 4 and 5 in top row. At least on my
>> board, some of these LEDs were rotated (wrong polarization).
> 
> Ok, then my test was bogus. Thanks for letting me know.
> 
>>
>>> * The device can be delivered with different amounts of RAM and
>>> storage. I have only added support for devices with 256MB RAM and 16MB
>>> storage, as that is the configuration of my device. However, I have
>>> added all the required infrastructure for making adding support for the
>>> other configurations easy.
>>
>>
>> AFAIK, board with 256/16 MB is the default one (mass production?). Any
>> change means MOQ and customized version. The default one can be easily
>> purchased from Ali..., directly from the vendor.
> 
> I agree with Mathias comments in his reply to you. While the default
> sample board has 256/16, based on my discussions with Unielec it seems
> that the other configurations are also easy to get hold of. I think we
> should keep my (minimum) attempt at making it easy to support the
> other configurations.

I'm fully OK with your dtsi+dts approach.

> 
>>
>>> * I have assumed that the placement of wifi cards will be as on the image
>>> on
>>> the Unielec website linked to above.
>>
>>
>> I have problem with this and I don't know how we should proceed here
>> (Mathias, what do you think?).
>>
>> Actually, the board by default comes without any Wi-Fi card installed and
>> they need to be ordered separately (if someone needs them at all).
>>
>> Personally, I don't think we should force any type of card and/or order in
>> slots. The board comes with two miniPCIe slots which can be used for almost
>> anything. I've been testing it with ath9k and mt7603 based cards, a
>> different configuration than yours :)
> 
> I agree and have no problem removing the mt76-part from the pcie node.
> One thing I am unsure of is how to specify the EEPROM offset for mt76
> cards, since the driver reads that from the dts. There seems to be no
> other way to pass configuration data to the driver. However, since
> there are so many potential configurations, perhaps some customization
> has to be required in order to support specific configs.

I think we should first find out if that EEPROM content in factory 
partition is correct. I bet it's some default one they put on every 
board, no matter what they ship it with.

> 
>>
>>> * The factory firmware reads the MAC address from offset e000 on the
>>> factory partition. On my device, this offset contains 0xffs, but I have
>>> chosen to keep the offset in the dts to ensure we are consistent with
>>> the factory firmware.
>>
>>
>> AFAIK, the firmware vendor provides board with doesn't come from them. They
>> installed some version dedicated for PandoraBox PBR-M1.
>>
>> There is also some dedicated Padavan version but I have no idea where it can
>> be downloaded from.
> 
> Yeah, I know. There is a MAC at e006, but that one is the same for my
> two boards at least.
> 
>>
>>>
>>> Installation:
>>>
>>> See Recovery below. The router comes pre-installed with OpenWRT (Pandora
>>> Box), but sysupgrade fails due to board name mismatch.
>>
>>
>> sysupgrade -F ...
> 
> True, but I would argue that using web recovery is quicker than scp +
> ssh. However, explaining both options sounds good to me.
> 
>>
>>>
>>> Recovery:
>>> The U7621-6 supports web recovery. If you keep the reset-button pressed
>>> for ~5 seconds during boot, a webserver is started.Your machine will be
>>> assigned an IP through DHCP, and the router has address 192.168.1.1. The
>>> recovery website is in Chinese, but is easy to use. Click on the second
>>> item in the list to access the recovery page, then the second item on
>>> the next page is where you select the firmware. In order to start the
>>> recovery, you click the button at the bottom.
>>
>>
>> At least on my board, button just stops autobooting process. Web server
>> seems to be enabled in the bootloader all the time - with a static IP on my
>> PC I can access it even during autobooting countdown.
> 
> Yes, that is true, so the text should be rewritten a bit I guess.
> 
>>
>>>
>>> Signed-off-by: Kristian Evensen <kristian.evensen at gmail.com>
>>> ---
>>>   .../linux/ramips/base-files/etc/board.d/02_network |   1 +
>>>   target/linux/ramips/base-files/lib/ramips.sh       |   3 +
>>>   .../ramips/base-files/lib/upgrade/platform.sh      |   1 +
>>>   target/linux/ramips/dts/U7621-6-256M-16M.dts       |  54 ++++++++
>>>   target/linux/ramips/dts/U7621-6.dtsi               | 147
>>> +++++++++++++++++++++
>>>   target/linux/ramips/image/mt7621.mk                |   9 ++
>>>   6 files changed, 215 insertions(+)
>>>   create mode 100644 target/linux/ramips/dts/U7621-6-256M-16M.dts
>>>   create mode 100644 target/linux/ramips/dts/U7621-6.dtsi
>>>
>>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
>>> b/target/linux/ramips/base-files/etc/board.d/02_network
>>> index 1c8505e8c7..8530ca5170 100755
>>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>>> @@ -102,6 +102,7 @@ ramips_setup_interfaces()
>>>         r6220|\
>>>         sap-g3200u3|\
>>>         sk-wb8|\
>>> +       u7621-6-256M-16M|\
>>
>>
>> The board name is U7621-06 (not U7621-6).
>>
>> As the 256/16 MB configuration is (seems to be) the default one, I don't see
>> any reason for a different board name.
>>
>> [snip]
>>
>>> +/dts-v1/;
>>> +
>>> +#include "U7621-6.dtsi"
>>> +
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +#include <dt-bindings/input/input.h>
>>> +
>>> +/ {
>>> +       compatible = "unielec,u7621-6-256m-16m", "unielec,u7621-6",
>>> "mediatek,mt7621-soc";
>>> +       model = "Unielec U7621-6 (256M RAM/16M flash)";
>>
>>
>> According to the vendor website and datasheet, it should be "UniElec
>> U7621-06".
> 
> I have no problem with changing the name, this is only pet peeve of
> mine. I really don't like capitalization inside words :)
> 
>>
>>> +       gpio_export {
>>> +               compatible = "gpio-export";
>>> +               #size-cells = <0>;
>>> +
>>> +               modem_power {
>>> +                   gpio-export,name = "modem_power";
>>
>>
>> This is not a "power" control line. Actually, GPIO16 is connected with
>> PERST# signal in miniPCIe slot (the one for LTE/mSATA). Most of miniPCIe
>> cards (including modems) use this pin for reset (active low).
> 
> Thanks for letting me know, we should find a better name then. Though,
> just out of curiosity, I guess it does the same job?

I selected "modem_reset".

This signal (when pulled low) just keep the card in reset state which 
AFAIK isn't the same as disconnecting it from power. If I remember 
correctly PCIe specification, it's used to indicate that power source 
voltage is stable, in specified range and card can start initialization.

> 
>>
>>
>>> +                   gpio-export,output = <1>;
>>> +                   gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
>>> +               };
>>> +       };
>>> +};
>>> +
>>> +&sdhci {
>>> +       status = "okay";
>>> +
>>> +       pinctrl-names = "default";
>>> +       pinctrl-0 = <&sdhci_pins>;
>>> +};
>>> +
>>> +&spi0 {
>>> +       status = "okay";
>>> +
>>> +       m25p80 at 0 {
>>> +               #address-cells = <1>;
>>> +               #size-cells = <1>;
>>> +               compatible = "jedec,spi-nor";
>>> +               reg = <0>;
>>> +               spi-max-frequency = <10000000>;
>>> +               m25p,chunked-io = <32>;
>>> +
>>> +               partition at 0 {
>>> +                       label = "u-boot";
>>
>>
>> This board doesn't use U-Boot.
>>
>>> +                       reg = <0x0 0x30000>;
>>> +                       read-only;
>>> +               };
>>> +
>>> +               partition at 30000 {
>>> +                       label = "u-boot-env";
>>
>>
>> This partition, at least on my piece, contains some configuration data which
>> looks like from MediaTek SDK based firmware (leftovers?). It's definitely
>> not an U-Boot environment.
> 
> Good point, I just recycled the partition names from the factory firmware.
> 
>>
>>
>>> +                       reg = <0x30000 0x10000>;
>>> +                       read-only;
>>> +               };
>>> +
>>> +               factory: partition at 40000 {
>>> +                       label = "factory";
>>> +                       reg = <0x40000 0x10000>;
>>> +                       read-only;
>>> +               };
>>> +
>>> +               firmware: partition at 50000 {
>>> +                       label = "firmware";
>>> +               };
>>> +       };
>>> +};
>>> +
>>> +&pcie {
>>> +       status = "okay";
>>> +
>>> +       pcie1 {
>>> +               wifi at 14c3,7612 {
>>> +                       compatible = "pci14c3,7612";
>>> +                       reg = <0x0000 0 0 0 0>;
>>> +                       mediatek,mtd-eeprom = <&factory 0x8000>;
>>> +                       ieee80211-freq-limit = <5000000 6000000>;
>>> +               };
>>> +       };
>>> +
>>> +       pcie2 {
>>> +               wifi at 14c3,7602 {
>>> +                       compatible = "pci14c3,7602";
>>> +                       reg = <0x0000 0 0 0 0>;
>>> +                       mediatek,mtd-eeprom = <&factory 0x0000>;
>>> +                       ieee80211-freq-limit = <2400000 2500000>;
>>> +               };
>>> +       };
>>
>>
>> Does your board contains correct eeprom data in factory partition, including
>> MAC addresses? Can you share your factory partition dumps?
> 
> Yes, it seems so, but it seems that they have just deployed the same
> EEPROM on multiple devices. I have another device with same mac
> address for the wifi interfaces. Will send you the dumps.

This doesn't sound correct for me then.

> 
>>
>>> +};
>>> +
>>> +&ethernet {
>>> +       mtd-mac-address = <&factory 0xe000>;
>>
>>
>> My board has a a MAC address at 0xe006.
> 
> Yes, mine too. However, I have two boards and they both have the same
> value stored at this offset (7c:3e:9d:1d:7a:2c).

And mine also has the same MAC address :)

-- 
Cheers,
Piotr



More information about the Lede-dev mailing list