No joy. Trying another build, starting from 0xa0000000, stepping by 0x1000.
About ready to take a hammer to the case ... 
Well...Yes it would indicate a specific moment in the boot cycle, if you could figure out what that is... (the moment from green to blue). And that would tell you that the image with the loader is also getting to that same point in boot cycle.
Hey! I was able to compile the Loader to power off or reboot the device if it encounters an error:
diff --git a/target/linux/ramips/image/lzma-loader/src/loader.c b/target/linux/ramips/image/lzma-loader/src/loader.c
index c73b60b351..d72d9b9204 100644
--- a/target/linux/ramips/image/lzma-loader/src/loader.c
+++ b/target/linux/ramips/image/lzma-loader/src/loader.c
@@ -22,13 +22,15 @@
#include <stddef.h>
#include <stdint.h>
#include <sys/types.h>
+#include <unistd.h>
+#include <sys/reboot.h>
#include "config.h"
#include "cache.h"
#include "printf.h"
#include "LzmaDecode.h"
-#define AR71XX_FLASH_START 0x1f000000
+#define AR71XX_FLASH_START 0x10000000
#define AR71XX_FLASH_END 0x1fe00000
#define KSEG0 0x80000000
@@ -86,7 +88,7 @@ static const char *kernel_argv[] = {
static void halt(void)
{
printf("\nSystem halted!\n");
- for(;;);
+ reboot( RB_AUTOBOOT );
}
static __inline__ unsigned long get_be32(void *buf)
@@ -189,6 +191,7 @@ static void lzma_init_data(void)
unsigned char *p;
p = flash_base + flash_ofs;
+ printf("\nchecking address 0x%08x... ", p);
magic = get_be32(p);
if (magic == IH_MAGIC_OKLI) {
hdr = (struct image_header *) p;
Building and uploading them for you: ravpower-wd03.lzma-loader-02.tar.gz
With reboot.bin it should go into bootloop! 
With poweroff.bin it should power off on error!
I hope you could detect at least one of above!
And if the device doesn't responds like previously, then it likely stops in u-boot, after "Starting kernel ..."
## Transferring control to Linux (at address 80000000) ...
## Giving linux memsize in MB, 64
Starting kernel ...
Thanks! I saw this, thought - that's awesome, also a way to confirm it's the loader. I went for the power-off option, as reboot is very difficult to detect (quick flash of light, in a long running test ... needle in a haystack). The results are odd, to say the least - it seems that I'm losing my mind ... LOL!. I ran 3 times, all with the power-off load (again, easier to see it work),
- First run, after something like ~ 15-20 min (wasn't watching it real closely), the blue led changed to green, and I could see that the ethernet was "dead" (no lights on the other end of the link). Seems like power off, perfect. So,
- Next run, just powered off, back on, but started a timer to see how long it took to power off. Well ... it never did. Finally stopped it after ~ 3 hours. Huh?!?!
- Tried one more time, this time re-flashing clean, like the first try above. 50 min in now, still powered up.
What?!?! Seems crazy to me. One time it did power off, but not the other two?
Hmmm ... could the loader twiddle some GPIO lines, make the LED blink slowly perhaps? Just a thought, some sort of indicator that it's still running.
Just took that hammer and wreck that case off! 
Ya, that's about where I'm at - was thinking the same thing ... LOL! I just know that after that it won't be usable any more 
.
This evening it comes off! FYI, heard back from their "tech support". They have no idea what the flash base address is.
1 Like
From the OpenWrt Wiki device page:
The box is made of two parts. Using a screwdriver in one corner, I managed to get leverage to force the box opened. It will leave pretty bad scratches to the enclosure and break some retaining clips inside.
It remains usable, IMHO. 
Yes, for debugging / development - agreed! I meant after it's all working (Openwrt), likely not a usable device for traveling. Broken clips won't work very well
LMAO - way too funny 
I'm good with this, but based on past history - airport security gets just a bit more excited 
I plan to break into it tonight!
Case "modified" ... serial port connected!
1 Like
Wow! Not at all what I expected. Address was fine, loader starts, finds the kernel ... and proceeds to hang decompressing. Huh?!?! Seen that before?
Serial Log 
https://paste.ubuntu.com/p/RbbB6WtcdF/
Oh, and BTW - it will boot my initramfs ... so seems the issue is in the loader decompression, agreed?
Thanks!
Just curious again, what uboot commands are available?
Yes, its related to the the 32 MByte RAM size, we need to tune the LZMA_TEXT_START or something.
There was an error int ath79 which @adrianschmutzler mentioned in the EXT202EXT pull request!
I don't remember this....link?
You are right! It was in a Mikrotik PR!
It was here:
Well, you can just try by increasing LZMA_TEXT_START in here:
https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/image/lzma-loader/Makefile#L11It's currently chosen to work on 32 MB RAM devices, so if you only build for this device you may increase it and have a look (I don't believe this is the issue however, since the decompressing seems to work fine and the starting is the problem.)
E.g. just try 56 MB:
LZMA_TEXT_START := 0x83800000
Related LZMA_TEXT_START commit in ath79:
1 Like
Exactly the same as the HooToo - no delta at all it seems. Do you want a listing of them? And you mean from the command line (i.e. not the full hierarchical menu), right?
I was thinking that was it! Just didn't have any proof 
.
Thanks! Will try to take a look this evening (had to actually go in to the office today, so away from the router now).
Took a look at this one, it makes sense - thanks! And I can see an issue for 32 MB, but also some inconsistencies (I think 
). Two files that seem to play into this, and what I'm trying,
- target/linux/ramips/image/Makefile
@@ -69,7 +69,7 @@ define Build/loader-common
PKG_BUILD_DIR="$@.src" \
TARGET_DIR="$(dir $@)" LOADER_NAME="$(notdir $@)" \
BOARD="$(BOARDNAME)" PLATFORM="$(LOADER_PLATFORM)" \
- LZMA_TEXT_START=0x82000000 LOADADDR=$(KERNEL_LOADADDR) \
+ LZMA_TEXT_START=0x81400000 LOADADDR=$(KERNEL_LOADADDR) \
$(1) compile loader.$(LOADER_TYPE)
mv "$@.$(LOADER_TYPE)" "$@"
rm -rf $@.src
=> I can see this one being an issue for 32 MB, as LZMA_TEXT_START=0x82000000 is at the end of the RAM (right?)
- target/linux/ramips/image/lzma-loader/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
-LZMA_TEXT_START := 0x80a00000
+LZMA_TEXT_START := 0x81400000
LOADER := loader.bin
LOADER_NAME := $(basename $(notdir $(LOADER)))
LOADER_DATA :=
=> Changing them both, to where I think it will be safe (yell if you disagree!), but it is odd ... why are they different (originally). Seems to be a conflict / error, no? Not sure why it's defined 2 different places, and worse yet ... differently in two different places. Also, why not define this in the Device, as it could / needs to be different, depending on the device RAM size, as well as the kernel size ... right?
So I built with my changes, installed and rebooted (get one shot at it, being remote 
). Sadly, I get the issue I have seen a few times now (enough to not just be random). I find that sometimes, when I make changes to the loader (even just adding a printf for debugging!), the boot fails, like captured here https://paste.ubuntu.com/p/NwqBRYh5kZ/. Have you seen this happen?
Thanks!
There is no inconsistency, just some (now unnecessary?) overriding mechanism.
For now, update LZMA_TEXT_START in target/linux/ramips/image/Makefile and leave the other instances alone!
I would try the 24 MB (0x81800000) value, as it was in the referenced commit.
You could try
- greater
pad-tovalue in the recipe, but 64K should be enough, or - exercise the
relocate-kernelas in my DIR-860L mail
2 Likes