Is Breed Bootloader "author" hackpascal a Mediatek dev?

The Breed bootloader is good for:

  • Re-flashing a new firmware when the firmware or config is messed up
  • Overclocking (works for my MT7621)

I want to try u-boot for my UniElec U7621-06 (256M/16M), but the best repo I can find is this repository, and I don't know what build config parameters are suitable for my device.

My device comes with Breed r777 (git-bb5218f) installed, but it seems that some other users got their devices with u-boot instead. The strange thing is that I cannot find my device's Breed build anywhere, even on hackpascal's homepage.

I sent an email to hackpascal a long time ago, asking whether he developed Breed for this device, and whether he can kindly provide an updated version of Breed, but there is no response from him.

Can someone please explain which one is more dangerous?
Firmware (e.g. sysupgrade bin) from unknown sources?
Or bootloader from unknown sources?

Actually many manufacturers uses breed without my authorization (commercial prohibition). They won't let me know they're using breed for commerical products, and of course I can't tell you which breed is being used by your device.

BTW I don't use gmail frequently.

4 Likes

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

I respect your right to your code. It is your choice to make. You have created something on your own that is useful for many people around the world. That is more than most people accomplish in a lifetime. You should be proud of that.
However, may I please ask:
1.) Why do you choose to keep this code closed source?
2.) How do you view the potential vulnerabilities this creates for millions of people because the code is not available for other developers to review, fork, or improve?

There are always a few people that are capable of fully reverse engineering the binary and finding exploits. With this in mind:
3.) Why do you choose to restrict your code for them to exploit?

EDIT:
LOL. What the heck Mr. Weijie Gao? You're the dev for the UBoot Mediatek stuff! Your name is on everything in the UBoot gitlab. So, I'm running your code or I'm running your code. I've got a lot of options to consider there :slight_smile:

Maybe someone can clue me in here. Why can't I go down the rabbit hole (and make it out the other side) by attempting to compile Uboot from gitlab.denx.de mainline for a MT7621A? (not that it matters: Newifi 3 D2//32MB SPI flash) I have 3 identical routers/jtag/flash tools/linux Fedora/Gentoo, and can etch/fab/solder anything short of jobs requiring a BGA rework station.
I'm about to start compiling Libreboot with my second Gentoo build from stage 1, and would like to try compiling a complete FOSS workstation/network... for sadistic pleasure.
There are a bunch of MT7621 references in uboot-mainline, but there isn't a dts/dtsi file for the soc, and the uboot file structure from 2016/5.x.x.x (5.0.1.0-6 - Padavan) is very different. At first glance it looks like it is not configuration based and instead hard coded.
-Jake

2 Likes

Thanks for the reply.

In my email I have attached the Breed bin extracted from my device. Can you please have a look?

You can also download the bin here:

(It expires after 1 day, so in case you missed it, let me know and I will be happy to send you another link.)

If device manufacturers modify your code without your authorization, are they reverse engineering your code?

Is there anything I can help to have an official version of Breed for UniElec U7621-06 (256M/16M)?
By the way, it is bought from Txxbao.

I would trust the bootloader if it is written by you (@hackpascal), because it will be safer and has a lower chance of bugs.
If the bootloader is modified by unknown people (or the manufacturer without your authorization), I would not trust it.

1 Like

On these MIPS routers, the bootloader extracts and starts linux kernel, after which the entire system runs linux and the bootloader is gone. There isn't any bootloader code running after the kernel is started, thus nothing to exploit. And the device isn't connected to the internet during the bootloader stage so people from the internet can't exploit your bootloader without compromising something else (e.g. your PC or main router firmware). For this reason I'd say bootloader isn't a worthy target to attack in the first place in this case.

Mainline U-boot doesn't support mt7621 at this moment. All the reference you found are added for mt7628, which reuses some hardware blocks from mt7621.

2 Likes

Boot log shows the model is Newifi D1:

Boot and Recovery Environment for Embedded Devices
Copyright (C) 2015 HackPascal <hackpascal@gmail.com>
Build date 2015-10-18 [git-bb5218f]
Version 1.0 (r777)

