The Firmware Page

It's been a while (since yesterday ). Let's make another release of the UJDA 7xx RPC-1 autopatcher (mpatch v1.12 - 2003.01.31)

The file can be downloaded here:
http://www.rpc1.org/matshita/mpatch.exe

Instructions:
- Download file,
- Run the executable in windows (this will create a bootable floppy),
- Reboot your laptop with the floppy in the drive (you might want to check that your BIOS is set to boot from the floppy),
- Leave the floppy do the patching or select a non automated mode.

NOTE: THE CURRENT AUTOPATCHING PROCESS WILL FREEZE WHEN EXECUTING DRVLOADC - WE KNOW!!!
BUT YOU WILL FIND WAYS TO WORK AROUND THIS IF YOU READ THIS THREAD (YOU HAVE TO REBOOT BETWEEN MPATCH AND DRVLOADC). IF YOU DON'T KNOW HOW TO DO THIS, WAIT FOR A NEW VERSION TO FIX THIS.

If everything goes well, there will be a bootable CD image for those who have a swap bay.

Now, I'm pretty sure this version (1.12) will fix the issue of drvloadc's freezout after running mpatch. Option -r has been dropped with this release (now mpatch will does a hard reset by default on exit, but this can be dropped with -s option)
Please confirm whether things work out as expected or not.

I also slightly altered the naming convention of the dump to 'ABC_123$.7xx' where:
- ABC is the OEM manufacturer (can be 2 or 3 letters)
- 123 is the revision (1.23)
- '$' indicates the IDE Master/Slave position (M or S)
- 7xx is the drive type

Now you can begin sending your dumps (using the dump option) to Arzeno, after having checked whether your firmware is already available on the site.

Hopefully, in a few months, we should have a good database of UJDA firmwares, so that people who got issues after flashing can get back to their original one.

Hello NIL,

Thanks for all your effort... this is important stuff.

I am getting the error shown above which was stated before by someone else with the pre-release. Any ideas?

IBM A31p, UJDA720, the original pain-in-the- .

Thanks,
Shiva_1

Is your drive really an IDE drive, or is it firewire?
Firewire is NOT supported, the main reason being that Matshita never released a flashing tool for Firewire, and I use the flashing tool from Matshita.

Is it worth those of us that have already flashed using this?
Would you want those dumps?

It's for sure an IDE drive. I am running the patch from a accessable partion with an empty drive and with a CD-ROM support boot, but I doubt that's a problem.

Shiva_1

Apparently it's a BIOS issue. If the BIOS refuses to list the devices in DOS mode, there's not much I can do about it, and I don't really plan to waste my time trying to work around stupid limitations added by manufacturers in their laptop BIOSes. Please have a look here for more information.

If your drive is running fine, you don't need to care about the dumps.
The dumps are mostly for ppl who flashed their drives using a different patched firmware from the one they had and who got issues with that.

Besides, since we are a firmware site, it makes sense to collect as many firmwares as possible.

Since these firmwares are meant to be used with mpatch, I would advise to dump the firmware with mpatch -d BEFORE applying the patch.

Having RPC-2 firmwares is no big deal, since mpatch can patch it, and in case you have to return your drive, you would just have to pick up the relevant RPC-2 on this site and flash it so that Matshita don't try to charge you extra from having patched your drive (like Pioneer does with the DVR's)

Once it's been confirmed that flash.bat can be run properly after mpatch, I'll make a nice foolproof version of the bootdisk, with menus, to ease up all this stuff.

I think it's strange that I can access the drive by reading CD-ROMS but can't access it to flash it.

Can you access your drive from DOS?
Does IDEDIAG (which is provided with the mpatch bootdisk) list your drive?

Also, you get the message: "Relevant device could not be accessed", but is it listed in mpatch or not?

In order to patch your UJDA mounted in this kind of docking station, you have to dismantle it, find another notebook with a similar hardware interface, put it inside, apply NIL's patch, and there ya go. Usually the drives are secondary masters, so you should have no particular problems.

It worked for me, with the exception that I had to use a blank floppy to copy inside the dump, due to the lack of space on the first one. Thanks to Gizmo, who explained the procedure in detail in the prelelease 3-rd page.

Thanks NIL for your wonderful work.

Good luck all of you in patching your firmware. This procedure should work for any other UJDA installed inside a IEEE1394 device, since Matsushite is producing IDE drives and some other companies are supplying Sony with the contoller (usually Epson).

I am now thinking about trying another firmware version, 1.50, for instance, because I have 1.04, and 1.50 should be a lot improved. What do you think NIL?

The drive IS listed with IDEDIAG as:

PS ATAPI CDROM UJDA720 DVD/CDROM (1.03).

Is it listed in mpatch?

??? What does it mean ???
Does it mean that running FLASH after 'mpatch -a' froze or you didn't even try to run FLASH without a reboot?
I NEED to know whether the problem still exists or not!!!

As to what I think about trying a newer revision, I'll have only one word:
'DANGER!'

You should have a look at the various UJDA threads relevant with RPC-1 patches, you will see that unlike other drives, UJDA ones do not upgrade without a fight (which is precisely why I had to make the autopatcher in the first place)

How do I see it with mpatch? When I type mpatch, is give me the response I told you about; " Relevent drive..."

