OpenWrt Forum Archive

Topic: RE: new device on RT5350 SoC

The content of this topic has been archived on 21 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Since I haven't received any reply in my old topic (forum.openwrt org/viewtopic.php?pid=348937 )  I thought I start here.

The issues I'm having so far:
- cannot break uboot default
- can't figure out GPIOs (maybe some of them are hardcoded), only found out about the red LED and the reset button
- the default image has 5 mtd blocks, not sure if I'm declaring them correctly, see below
- can't figure out how to load to SDRAM for testing since I cannot boot to uboot. Is there any way to do this from the normal boot environment?
- recommended naming conventions for new devices?

What was achieved so far:
- identified flash chip and added declaration into the DTS file
- dumped mtdblock 0 through 5
- know where the blocks above are situated in the SPI flash
- have the kernel config file from the factory firmware
- I think I know what devices and modules need to be included
- can flash individual blocks from factory firmware (mtdwrite)

# cat /proc/cpuinfo
system type             : Ralink SoC
processor               : 0
cpu model               : MIPS 24Kc V4.12
BogoMIPS                : 239.61
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0004, 0x0ec4, 0x0ff8, 0x0803]
ASEs implemented        : mips16 dsp
shadow register sets    : 1
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00800000 00010000 "ALL"
mtd1: 00030000 00010000 "Bootloader"
mtd2: 00010000 00010000 "Config"
mtd3: 00010000 00010000 "Factory"
mtd4: 001c0000 00010000 "MiniSystem"
mtd5: 005f0000 00010000 "Kernel"


Normal boot:

## Booting image at bc210000 ...
raspi_read: from:210000 len:40 
.   Image Name:   Linux Kernel Image
   Created:      2013-09-09   8:53:17 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    6025942 Bytes =  5.7 MB
   Load Address: 80000000
   Entry Point:  8000c310
raspi_read: from:210040 len:5bf2d6 

Minisystem (failsafe) boot:

## Booting image at bc050000 ...
raspi_read: from:50000 len:40
.   Image Name:   Linux Kernel Image
   Created:      2013-03-11   6:20:33 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1649876 Bytes =  1.6 MB
   Load Address: 80000000
   Entry Point:  8000c310
raspi_read: from:50040 len:192cd4

Snippet from my dts file:

&spi0 {
    status = "okay";

    en25q64@0 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "jedec,spi-nor";
        reg = <0>;
        linux,modalias = "m25p80", "en25q64";
        spi-max-frequency = <10000000>;

        partition@0 {
            label = "u-boot";
            reg = <0x0 0x30000>;
            read-only;
        };

        partition@30000 {
            label = "u-boot-env";
            reg = <0x30000 0x1000>;
            read-only;
        };

        partition@31000 {
            label = "config";
            reg = <0x31000 0xf000>;
            read-only;
        };

        factory: partition@40000 {
            label = "factory";
            reg = <0x40000 0x10000>;
            read-only;
        };

        partition@50000 {
            label = "firmware";
            reg = <0x50000 0x7b0000>;
        };
    };
};

Do I need the u-boot-env partition?
Factory is the same as minisystem?

Edit: it seems that uboot-env is also used in the original firmware, or at least I assume so:

U-Boot 1.1.3 (Apr 19 2013 - 00:35:05)
Board: Ralink APSoC DRAM:  64 MB
relocate_code Pointer at: 83fb4000
spi_wait_nsec: 42 
spi device id: 1c 30 17 1c 30 (30171c30)
find flash: EN25Q64
raspi_read: from:30000 len:1000 
.*** Warning - bad CRC, using default environment

============================================ 
Ralink UBoot Version: 4.0.1.0

I have no idea why there are 2 config partitions (64kb each). The first one seems to store router settings while the second one is for WiFi register definitions? It only uses the first 0x12b (299) bytes.

I'm not looking for someone to solve the problems for me, just hints.

(Last edited by brainwash on 11 Jan 2017, 10:04)

I cannot post links, that's why I removed the dot.

