I just loaded v3alpha7 onto my upgraded player, and noticed a small quirk.

The empeg .upgrade file includes a replacement "stock" 0e000 flash loader, so it wipes out the required one from Hugo! I'll update my Linux upgrader binary to automatically skip the 0e000 replacement in the same way it currently skips the kernel replacement step.

Apart from that, v3alpha7 seems to be working as well as ever, and leaves the second 16MB mostly untouched.

TO DO: the kernel and/or loader really have to be fixed to do an installed memory scan to determine RAM size. Currently I'm just hardcoding it, which means special kernels are required to suit the amount of memory installed.

Fixing this is not as simple as it might seem, since it requires tweaking the MMU to first gain access to the theoretical extra memory, testing for its presence (and defeating data-caching..), and then unmapping it if not found. All of which is complicated by the fact that the kernel currently sets up the MMU extensions much too late in the process, well after it has made use of the "memory size" value in lots of places..

Cheers

The updated upgrader (Linux only, for the moment) is now linked from the Hijack site, and upgrader.c is attached to this posting. MacOS and Win32 binaries will follow whenever the maintainers of those get around to it.

Cheers

Mmm.. The Hijack webserver can certainly take advantage of the extra memory! It can now load my album list into RAM and keep it there as I browse up and down the playlists through the web interface.

In fact, doing this exposed a glitch where the server is completely CPU bound longer than it used to be -- resulting in the odd playback glitch from the CPU-starved player software. I'll add some voluntary scheduling points in the code to prevent this for the next release.

Cheers

We don't have any more memory for sale, but we can most likely get more! There is a fairly substanial minimum order of 31 pieces last time we ordered. We can probably do a group buy, maybe for the remaining stock if anybody is interested.

Stu

How's the existing unit there doing, Stu?

Any luck with the Hijack kernels?

I'm about to release v387, which removes the requirement for Hugo's 0e000 replacement loader. Should simplify life for us in the longer run that way.

Cheers

I can't get the player to upgrade the flash file. Permissions seem to be getting in the way. Any suggestions? Mucking around with files in the Empeg is not our specialty.

Stu

Upgrade to Hijack v387 and reboot. No more need for the flash_0e000 thing that way. But the diagnostic memory test is gone in that version -- it still does a ramtest, but just silently ignores the extra memory if it fails the test.

You can check for this by connection with serial, and hitting Q or control^C to exit the player, and then do: cat /proc/meminfo

It should look like what I posted earlier in this thread if all 32MB is working.

EDIT: Specifically, there should be a line like this in meminfo:

            MemTotal:     31176 kB

Cheers

At what point do we hit Q and where do we type cat/proc/meminfo? In a terminal? What does /meminfo do? I think we did it right, but we kept getting a sync error. Not sure what it meant, the player works fine.

Thanks,
Stu

You can hit Q and/or control^C anytime after about 10 seconds after applying power to the player.

And there's a space after "cat":

cat  /proc/meminfo

Alternatively, if Hijack is installed, you may be able to connect to it's webserver over ethernet and view it there: http://players.ip.addr/proc/meminfo

Finally, this is not even needed.. instead, you could just watch the serial output during boot, looking for this line:

Memory: 31240k/32M available (980k code, 20k reserved, 524k data, 4k init)

Cheers

News?

We don't have any more memory for sale, but we can most likely get more!

OK, I've sent you another email asking to be added to the list. Hopefully there are enough interested people to make another memory order worthwhile.

-Mike

I've updated Hijack to v388 here.

This version has better memory testing and failure reporting for memory upgrades.

Cheers

Well, it looked like still the stock memory in the Ethernet test. We haven't done the serial test yet. We'll try that if that fails too, I guess we'll have to inspect things, but so far everything looks soldered quite well

Stu.

All of those will show the same amount of ram.

You do need to have first installed the recent Hijack kernel, though. The best one now is v389.

-ml

I have just fixed a bug in Hijack whereby it has been "broken" for Mk1 and Mk2 players since v386 onwards. v389 in theory should work -- see the thread in Programming for details and current status on Mk2/Mk1 players.

