Another note, I noticed the SCSI command whitelist in older FW revisions normally has 3 x int32 values per element, the 3rd one always seemingly being null.  However FW 1.50 actually uses that 3rd value as a pointer to a string with the original command name.  (In newer FW like 6.60 the array is 2x int8.)  The command names for 0x00-0xC0 are pretty standard besides DVD->UMD replacements, but the 0xF0 command names without any associated function/NID could be useful too.

    {0x00, 0x01}, // TEST_UNIT_READY
    {0x03, 0x02}, // REQUEST_SENSE
    {0x12, 0x02}, // INQUIRY
    {0x1B, 0x01}, // START_STOP_UNIT
    {0x1E, 0x01}, // PREVENT_ALLOW_MEDIA
    {0x23, 0x02}, // READ_FORMAT_CAPACITIES
    {0x25, 0x02}, // READ_UMD_CAPACITY
    {0x28, 0x08}, // READ10
    {0x2B, 0x01}, // SEEK
    {0x34, 0x01}, // PREFETCH10
    {0x46, 0x02}, // GET_CONFIGURATION
    {0x4A, 0x02}, // GET_STAT_EVENT
    {0x55, 0x04}, // MODE_SELECT10
    {0x5A, 0x02}, // MODE_SENSE10
    {0xAD, 0x02}, // READ_UMD_STRUCTURE
    {0xB6, 0x04}, // SET_STREAMING
    {0xBB, 0x01}, // SET_SPEED
    {0xBD, 0x02}, // MECHANISM_STATUS

    {0xF0, 0x02}, // DETECT_UMD_PSP
    {0xF1, 0x08}, // READ_UMD_MKI
    {0xF2, 0x02}, // REPORT_CACHE
    {0xF3, 0x01}, // CLEAR_CACHE_INFO
    {0xF4, 0x02}, // GET_MEDIA_INFO
    {0xF5, 0x02}, // TEST
    {0xF6, 0x01}, // SET_ACCESS_LIMIT
    {0xF7, 0x01}, // SET_LOCK_LENGTH
    {0xF8, 0x01}, // SET_AREA_LIMIT
    {0xF9, 0x02}, // GET_ERROR_LOG
    {0xFA, 0x02}, // TEST_PI
    {0xFB, 0x04}, // TEST_PO
    {0xFC, 0x02}, // GET_ADJUST_DATA
    {0xFD, 0x04}, // SET_ADJUST_DATA

On PS2 the (DNAS) Disc ID is also 5 bytes long. 

How do we get it?

5 bytes = 40 bits. DVD has 40 bits key of CSS, so I've expected that UMD also has some kind of 40 bits key (media key?).

SPK is SPecial Key? SPecific Key?

Possible.

Another guess I have could be it's some form of Disc ID - Sony already has a unique ID for every disc on PS2 and PS3.  (If not from the MKI command, maybe from another one.)
On PS2 the (DNAS) Disc ID is also 5 bytes long.  And while currently on Redump only the first two bytes are removed due to being serialized/random, from my observations I'm pretty sure it's supposed to be the first three bytes (see [PS2] Burnout Revenge (Europe, Australia) (En,Fr,De) as an example) followed by the region on the 4th byte (0x20 = Asia, 0x30 = USA, 0x40 = Europe etc.), making it 16.7 million unique Disc IDs for each game on PS2.
Likewise, PS3's Disc ID being 16 bytes long, the last 4 bytes are also removed for each entry, also followed by the region on the 5th byte (0x01 = Asia, 0x03 = USA, 0x04 = Europe etc.), making it theoretically 4.2 billion unique IDs per game.

With this in mind, I wouldn't be surprised if Sony also had some form of unique Disc ID for PSP, too.  Although wouldn't the 0x08 written at buf[2] interfere with it?

unsigned char bufSPK[0x4000] = {};
void* p1 = _sceUmdManSPKGetMKI();
memcpy(bufSPK, p1, 0x4000);

It crashed by memcpy.

5 bytes = 40 bits. DVD has 40 bits key of CSS, so I've expected that UMD also has some kind of 40 bits key (media key?).