Hi >NIL,

I tried the release version (1.10) of the UJDA 7xx autopatcher and run in the same problem described in the pre-release thread (first drvloadc would hang forever, then reboot and just run drvloadc --> error at 69%).

From what I can see (I run a sided by side comparison), the floppys generated by the pre-release and the release version are identical (with the exception of the date and filestamp of the cab file, but the content if the cab itself seems to be the same).

Maybe the link to mpatch.exe is not pointing to the correct location?

Well, mpatch is supposed to list some information about the drives it can find, like the constructor's ID. It could display this info and say relevant drive not found or it can just say "None" and not found.

Nope, I go into DOS, take the disc out of the drive, and type mpatch (or mpatch -a, before) and it says the program title and then the error message.

It seems strange that mine does this (IBM), someone else's Dell does this and there was another brand with the problem... I wonder what is common with our different brands that isn't a problem with other peoples.

Hi >NIL:, Unless somebody beats me to it, I'll run the test later. Currently in the middle of a long 2-pass DivX encoding session so can't reboot!

I have not done anything to fix this. I'm only interested in getting the FLASH batch working after running mpatch, so that I can produce a dumbproof enough release.



Only the mpatch executable which is extracted from the cab archive has been modified. The rest is exactly the same. If mpatch displays version 1.10, you're using the new release.

Now, it looks like I have to make my IDE bus reset a little stronger...

IMPORTANT!!

OK, it seems that zaton was right and that the mpatch version I embedded in the cab archive was still v1.00
Sorry about that

Now, I've just release v1.11, with a new interface.
Hopefully this time you should be able to really verify whether the soft reset works to get DRVLOADC running after mpatch.
Please be aware that if it doesn't, you can also try to add the -r option to do an hard reset.

Please let me know how it goes.

Bad news I'm afraid. According to the test procedure I set out in my earlier post the problem still exists with both soft/hard IDE resets.

>NIL: are the IDE resets still carried out if a CTRL+C interrupt is received? Not that I think it makes much difference since for the hard IDE reset (-r) I let MPATCH -d -r run all the way through and DRVLOADC still hung afterwards For the soft IDE reset I ran MPATCH (no flags) and interrupted with CTRL+C. Same result - DRVLOADC hangs

Oh, and BTW, you have a typo in the banner for MPATCH

I found that on my HP Omnibook with a UJDA 710 FW 1.09 RPC-1 HW 1.01 that IDEDIAG found the device just fine as SM but the Windows Device Manager states it is in location 0(0) which means that technically the hard drive and the UJDA710 are sitting as Primary masters and bus mastering or some other software device is being used to force the UJDA over into SM. Could it be possible that it might work if the HD was disconnected? I am going to try this when I can.

In any case the pre-release mpatch does not find the UJDA710 or any other device on my system although IDEDIAG correctly diagnoses it to be
a UJDA710, SM, with FW 1.09.

What do y'all think? 8)

Dammit!
But I'm having doubts about the whole reset thing (I'm just reusing someone else's code), especially with the hard reset, since I would expect the IDE devices to react in some noticeable way, and I can't see anything like this happening...



Nope. They are done at the very end, just before mpatch exits. If you interrupt, reset will not occur.

Does anybody knows if it's possible to make a permanent RAM disk on a PC (i.e. a RamDisk that will keep its information between resets and only gets discarded on poweroff)? This way I could at last come with some kind of dumbproof solution where people who don't want to worry about the patch could let the whole thing run by itself.
And FYI, this permanent bootdisk was a standard feature of the Amiga (and you could boot from this RamDisk as well)...

I will correct this, thanks!

Are you sure you're resetting the IDE device at the end of the cable and not just the IDE controller itself?

Simulating ejecting the drive (thus cutting off its power) and replugging it to reset it into a sane state probably can only be imitated by sending the drive itself some special command, and I'm not sure if that's even standardized...

np: Deadbeat - A Dub For Akufen (Wild Life Documentaries)

Well, according to ATA-3 (http://ftp.t10.org/ftp/t10/drafts/ata3/ata3r06.pdf - section 9) and other sources, there are 3 types of reset you can do:
1/ Power on and hardware reset (the real Hardware Reset)
2/ Software Reset
3/ Sending an ATA DEVICE_RESET command on the IDE bus

Now, since I have yet to find a source on the internet that will explain how to program the RESET pin from the IDE controller, I have only used options 2 and 3 (mpatch does 2 by default, and mpatch -r does 2+3)

Now, I'm basically using Hale Landis' ATADRVR sources around which I wrapped in a DOS equivalent of the winaspi32 API.
Therefore, I completely rely on Landis' code for my resets, but it seems to do a pretty good job with all the rest, so I guess it should be OK.

Software Reset was already implemented in the reg_reset() function, so this was the first one I used. Then yesterday I found out that you could use a CMD_DEVICE_RESET, which I hoped would do the kind of hard reset I was looking for, but apparently doesn't .

From my analysis of the code, both those commands apply to the whole bus and not to a single device on the bus, so this my reset function is currently coded as follows:



Now, Hale says the following about the DEVICE_RESET command, which leads me to think that, eventually, we'll need to trigger a real hardware reset of the buses:


Nothing replaces a TRUE hardware reset!