Meanwhile I've corrected the flash layout.

        partition@0 {
            label = "u-boot";
            reg = <0x0 0x30000>;
            read-only;
        };

        partition@30000 {
            label = "u-boot-env";
            reg = <0x30000 0x10000>;
            read-only;
        };

        factory: partition@40000 {
            label = "factory";
            reg = <0x40000 0x10000>;
            read-only;
        };

        partition@50000 {
            label = "recover";
            reg = <0x50000 0x1c0000>;
        };

        partition@210000 {
            label = "firmware";
            reg = <0x210000 0x5f0000>;
        };

Managed to deploy a bootable image to mtd5 while keeping the mtd4 (minisystem/recovery) intact.

Does the *squashfs-sysupgrade.bin image contain any extra data like bootloader? Should I use something else for the firmware partition?

How do I specify the maximum size when building? I only have 6225920 bytes available.

The gadget is a travel router that does not have an ethernet connection and the wifi is disabled by default by openwrt. How do I enable this in the build configuration?

(Last edited by brainwash on 11 Jan 2017, 16:19)

Well, the image is up, some changes were required:
- the wifi connection led has been autodetected, I only had to add the custom red to the configuration
- the reset button is working, at least it reboots, I haven't tried to re-assign it
- the ram memory had to be updated in kernel hacks to mem=64M, it only detected 32M
+ other stuff

The questions above still remain.

Also the router loses its configuration on every boot, but I don't want to risk flashing a full image until I know everything works.

Is there a way to mount EFI filesystems? The original firmware was able to detect those. I'm testing with a bootable MacOS stick. Perhaps there is a way kernel mod or package that I'm missing.

Thank you. Is there any way that I can make this device specific instead of altering the file one time? If I want to push these changes later the device is unusable without a WiFi connection, other users would need to open it up and connect to serial.

you are changing this in buildroot, not on device. once flashed and booted wifi will auto-start.

Sorry, I was looking at the post above that mentioned altering the source dir.
So instead I should make changes into this folder: /target/linux/ramips/base-files/etc
Is it better to modify ./board.d/02_network or add a new file into ./uci-defaults? Is there some example I can follow where someone has had the same problem? I think the Zsun Card reader is similar in this regard.

read again. carefully. mac80211.sh

But this will not persist if anyone else wants to build the firmware by themselves and will essentially 'soft-brick' the router for them.

Ok, most of the issues have been solved, see below. Will try to push upstream once everything is a user-friendly condition.

brainwash wrote:

- cannot break uboot default

This is still up. I could try rewriting uboot but too chicken to do that.

brainwash wrote:

- can't figure out GPIOs (maybe some of them are hardcoded), only found out about the red LED and the reset button

Maybe the other ones are hardcoded, it's still ok that these ones work.

brainwash wrote:

- the default image has 5 mtd blocks, not sure if I'm declaring them correctly, see below

Solved

brainwash wrote:

- can't figure out how to load to SDRAM for testing since I cannot boot to uboot. Is there any way to do this from the normal boot environment?

Not required anymore.

brainwash wrote:

- recommended naming conventions for new devices?

I need to check if my sysupgrade image can be flashed on the original firmware. This might require renaming of the board name. But it seems everyone just chooses a mostly random convention.

brainwash wrote:

Does the *squashfs-sysupgrade.bin image contain any extra data like bootloader? Should I use something else for the firmware partition?

It does not contain nor overwrite the bootloader. At least as far as I can see.

brainwash wrote:

Also the router loses its configuration on every boot, but I don't want to risk flashing a full image until I know everything works.

This was because the sysimage needs to be flashed. Flashing directly to mtd does not allow saving. OpenWRT stores the configuration files in the same partition as the firmware image, in the free space remaining. Not sure how this can be overridden.

brainwash wrote:

Is there a way to mount EFI filesystems? The original firmware was able to detect those. I'm testing with a bootable MacOS stick. Perhaps there is a way kernel mod or package that I'm missing.

Requires the XFS file system kernel mod.

Still open: how to create board-specific configuration files in a nicer way. Since this is not a full-fledged router, a lot of the openwrt default assumptions do not apply. Or are people just publishing the configuration files but a custom-built binary?

I managed to get a working build (about a month ago) but I don't know what the procedure for pushing the changes upstream is.

The device in question is an I.Onik WiFi Cloud Hub, basically a travel router primarily geared towards sharing media files from USB or SD via WiFi

Did a 'quick' write-up here: http://hackcorrelation.blogspot.de/2017 … d-hub.html

The discussion might have continued from here.