FMCB will only boot ule from osdmenu

For some bizarre reason, lately whenever I try jump to ulaunchelf from FMCB using a shortcut key, or the auto setting, I get a black screen that flickers briefly at first (like it would on a successful boot), but then just sits at a blank screen. However, if I let FMCB go all the way into the main menu and select ulaunchelf from there, it boots just fine. It's odd, since both entries point to the same .elf file. Also, I can boot HDloader and ESR with key shortcuts just fine.

The only real change I've made to FMCB was to delete the sms.elf file (to save space). But I've since copied it back to the MC1/boot/ and even run the FMCB installer (single, rather than multi version) again with no luck.

I'm using ule 4.4. I've also tried 4.15, and 4.39 with no luck. Bizarrely enough, if I move them to MC0 (the non-fmcb card) they all boot from a shortcut key just fine.

other details
- FMCB version 1.8 test 22 (according to fmcb eonfigurator)
- fmcb is installed to MC1 (card in slot 2)
- config file loaded on an attached thumb drive (there's also a backup copy in MC1:/SYS-CONF).
- I've attached copies of my freemcb.cnf and launchelf.cnf files.
- both memory cards are official sony brand cards.
- MC0 I bought brand new many years ago, MC1 I bought used a few weeks ago

In summary ulaunchelf won't boot from a shortcut key or the auto entry when it's on the same memory card as FMCB, even though it boots just fine from the osd menu (on either card).

Quote:

---

Originally Posted by dstarfire

For some bizarre reason, lately whenever I try jump to ulaunchelf from FMCB using a shortcut key, or the auto setting, I get a black screen that flickers briefly at first (like it would on a successful boot), but then just sits at a blank screen. However, if I let FMCB go all the way into the main menu and select ulaunchelf from there, it boots just fine. It's odd, since both entries point to the same .elf file. Also, I can boot HDloader and ESR with key shortcuts just fine.

The only real change I've made to FMCB was to delete the sms.elf file (to save space). But I've since copied it back to the MC1/boot/ and even run the FMCB installer (single, rather than multi version) again with no luck.

---

Please use the proper namings.
It is mc?:/BOOT normally.
mc0 is MC-Slot1 (left)
mc1 is MC-Slot2 (right)
mc? is searching on both MCs in a folder for a file (same folder- and file-name).

Btw.: Normally there is no need to use the "Normal-Install". A Multi-Install is preferable.

Quote:

---

I'm using ule 4.4. I've also tried 4.15, and 4.39 with no luck. Bizarrely enough, if I move them to MC0 (the non-fmcb card) they all boot from a shortcut key just fine.

---

Hm,... Let's quote the relevant stuff.

Code:

---

LK_R1_E1 = mc1:/BOOT/ULE 3-9.elf
LK_R1_E2 = mc?:/BOOT/BOOT.ELF
LK_R1_E3 = mc?:/B?DATA-SYSTEM/BOOT.ELF

---

Btw.: Huh? Why are the first and second entry 'kind of' doubled?
I know you didn´t mentioned any problems in OSD, I was just interested.

Code:

---

name_OSDSYS_ITEM_1 = uLaunchELF
path1_OSDSYS_ITEM_1 = mc1:/BOOT/BOOT.ELF
path2_OSDSYS_ITEM_1 = mc0:/BOOT/BOOT.elf
path3_OSDSYS_ITEM_1 = mc?:/B?DATA-SYSTEM/BOOT.ELF

---

It seems to me the BOOT.ELF is, which is correctly launched from OSD.
So why is there even the first pad-path mapped to "ULE 3-9.elf"?
Is this file present in the desired folder?
Hm,... This reminds me a bit to an old bug before 1.8 was released.
Maybe it isn´t 100%ly fixed.

Quote:

---

other details
- FMCB version 1.8 test 22 (according to fmcb eonfigurator)

---

Nope, that is the configurator-Version (It was for FMCB 1.8Beta-Testbuild 22), but I think that wasn´t updated simlpy.

Quote:

---

- fmcb is installed to MC1 (card in slot 2)
- config file loaded on an attached thumb drive (there's also a backup copy in MC1:/SYS-CONF).
- I've attached copies of my freemcb.cnf and launchelf.cnf files.
- both memory cards are official sony brand cards.
- MC0 I bought brand new many years ago, MC1 I bought used a few weeks ago

In summary ulaunchelf won't boot from a shortcut key or the auto entry when it's on the same memory card as FMCB, even though it boots just fine from the osd menu (on either card).

---

Crazy issue.

This seems like the reason your having issue with a button launch:

Quote:

---

LK_R1_E1 = mc1:/BOOT/ULE 3-9.elf
LK_R1_E2 = mc?:/BOOT/BOOT.ELF
LK_R1_E3 = mc?:/B?DATA-SYSTEM/BOOT.ELF

---

Try deleting ULE 3-9.elf and see if it works.:chinscrat

Quote:

---

Originally Posted by dstarfire

For some bizarre reason, lately whenever I try jump to ulaunchelf from FMCB using a shortcut key, or the auto setting, I get a black screen that flickers briefly at first (like it would on a successful boot), but then just sits at a blank screen. However, if I let FMCB go all the way into the main menu and select ulaunchelf from there, it boots just fine. It's odd, since both entries point to the same .elf file. Also, I can boot HDloader and ESR with key shortcuts just fine.

The only real change I've made to FMCB was to delete the sms.elf file (to save space). But I've since copied it back to the MC1/boot/ and even run the FMCB installer (single, rather than multi version) again with no luck.

I'm using ule 4.4. I've also tried 4.15, and 4.39 with no luck. Bizarrely enough, if I move them to MC0 (the non-fmcb card) they all boot from a shortcut key just fine.

---

I can't say that I see the full picture here, but I do see something that seems wrong, and certainly is inconsistent, as you imply that the launch strings for the launch key and for the OSDSYS menu entry are identical, which they are not.

Let's have a look at the R1 shortcut definitions:

Code:

---

LK_R1_E1 = mc1:/BOOT/ULE 3-9.elf
LK_R1_E2 = mc?:/BOOT/BOOT.ELF
LK_R1_E3 = mc?:/B?DATA-SYSTEM/BOOT.ELF

---

And then the OSDSYS menu entry for uLE:

Code:

---

name_OSDSYS_ITEM_1 = uLaunchELF
path1_OSDSYS_ITEM_1 = mc1:/BOOT/BOOT.ELF
path2_OSDSYS_ITEM_1 = mc0:/BOOT/BOOT.elf
path3_OSDSYS_ITEM_1 = mc?:/B?DATA-SYSTEM/BOOT.ELF

---

Note how both the first and the second entries of the R1 launch key definition differ from the first and second entries of the OSDSYS definition for uLE.

That is clearly involved in why the OSDSYS version always works, while the launch key does not.

But if that is all there is to it, then there is a bug in FMCB...!!!
Because even though the first entry of the R1 launch key definition looks like garbage, that should not affect the use of the second entry, which should be able to find the BOOT/BOOT.ELF by searching both memory cards, disregarding the failure of the first entry.

And yet you say that it does work fine when you place the MC as mc0, rather than mc1.

This does make some sense, in case the FMCB bug causes a failure in the first entry to somehow affect the next entry such that it too will fail for the SAME device as used in the first entry. And since the first entry specifies only mc1, this allows the search on mc0 to succeed.

This means that unless there is something more involved here, beyond what I can see, then there probably is some bug in how FMCB handles multiple entry searches for the same device (or perhaps just the same specific MC). And this means that the FMCB programmers should have a look-see in that part of the code, to check if it needs fixing. (I may have a peek at this myself if I get some time for it.)

However, the obvious thing for you to do now is (like others already said) to replace the first entry of both the definitions quoted above so as to instead use the path string "mc?:/BOOT/BOOT.ELF" (but without the quote characters I used here).


@TnA & JNABK:
You are both correct in pointing out the most obvious error dstarfire made here, but you seem to have missed the important implication of a bug in FMCB.

If FMCB worked correctly, then his symptom should not have occurred. The elf should always have launched when he held the R1 button, though it would have a slightly longer delay due to the time wasted looking for the wrong name of the E1 entry, but since the E2 entry with correct filename specifies a search of both MCs, that search should succeed identically, regardless of whether the MC was in the first or the second slot.

This bug may have been masked all this time by the fact that the first and second path entries of launch key and OSDSYS definitions normally refer to different devices ("mass:" vs "mc?:").

Best regards: dlanor

Well it could also simply be the entry:
LK_R1_E1 = mc1:/BOOT/ULE 3-9.elf
as his cause for a blackscreen, if booting that ELF indeed causes a blackscreen if he in fact even has that ELF with that name in that location. :chinscrat

Quote:

---

Originally Posted by JNABK

Well it could also simply be the entry:
LK_R1_E1 = mc1:/BOOT/ULE 3-9.elf
as his cause for a blackscreen, if booting that ELF indeed causes a blackscreen if he in fact even has that ELF with that name in that location. :chinscrat

---

That is true of course, but most elfs would produce some screen output before just dying, especially if it really is some version of uLE. But I guess some of the old versions may be 'allergic' to some of the values in a CNF file created by a new version, causing them to go BSOD.

Whatever, only dstarfire can tell us if any elf by that name really exists on that MC or not.

Best regards: dlanor

Quote:

---

Originally Posted by dlanor

@TnA & JNABK:
You are both correct in pointing out the most obvious error dstarfire made here, but you seem to have missed the important implication of a bug in FMCB.

---

I quote myself. ;)

Quote:

---

Originally Posted by TnA

Hm,... This reminds me a bit to an old bug before 1.8 was released.
Maybe it isn´t 100%ly fixed.

---

I mean a bug which was triggered, if the first path was empty (CNF-Entry present without path).
Maybe he remembers, which one.
There were similar bugs due the (time of) 1.8 beta-status.

Maybe he can rename a working HDLoader or similar to the same name and start it.

In the config files, the references to ule 3-9.elf are the result of testing the other versions of ULE. I had the problem before I made those changes.

I've attached updated config files with those changes reverted, if this helps at all.

Also, the blank screen I get flickers briefly at the start, as most apps normally do when launching from FMCB. Usually, this occurs right after the screen that simply says "loading ...". However, when it fails to boot ule, it doesn't even display that loading screen.

Finally, the entries in the E1 launch keys section refer to working .elf files that are in the location described. I created those config files with fmcb configuration utility.

Quote:

---

Originally Posted by dstarfire

In the config files, the references to ule 3-9.elf are the result of testing the other versions of ULE. I had the problem before I made those changes.

I've attached updated config files with those changes reverted, if this helps at all.

---

It does not really help at all, because that is not the only change you made.
You also modified LK_Auto_E1 which is going to interfere with the testing every time you "miss" the button pressing, then attempting to launch "mc1:/BOOT/BOOT.ELF", which will obviously give different results depending on which slot you insert the MC in.

Quote:

---

Also, the blank screen I get flickers briefly at the start, as most apps normally do when launching from FMCB. Usually, this occurs right after the screen that simply says "loading ...". However, when it fails to boot ule, it doesn't even display that loading screen.

Finally, the entries in the E1 launch keys section refer to working .elf files that are in the location described. I created those config files with fmcb configuration utility.

---

Sure, but in that editing you must have done something more than you say you did, because that "LK_Auto_E1" entry did not change of itself without you editing it.

I also note that you still insist on continuing to use specific MC device names like "mc0:" and "mc1:" instead of using the generic MC reference string "mc?:" which is the recommended way of referring to an MC path, to ensure that the program searches both MC slots.

The only purpose of doing that would be in testing the search routines of FMCB, but to solve your own problem and make your setup independent of which MC slot you use, like you wanted it to be, you need to use the generic MC reference string "mc?:" instead of the specific device names you now use.

Edit:
I just realized that you may not have understood the meaning of the tooltip in the bottom line of the configurator menu, where it says "[]:Map to any MC". That tooltip means that if you use the Square button, instead of the normal menu action button (Circle or Cross), when you choose the button to be edited (eg: when the cursor is pointing to R1). Then the final result of the selection will be a 'generic' MC file reference.

So if you first use the normal action button to enter the menu "Configure E1 launch keys", and there move the cursor to the entry for R1 and then press the Square button, the file selector will be opened just as if you had used the normal menu action key. But when you conclude the file selection (using normal action key on an elf), the resulting selection for the R1 entry will start with "mc?:" instead of the name of the specific MC where you selected the elf file.

Best regards: dlanor

The LK_Auto_E entry is why I want to fix this problem. I set that so I could jump straight to ule (which is where I go most of the time).

I tried remapping all customized button settings to mc?, as you suggested, but that made no difference. I even made sure the exact same elf existed in both locations with the same name, but still get the same error.

Also, I'm not sure if this is related or not, but if I launch ule from fmcb I can't access the thumb drive until I launch another instance of ule from the first one.

Thanks again for your help, I really appreciate it.