DRAM: 256MB
Platform: MediaTek MT7621A ver 1, eco 3
Board: Newifi D1
Clocks: CPU: 1000MHz, DDR: 1066MHz, Bus: 333MHz, Ref: 40MHz
Flash: EON EN25F80 (1MB) on rt6855a-spi
rt2880-eth: MAC address from EEPROM is invalid, using default settings.
rt2880-eth: Using MAC address 00:0c:43:00:00:01
eth0: MediaTek MT7530 Gigabit switch

Network started on eth0, inet addr 192.168.1.1, netmask 255.255.255.0

Press any key to interrupt autoboot ... 3
Autoboot aborted due to key press.

Starting breed built-in shell

breed>

File name is breed-mt7621-newifi-d1.bin

However, because I didn't have my early releases archived, I can't tell you whether this file is modified or not. The possibility that breed was modified is very low. If you still mind this, you can try my latest version: https://breed.hackpascal.net/breed-mt7621-newifi-d1.bin

I've read from https://openwrt.org/toh/unielec/u7621-06 and found the UniElec U7621-06 has the same reset button GPIO configuration from Newifi D1, and the only difference is LED GPIO configuration. Normally it's ok to use a breed with the reset btton working.

I have to say that I don't have much time to continue developing breed now. But if you really want a dedicated version of UniElec U7621-06 (with correct LED GPIO, and the correct board name which you can only see from the serial), I'll build one for you.

7 Likes

the only difference is LED GPIO configuration

Is this the reason why the LED of the 2nd LAN port counting from the USB port has a lower brightness?

From my observation, the LEDs on U7621-06 has 2 brightness level. (At least for WiFi)
When the device is booting, the WiFi LED will be at Level 1 (less bright).
When boot is completed, the WiFi LED will be at Level 2 (full brightness).

The LEDs of all other LAN ports are always at full brightness, which is expected, but the 2nd LAN port is an exception, which is always in Level 1. (It does blink when there is activity on that port, however.)

By the way, does the bootloader need to handle any PCIe action (e.g. powering up / initializing the PCIe cards)? Or it only extracts and starts linux kernel, and does not touch PCIe cards?

The U7621-06 has 2 mPCIe ports, and I inserted 2 mPCIe cards. One of them works perfectly, another one seems to have problem (working one is QCA988X (QCA9880 if I remember correctly), bad one is QCA9888). Not sure if this is bootloader's problem though.

Developing breed is just a personal hobbit. I did't force anyone to use it. If you can't accept closed-source software, you can just change to u-boot.

As @981213 said, bootloader isn't a worthy target to attack.
You found mt7621 keywords in mainline u-boot just because some hardware IPs are also used by MT7628.

4 Likes

After power on, all GPIOs are in Input mode. At this time, the GPIOs can be treated as high-impedence, or floating. In this situation, the voltage level of GPIO is unknow, and is likely to be non-zero, and far below than 3V3. But since the voltage is non-zero, there will be current, and the LEDs can be turned on, with less brightness.

Once the bootloader is running, it will set GPIOs of LEDs to Output mode, and there will only be two voltage levels: 0 or 3V3.

So, back to your question, the WiFi LED is controlled by the WiFi chip. Only after the WiFi driver is loaded, the GPIO of WiFi LED can be set to Output mode. That's why the WiFi LED has two brightness during booting.

The switch LEDs are connected directed to the MT7531, and has the default power-on mode as LED, which is appearently Output mode. The less brightness may due to LED or resistor problem.

Normally MT7621 u-boot does nothing for PCI-e. But breed will pull-down and pull-up the reset pin of all three PCI-e slots. This is a workaround trying to solve some WiFi card issue. There are indeed potential risks which may causing other PCI-e cards work abnormally.

1 Like

The less brightness may due to LED or resistor problem.

Okay.

But what happens if the LED GPIO configuration does not match? Does it affect custom LEDs only?

I never used custom LEDs on my device, so basically the only LEDs the device is using are Power LED, Status LED, WiFi LED (x2), and the switch LEDs. It seems that these LEDs work normally.

