struct aeolia_ipl_hdr {
    u32 magic; // 0xd48ff9aa
    u8 field_4;
    u8 field_5;
    u8 field_6;
    u8 proc_type; // 0x48: EMC, 0x68: EAP
    u32 hdr_len;
    u32 body_len;
    u32 load_addr_0;
    u32 load_addr_1; // one is probably entrypoint..
    u8 fill_pattern[0x10]; // DE AD BE EF CA FE BE BE DE AF BE EF CA FE BE BE
    u8 key_seed[0x8]; // F1 F2 F3 F4 F5 F6 F7 F8
    // key_seed is used as input to 4 aes operations (2 blocks each)
    // some output of those operations is used as the key to decrypt the following 5 blocks
    u8 wrapped_thing[0x20];
    u8 signature[0x30];
    // offset 0x80
    u8 body[body_len];
}

notes:
 * hdr_len must be 0x80
 * body_len must be at least 0x200
 * load_addr + hdr_len + body_len <= 0x160000
 * seems to be similar to other marvell rom/sram layout.
 * EMC IPL seems to be bounded to range [0x100c00, 0x160000)
 * load_addrs can be anywhere within range, but must be same value
 * seems wrapped_thing is something used to decrypt body.
  * wrapped with silicon-revision-specific material
 * if given ipl from wrong pup package_id (made for different key?), still reads in whole thing
  * either doesn't execute or doesn't execute successfully
 * does not appear to do crypto while loading ipl body

flow
 * read sector 0
 * read indicator
 * read mbr
  * check ipl size in sectors <= 0x2fa (0x5f400)
 * read ipl sector 0 (header)
  * verify bounds:
   * hdr_len == 0x80
   * load_addr_0 == load_addr_1
   * load_addr >= 0x100c00
   * load_addr + hdr_len + body_len <= 0x160000
  * check other fields:
   * proc_type == expected
   * maybe some other fields...?
   * (still proceeds to read body even if fill_pattern, wrapped_thing, signature are all bogus)
 * read rest of ipl
 * does weird crypto initialization patterns ???
  * assume derivation with wrapped_thing
 * hashes header and compares to expected (not sure where it's stored)
 * if wrapped_thing or signature (or any part of header...) is modified, stops here
 * hashes body
  * this takes fucking forever (~4s @ 100/12mhz)
  * seems to just halt at end if data is wrong? (quick hash check? or it jmps and fails?)
  * small, slightly different pattern at the end
   * looks like 4x previous pattern, with stuff inserted inbetween
 * switches to denser pattern for another ~4s
  * aes probably
  * same pattern is seen during initial derivation
 * jmp entrypoint?
 * clock config seems to happen - in ipl code now?
 * accesses sflash again (for wifi fw?)