Ubee DDW36C profile question

[Anonymous941]

@jclehner I'm confused on how to write a device profile for the Ubee DDW36C. For example, when trying to convert this /flash/show portion (full output):

Flash Device Information:

      CFI Compliant: no
        Command Set: Generic SPI Flash
   Device/Bus Width: x16
 Little Word Endian: no
    Fast Bulk Erase: no
    Multibyte Write: 256 bytes max
  Phys base address: 0xbadf1a5
 Uncached Virt addr: 0x1badf1a5
   Cached Virt addr: 0x2badf1a5
   Number of blocks: 257
         Total size: 16777216 bytes, 16 Mbytes
       Current mode: Read Array
        Device Size: 16 MB, Write buffer: 256, Flags: 0

      Size  Device      Device     Region
Block  kB   Address     Offset     Offset   Region Allocation
----- ---- ---------- ----------- --------- -----------------
    0   32 0x1badf1a5           0         0 Bootloader
    1   32 0x1bae71a5      0x8000    0x8000 Bootloader (65536 bytes)
    2   64 0x1baef1a5     0x10000         0 Permanent NonVol
    3   64 0x1baff1a5     0x20000   0x10000 Permanent NonVol (131072 bytes)

I don't understand why both of these are duplicated, and the number of bytes doesn't match up with the device offsets. My best guess is this:

{
    .name = "ddw36c",
    .pretty = "Ubee DDW36C",
    .spaces = {
        {
            .name = "flash",
            .size = 16 * 1024 * 1024,
            // what is .blocksize?
            .parts = {
                { "bootloader", 0x000000, 0x010000 },
                { "permnv", 0x010000, 0x020000 }
            }
        }
    }
},

[jclehner]

I don't understand why both of these are duplicated, and the number of bytes doesn't match up with the device offsets. My best guess is this:

The above output means that the bootloader partition is only 0x8000 bytes, but the next partition (permnv) starts at 0x10000, leaving a "hole" between 0x8000-0x10000.

Also, note that the partition definitions in profiledef.c are offset, size, not begin, end. So the first two partitions should be

{ "bootloader", 0x000000, 0x008000 },
{ "permnv", 0x010000, 0x010000 }

The permnv partition starts at device offset 0x10000, and is 0x10000 bytes long.

// what is .blocksize?

Set blocksize to 64k.

[Anonymous941]

@jclehner

I've added those, thanks. Now I'm trying to add these (also flash1 and flash2, but their output is much larger so I won't include them here):

  249   64 0x1ca5f1a5    0xf80000         0 Backup Dynamic NonVol
  250   64 0x1ca6f1a5    0xf90000   0x10000 Backup Dynamic NonVol
  251   64 0x1ca7f1a5    0xfa0000   0x20000 Backup Dynamic NonVol
  252   64 0x1ca8f1a5    0xfb0000   0x30000 Backup Dynamic NonVol (262144 bytes)
  253   64 0x1ca9f1a5    0xfc0000         0 Dynamic NonVol
  254   64 0x1caaf1a5    0xfd0000   0x10000 Dynamic NonVol
  255   64 0x1cabf1a5    0xfe0000   0x20000 Dynamic NonVol
  256   64 0x1cacf1a5    0xff0000   0x30000 Dynamic NonVol (262144 bytes)

I'm assuming dynnv_alt is the same as backup. Does it just mean this?

{ "dynnv_alt",  0xf80000, 0x030000, "dyn" },
{ "dynnv", 0xfc0000, 0x030000, "dyn" }

The above output means that the bootloader partition is only 0x8000 bytes, but the next partition (permnv) starts at 0x10000, leaving a "hole" between 0x8000-0x10000.

Out of curiosity, what is in these holes? Is it just unused flash or something like open bus?

[jclehner]

Out of curiosity, what is in these holes? Is it just unused flash or something like open bus?

Unused flash.

[Anonymous941]

Sorry for the late response, here's what I have so far:

{
    .name = "ddw36c",
    .pretty = "Ubee DDW36C",
    .baudrate = 115200,
    .spaces = {
        {
            .name = "ram",
            .min = 0x80000000,
            // read_memory < 0x8000000 = ERROR - Address is less than 0x8000000!
            // read_memory 0x80000000 (0k) = works
            // read_memory 0x80010000 (64k) = works
            // read_memory 0x80020000 (128k) = works
            // read_memory 0x80040000 (256k) = works
            // read_memory 0x80080000 (512k) = works
            // read_memory 0x88000000 = works
            // read_memory 0x90000000 = crash
            // read_memory 0xfffffffc = crash
            // read_memory >=0xffffffff = ERROR - Address 0xffffffff not aligned for the element size (4 bytes)!
        },
        {
            .name = "flash",
            .size = 16 * 1024 * 1024,
            .parts = {
                { "bootloader", 0x000000, 0x010000 },
                { "permnv", 0x010000, 0x020000, "perm" },
                { "image1", 0x30000, 0x7d0000, "image1" },
                { "image2", 0x800000, 0x780000, "image2" },
                { "dynnv_alt",  0xf80000, 0x040000, "dyn" },
                { "dynnv", 0xfc0000, 0x040000, "dyn" },
            },
        },
    },
},

• I don't think those parts of flash are unused. When I dump permnv, dynnv and dynnv_alt, bcm2cfg only parses it successfully if I dump those parts too. I'm not sure how to check bootloader, but image1/image2 successfully extract using ProgramStore
• How do I check the size of the RAM? I could figure out that it starts at 0x80000000 with read_memory, but I can't figure out where it ends, as read_memory works (meaning it doesn't crash the router) even 128 MB in, and I doubt my router has that much RAM
• Where is the nvram? I know it has it because there are commands related to it, but I don't know how to find it. Could I dump the entire contents of RAM, and search for some kind of magic?
• Also, how do I find the bootloader in RAM? Does it differ from the bootloader in flash?
• ecos_bootloader_analysis.py in recos failed to automatically find the functions, so I have to load it into Ghidra. Do I have to look at every function one by one or is there a better way?