HI slh,
I downloaded the source code for f9k11115v2 and looked in the uboot source code and found the following which seems to correspond to reading headers generated by the edimax header patcher:
int eraseall_func(uint8_t *upg_addr){
uint8_t hcrc=0, dcrc=0;
unsigned long start=0, end=0, size=0, data=0;
fw_header_s hdr, *phdr=NULL;
uint8_t *p=NULL;
p=(uint8_t *)upg_addr;
data=(unsigned long)(upg_addr+sizeof(fw_header_s));
memset(&hdr, 0, sizeof(fw_header_s));
memcpy(&hdr, p, sizeof(fw_header_s));
phdr=(fw_header_s *)p;
printf("######################### Eraseall %01x ########################\n", eraseall_count);
if(strcmp(phdr->magic, "eDiMaXsUpEr")!=0 && strcmp(phdr->magic, MAGIC_STRING)!=0) goto run_cmd_err; //check header "super magic" and "magic" string
hdr.hcrc=0;
hcrc=checksum((char *)&hdr, sizeof(fw_header_s));
dcrc=checksum((char *)(p+sizeof(fw_header_s)), hdr.size);
start=ntohl(phdr->start_addr);
size=ntohl(phdr->size);
if(!strcmp(phdr->mtd_name, "u-boot")){
start+=0x9f000000;
}
if(!strcmp(phdr->mtd_name, "uImage")){
start+=0x9fe70000;
}
if(!strcmp(phdr->mtd_name, "rootfs")){
start+=0x9f050000;
}
end=start+size-1;
printf("Header Data: \n");
printf("Model Name: %.*s\n", 32, phdr->model);
printf("Data Size: %ld Bytes\n", size);
printf("Start Address: 0x%08X\n", start);
printf("End Address: 0x%08X\n", end);
printf("MTD Name: %.*s\n", 16, phdr->mtd_name);
printf("Version: %.*s\n", 14, phdr->version);
if(hcrc!=ntohl(phdr->hcrc)) goto hcrc_err;
if(dcrc!=ntohl(phdr->dcrc)) goto dcrc_err;
current_upg_addr+=sizeof(fw_header_s)+size;
//if(uboot_run_cmd("protect off %lx %lx", start, end)<0) goto run_cmd_err;
if(uboot_run_cmd("protect off all")<0) goto run_cmd_err;
if(uboot_run_cmd("erase %lx +%lx", start, size)<0) goto run_cmd_err;
if(uboot_run_cmd("cp.b %x %lx %lx", data, start, size)<0) goto run_cmd_err;
return 1;
run_cmd_err:
printf("run_cmd error!!\n");
goto enderr;
magic_err:
printf("magic error!!\n");
goto enderr;
hcrc_err:
printf("hcrc error!!\n");
goto enderr;
dcrc_err:
printf("dcrc error!!\n");
enderr:
printf("#############################################################\n");
return 0;
}
It doesn't seem like this is doing anything to adjust boot argument...
However, the mtd partition layout from the source code for this board (board955x) seems to be the following:
boot\u-boot\include\configs\board955x.h:178:# define MTDPARTS_DEFAULT "mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),14464k(rootfs),1536k(uImage),64k(ART),16320k@0x0(all)"
Which is curiously different from the lede one:
f9k1115v2_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),14464k(rootfs),1408k(kernel),64k(nvram)ro,64k(envram)ro,64k(art)ro,15872k@0x50000(firmware)
I am not sure what to make out of this - is it possible to get rid of nvram and envram and merge them into kernel partition?
On another note, in this commit:
https://github.com/lede-project/source/commit/f7a6fd31539be54d14d7c52b491b40b26bf8f740
Hauke Mehrtens mentioned
When CONFIG_KERNEL_KALLSYMS is not set it could be that the kernel will
fit onto the board again, this is the case for release images.
Do you know how much it shrinks the kernel? Are there other known safe ways to shrink the kernel - in which case I can happily compile custom builds for this router (and hopefully it is also generally applicable to other devices with similar size of kernel partition)