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.bin
0xa0800000 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.bin
Now 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 11 Oct 2014, 01:25)