Try testing your Mk2a mod job instead -- that part works just fine.

Bulk order in progress... Please stand by...

pgrzelak wrote:

I think I can safely say that I am running one of the largest databases in production today: highest FID 762D (30,253 FIDs decimal) with a database file size of just over 4MB. I think the hard published limit was somewhere around 28,000 FIDs decimal.

Can you run v3 at all with this database? I "only" have about 20.000 FIDs and had to do a lot to make this work on v3.

I upgraded my mk2 to an mk2a, disabled all third party apps, use mp3tofid to dramatically reduce the database size (from over 4 MB to 2.3 MB), and reduced the cache size to the bare limit.

Now I can use v3 without much trouble, but I still cannot play the root playlist without crashing the player. And of course, the harddisks hardly ever spin down.

I wonder if I'm the only one considering a memory upgrade just to make v3 work more reliably...

Pim

The root playlist crashes my player too. I just don't play it.

Link to memory bulk order info in the For Sale forum.

I wonder if I'm the only one considering a memory upgrade just to make v3 work more reliably...

Nah, you've got company here... But I'll have to wait until someone's providing an upgrade service, as I can't do the install myself.

I'm offering a limited installation service. Follow-ups to Paul's thread in ForSale forum, please.

We've been juggling half a dozen projects, and haven't had the time to get back to this. I believe we found the problem. Pin 14 of one the chips snapped off while attaching the line to it (apparently very easy to do due to all the bending involved). We dug away some of the package material to expose some of the lead inside, but I don't think it was quite making contact with the lead. We'll dig a little more and pray we don't run into the die.

Stu

Okay, we reattached the lead to pin 14. It seems well soldered. We'vedouble checked the solder joints all check out. What gives? We get:

"Checking for extra DRAM at c1000000: wrote 00000000, read c00e0000 " which obviously means a failure of the extra memory. Can we narrow it down based on this output?

Stu

Which model player? Which Hijack kernel?

It really looks like the chip (which?) that is on the upper 16-bits is still not getting the RAS line signal -- the lower 16-bits are zeros as they should be, but the upper 16-bits are just showing the last address strobe on the bus, as if the chip was not driving data lines. That means no chip select == no RAS.

For Mk2, pin14 should connect to RAS3 on the CPU, for Mk2a it should connect to RAS1.

Both RAM chips should have pin14 (assuming Mk2a) connected to the same CPU RAS line.

Cheers

I suppose the R/W signal could also be the problem on the upper 16-bit chip.

To figure out which chip is which, use an ohm meter to compare the lowest data line on each RAM chip (D0, or possibly D1) to D0 and D16 at the CPU. The faulty chip is the one with D0 (RAM) connected to D16 (CPU).

Cheers

Yes, it's an Mk2A with RAS1 to pin 14 on both chips. Thanks, we'll try the ohm meter thing.

Stu

Okay, sorry for the lack of updates. Doing the above test, the problem chip is the one furthest from the CPU. Does it have to be pin 14 on the chip that's not connected or can it be another pin? Pin 14 on both chips is quite securely connected to RAS 1.

Stu

It could be:

W (pin 13) - write strobe
OE (pin 36) - read strobe
UCAS/LCAS (37/38) - upper/lower byte lane select (less likely)

...or even maybe an address line.

Hugo

Now we get "Checking for extra DRAM at c1000000: wrote 00000000, read c0000000 " as opposed to it reading c00e0000. The only thing we did was put enough solder on the leads to sink a battleship, but I guess it wasn't enough.

Stu

I just spent an hour trying to find my dodgy pins, having refluxed and retouched every pin about half a dozen times. Visually they looked perfect (better than Marks', but I can say that because I don't have a camera capable of taking a nice close up )

Eventually I gave up being lazy, got the meter out and continuity checked each connection. There's enough room to get in there with the probes and test the top pin to bottom pin continuity. It only took me five minutes to verify all the connections and touch up the two that weren't good. Wish I'd done that to start with.