breed will pull-down and pull-up the reset pin of all three PCI-e slots
There are indeed potential risks which may causing other PCI-e cards work abnormally.

I suspect my Compex QCA9888 is troublesome, because if I insert it in PC, then it will be erroneously reported as device ID 0xabcd. If I insert it in U7621, it enumerates and the device id is correct, but then ath10k can't load the firmware (so the card cannot be used).

Some comments on Kernel Bugzilla say that the card needs to set W_DISABLE# (pin 20), one says the pin can be set via .dts file, but can this be done on U7621? They also mention things like CPU-PCIe-TX and signal polling frame after a PCIe reset...

Edit: Does the serial speed have anything to do with Breed? I remembered this thread some time ago which says that the serial speed is different. Is this because some OpenWrt developers get the board with custom Breed, and some users get the board with U-boot?

But what happens if the LED GPIO configuration does not match? Does it affect custom LEDs only?

Some LEDs may be still in input mode. Although it will not really happen for MT7621, some non-LED GPIOs may be set to wrong direction/level.

Some comments on Kernel Bugzilla say that the card needs to set W_DISABLE# (pin 20), one says the pin can be set via .dts file, but can this be done on U7621?

MT7621 has no control to this pin, and this pin should be tied to 3V3 with a pull-up resistor directly in MT7621's PCB design.

Does the serial speed have anything to do with Breed?

The factory firmware of Newifi D1 uses 115200. Since you're using the dedicated version of Breed for Newifi D1, the serial baudrate of Breed is appearently 115200.

Is this because some OpenWrt developers get the board with custom Breed, and some users get the board with U-boot?

115200 is the most commonly used baudrate. But the offical MTK SDK (with kernel-3.10) uses 57600 instead. The baudrate of the kernel used by U7621-06 seems to be modified to sync with Breed.

2 Likes

@hackpascal I see a file breed-mt76x8-blank.bin on your site - is it suitable for all mt7628 boards? What is the meaning of blank in this case?

I installed the latest Breed version of Newifi D1 and it works fine. The "DDR" and "Bus" values in information page seems a bit off (IIRC it shows something like DDR 1040MHz now), but the board works well anyway.

My last question: the new Breed version has an option to set DDR speed. Is it safe to overclock DDR RAM speed to 1333? (If it fails, will Breed attempt to use the original /default value, just like CPU overclocking?) How much speed improvement can I get if DDR is overclocked?

Thank you very much!

IIRC it shows something like DDR 1040MHz now

1040MHz is the real speed when using 1066MHz settings.

My last question: the new Breed version has an option to set DDR speed. Is it safe to overclock DDR RAM speed to 1333?

Actually there are only four fixed speed options. As you can see the max speed is 1200MHz, and fine tune is impossible due to all DDR initialization sequences are compiled into mt7621_stage_sram.bin which can't be modified.

How much speed improvement can I get if DDR is overclocked?

No significant improvement. The DDR controller would fail with just a slightly higher speed.

(If it fails, will Breed attempt to use the original /default value, just like CPU overclocking?)

Breed will use default settings if you press and hold the reset button and then power on the device.

1 Like

blank means no default GPIO settings (LEDs and buttons).
Normally I release the blank version only if I do not want to develop breed for this chip anymore.

You can set customized reset button with this version.

2 Likes

I was not aware of such an option. How that could be done? Thanks!

This is done by editing the environment variable of Breed.

But first you have to enable the environment variable. This can be done by enabling it in the Web UI, or using a command:

envconf <addr> <size>

You can choose any spare area in the flash. The the size can't be less than 0x100 bytes. The addr is prefered to be at the block boundary.

e.g.:
For mt7628, setting env in nor flash at 0x30000, size 0x1000

envconf 0x30000 0x1000

The environment variable will take effect after a reboot.

Then, you can set the customized reset button by using the following command:

env set gpio.customized.reset <cfg>
env save

The format of cfg is: <gpio_num><active_voltage_level>

e.g.:
If the reset button is GPIO11 active-low:

env set gpio.customized.reset 11L

If the reset button is GPIO21 active-high:

env set gpio.customized.reset 21H
5 Likes

Many thanks, I'll give it a try.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.