[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.
>
>>
>>> +};
>>> +
>>> +ðernet {
>>> + 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