SPK is SPecial Key? SPecific Key?

For good measure maybe also copy the data from the MKI address before memset'ing it to 00, to see if there's already something there.

I am probably overthinking it, but do try the ReadMKI function with the SPKGetMKI address (if it allows you to write to kernel memory like that).  At worst it'll just blank out assembly instructions of the module and crash

The result is no error and no crash but buffer is all zero bytes except buffer[2].

    void* p = _sceUmdManSPKGetMKI();

p is 0x880f1240

Looks like that is in kernel module address space 0x88000000-0x8837FFFF, per documentation.
This does make more sense than just plain 0x1C0, but now part of me wonders if this is a valid region of data that can be overwritten, or if this is just the offset of the module itself, indicating its base is at 0x880F1080.  I am probably overthinking it, but do try the ReadMKI function with the SPKGetMKI address (if it allows you to write to kernel memory like that).  At worst it'll just blank out assembly instructions of the module and crash

Also, at first I couldn't find any mention of this MKI thing anywhere on the internet, but I just now stumbled upon an archived thread that mentions "UMD MKI" once.  Doesn't say what it stands for, but it's something.

could you try calling sceUmdManSPKGetMKI() on its own and print out what address it returns?

    void* p = _sceUmdManSPKGetMKI();

p is 0x880f1240

Yes. I've already comfirmed that this func can be called and succeeded.

    unsigned char bufCapa[8] = {};
    res = _sceUmdExecReadCapacityCmd(0x25, pUmdDrive, 8, bufCapa);

The result is here. (Dissidia 012: Duodecim Final Fantasy)

 00 0D 2C B0 00 00 08 00

1st 4 bytes show total sectors. It matches redump db. 2nd 4 bytes show the block size in bytes. It's always 0x800.

Without a debugger to see what exactly it's doing, it's hard to know if those addresses are relocated by the system or not.  However, could you try calling sceUmdManSPKGetMKI() on its own and print out what address it returns?  Maybe this will give an answer whether you truly have to put 0x1C0 or not.  (And you could likely use the output of that to set up the ReadMKI call.)

----------

This is unrelated, but I did a bit more research about the SCSI commands that umdman.prx has functions for.  Some firmware revisions have functions that send the commands 0xA3 and 0xA4, but neither of them have any NIDs associated.  And today I noticed what looks to be an array of whitelisted commands it can send.  In addition to the FW NID map function I wrote a few replies back, it looks like it would allow commands 0x00, 0x23, 0x25, 0xA3, 0xA4, 0xB6, 0xBB, and vendor specific commands 0xF5, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD.  None of these also have a specific NID-hashed function.

However, sceUmdExecReadCapacityCmd() seems to be the only function that allows putting your own command as arg0, followed by the UMD drive as arg1 of course.  While I assume this is where you would normally put 0x23/0x25, I wonder if it would be possible to exploit and take advantage of this function to send other commands.  Though there is no function that calls it in any firmware it looks like (checked 1.50, 3.52, 6.60), so knowing that it wants for arg2 and arg3 will need guesswork.
I've edited the 3.70-6.60 NID map to also include this function commented with "Any?"

A 5 byte buffer is created on the stack, arg1 and arg2 being stored as int16s at 0x00 and 0x02, and arg3 as an int8 to 0x04.
If I am reading it correctly, you can just write 0x08 at buffer[0x2] and that's it.

sceUmdExecReadMKICmd() is called with 4 arguments:

• $a0 - UMD drive (as always)

• $a1 - Pointer to the buffer

• $a2 - Number 8 (from buffer[0x2])

• $a3 - Number 448 (0x1C0)

Overall, I would say this is it, if it weren't for some unusual calls between the buffer creation and the actual ReadMKI call.  It calls memset(0x1C0, 0x00, 0x8000) - I'm not sure if 0x1C0 a valid address.
And right after that, it calls sceKernelDcacheInvalidateRange(0x1C0, 0x4000), (the 2nd arg being 8 (from arg2) << 11 = 0x4000), implying the address 0x1C0 is somewhere in the CPU data cache region?  No idea.
Does that also mean it expects you to get the output back from d-cache too?