Well, I got the new HornetUB2.
The instructions for flashing on the wiki aren't working. (http://wiki.openwrt.org/toh/alfa.network/hornet-ub?s[]=hornet)
I'm trying to dissect why certain memory ranges are chosen to correctly adjust them for this newer board.
So first we see
tftp 0xa0800000 openwrt-ar71xx-generic-hornet-ub-jffs2-sysupgrade.bin0xa0800000 seems to be just blank space suitable for temporary storage. This address is notably different from the one describe on ALFA's instructions: http://www.alfa.com.tw/press_c_show.php?sn=4
tftp 0x80600000 kernel.binNow I've had ALFAs instructions work on the 8MB/32MB version, but I've never tried OpenWRT's method with the sysupgrade file.
Anyways, the conclusion I've reached, assuming OpenWRTs instructions are correct, is that it's just extra space and not a big deal. OpenWRT is just further along the memory pool.
So, we first copy the firmware to a temporary place, is the address at 0xa0800000 going to be far enough in the memory pool to avoid overwriting necessary files? I don't know! I can't figure out how they even chose that address to begin with besides just choosing one far enough away from the flash to enter the ram. So lets think here, assuming it starts at 0x0, that address is 2692743168 bytes away from the start. That works out to exactly 2568MB...um...no...something is wrong here.
Ok so maybe it's in bits and not bytes, leaves us at 321MB, nope...
Soooo, OK, maybe we don't start with 0x0? Let's look at the 8MB U-Boot output:
U-Boot 1.1.4-g971cc15e-dirty (Sep 7 2011 - 11:44:55)
AP121-8MB (ar9331) U-boot
DRAM: 32 MB
Top of RAM usable for U-Boot at: 82000000
Reserving 248k for U-Boot at: 81fc0000
Reserving 192k for malloc() at: 81f90000
Reserving 44 Bytes for Board Info at: 81f8ffd4
Reserving 36 Bytes for Global Data at: 81f8ffb0
Reserving 128k for boot params() at: 81f6ffb0
Stack Pointer at: 81f6ff98
Now running in RAM - U-Boot at: 81fc0000
id read 0x100000ff
flash size 8388608, sector count = 128
Flash: 8 MB
In: serial
Out: serial
Err: serial
Net: ag7240_enet_initialize...
No valid address in Flash. Using fixed address
No valid address in Flash. Using fixed address
: cfg1 0x5 cfg2 0x7114
eth0: 00:03:7f:09:0b:ad
eth0 up
: cfg1 0xf cfg2 0x7214
eth1: 00:03:7f:09:0b:ad
athrs26_reg_init_lan
ATHRS26: resetting s26
ATHRS26: s26 reset done
eth1 up
eth0, eth1
Please choose the operation:
1: Entr boot command line interface.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default). 0
System Boot system code via Flash.
## Booting image at 9f650000 ...
Image Name: MIPS OpenWrt Linux-3.10.49
Created: 2014-10-09 15:29:28 UTC
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 1057290 Bytes = 1 MB
Load Address: 80060000
Entry Point: 80060000
Verifying Checksum at 0x9f650040 ...OK
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 80060000) ...
## Giving linux memsize in bytes, 33554432
Starting kernel ...Ah ha! I see top of RAM starts at 82000000
Let's do a quick test, from the top of usable ram 82000000 minus the start of the reservation 81fc0000 we get 256KB (or 40000 in hex)
Hmmm, so sounds like our math is right, that's common amount of memory, so it's our starting location that is off.
So let's check the temporary storage address in relation to 82000000 which is the top of the usable ram for U-Boot:
a0800000 - 82000000 = 488MB....nope...ok...so that 256 could have just been a coincidence...
I'm pretty damn sure I'm doing something completely wrong here. I'm going to do some research on memory address calculations.
Any help on this would be greatly appreciated. I'll continue to post as I try to figure this out, I wish ALFA would have posted why they chose these addresses instead of just posting the instructions.
(Last edited by jivex5k on 10 Oct 2014, 23:25)