Felix Kaechele wrote:
Flávio Silveira wrote:
The offset defined in 10-rt2x00-eeprom is 16384, so I've put:
"ralink,mtd-eeprom = <&devdata 16384>;"
That should work, yes.
I had to add "devdata:" as node name or it wouldn't compile, label is
correct though, is this expected?
According to 617-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch,
it searches both node and label.
https://dev.openwrt.org/browser/trunk/package/mac80211/patches/617-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch?rev=36939
devdata: partition@30000 {
label = "devdata";
reg = <0x30000 0x10000>;
read-only;
};
Here is my full dts file if you want to take a look and comment:
http://codepad.org/ONZdgMZ3
I gave stock boot log in the last e-mail, if you don't mind, can you check
if my dts file definitions makes sense compared to stock?
10-rt2x00-eeprom should become obsolete for most boards as they move
towards defining this information in the DTS. The script is still useful
if more sophisticated means of extracting the firmware is needed.
Good to know, so it's good to update my dts file already, right?
Yeah, makes sense.
4- How do I discover "magic" of this router, to setup it properly in
platform_check_image() in platform.sh?
The magic you need depends on the bootloader. Most Ralink based boards
use u-boot so 0x27051956 would be the correct magic.
Sometimes vendors feel they need to change this. Then you can usually
look at the vendor's original firmware image header.
Do you mean for me to check the first 32 bytes of original
firmware and it should contain 27051956? Is there an offset to look at?
Best case is that the magic is right at offset 0.
It's quite common that vendors modify their images to contain custom
header information (that's why there are so many tools to generate
vendor specific images). This header information is then usually
stripped out by the vendor's firmware update routine. So you might be
lucky to find the uImage magic at some other offset. As always, binwalk
is your friend here.
Worst case is that the image is obfuscated or otherwise encrypted. Then
it is down to reverse engineering the vendor's update mechanism to find
out how they modified that image. That's what we needed to do for the
devices manufactured by Poray (see the mkporayfw tool).
But when decrypted and custom headers stripped it clearly shows the
uImage magic at offset 0.
Here is stock firmware boot log, if it helps: http://codepad.org/stXQWQSQ
This log looks like your board expects a SEAMA image header rather than
uImage. So you're looking at a magic of 0x5ea3a417.
Also, judging from the MAC Adress it's also a D-Link device.
Refer to the DIR-645 on how to use/generate SEAMA images as it has been
done there before.
You were correct, stock firmware has 5ea3a417 on the first bytes, Openwrt
squashfs-factory also have it.
I'm gonna edit upgrade.sh accordingly and I think support is done.
Regards,
Felix
Thanks!
Regards,
Flavio
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
