How things could become more difficult...

Posted by: BartDG

How things could become more difficult... - 06/01/2004 05:46

... if an Empeg owner wants to upgrade in the future!!

It seems that Fujitsu has developed the first 2.5" Serial ATA harddisk !

Well, as long as they keep producing the IDE versions too, we should be fine...
Posted by: pgrzelak

Re: How things could become more difficult... - 06/01/2004 05:52

Don't look at me - I just upgraded less than a year ago! Tempting, though...

Seriously, the main bottleneck is the IDE bus speed in the empeg. Even if you could find some way to convert the adapter type, you will not see any benefit from the speed. And we are already starting to hit danger points with the size of the hard drive and available memory in the empeg...
Posted by: Taym

Re: How things could become more difficult... - 06/01/2004 12:46

I remember a thread regarding the possibility to increase the amount of ram memory in an empeg. Not an easy task, I remember, but if that could be done physically somehow (no clue if it it possible theoretically), then probably a software update would not be totally impossible now that through Karma the code is still being developed to a certain extent...
Posted by: foxtrot_xray

Re: How things could become more difficult... - 06/01/2004 13:09


physically somehow (no clue if it it possible theoretically


I really, really hope that it could be done in theory before in all practicality. (Unless you work for my company, which is selling systems for $30k to house nothing more than 50 million phone numbers..) Sheesh.

Me.
Posted by: JeffS

Re: How things could become more difficult... - 06/01/2004 13:41

I really, really hope that it could be done in theory before in all practicality.
Ah, if only the marketing people could understand this . . .
Posted by: Taym

Re: How things could become more difficult... - 06/01/2004 16:01

Sorry guys, my English is sometimes theoretically and practically awful
Posted by: tman

Re: How things could become more difficult... - 06/01/2004 16:56

Adding RAM yourself is something definately not fun if Patrick said it would be difficult to do!

The relevant thread post are here and here.

Basically on a Mk1 it's quite easy as the IC positions are already there on the bottom, just unfilled. The Mk2 is going to be very difficult as you're reaching the limits of the layout and design. The Mk2A however is technically possible but you'd have to stick the extra RAM on top of the existing chips and then wire in the chip select lines directly to the SA.

Another point was that the protected bootloader does the initialisation of the extra RAM. You can't change the bootloader without opening up the player and shorting the write protection points. I think Mark Lord has mentioned in the past that he would probably be able to change the kernel to do the initialisation for the extra RAM but I can't find the post at the moment.
Posted by: Taym

Re: How things could become more difficult... - 06/01/2004 19:28

Thanks Trevor. Interesting threads. Well, definitely not an easy task, maybe in Mark 3....

On that note, have you guys ever found yourself thinking of what you would really like to see in the Mark 3, if it ever ended up being produced?

- Gb Ethernet interface
- WiFi 802.11g
- USB2
- FireWire
- Color LCD Display
- Integrated Radio
- >160Gb HDD (This can be actually achieved easily in few months with current Mark 2, but I was just trying to make this list appealing for Paul too... ).
- Coffee machine.

Ok. I'll stop.

Posted by: Chaosium

Re: How things could become more difficult... - 07/01/2004 01:14

Why, the SATA just means that our large IDE HDDs will be available cheaper
Posted by: pototo

Re: How things could become more difficult... - 07/01/2004 05:03

Has really anything been said about a possible development of a Mark 3 at all?

I know anything is possible but, are the any signs in that direction? I just might have missed something, and since I am willing to get an empeg player (I haven't got one jet and I am new here) it would be nice to know if I have to wait a little bit more, or just for ever

Uf, that list of funtionalities is real good. I had a dream.... too!
Posted by: pgrzelak

Re: How things could become more difficult... - 07/01/2004 05:30

[Lurch]

...you rang...

[/Lurch]

I hate to say it, but one feature I would want in a Mark 3 would be greater ease for integrating it into existing car stereo systems. Cars today are so unfriendly to third party stereo upgrades that you basically have to rip apart the entire dash(sometimes more) to install the system you want.
Posted by: boxer

Re: How things could become more difficult... - 07/01/2004 05:52

Personally, I don't think a mark 3 is the way to go, but better integration with stock HU's is. How about something like the Karma with more gigs (Presumably more gigs in less space is only a matter of time), home and car sleds, the latter with a sophisticated interface with a dashboard display, controls and battery charger: Best of three worlds, home, car and portable.
Ah Well, one can dream!
Posted by: Taym

Re: How things could become more difficult... - 07/01/2004 10:17

Yes, something like that would work well in my view. A simple extra display is better than an entire din slot, in these days. I can't imagine how integrated that would be with the factory system, though. I can imagine a separate system which is however easier to install since it does not require a standard din slot... Which is probably better: I may be underestimating this integration aspect, but when I think of integration to factory systems I think of many limitations on the display info available, commands available, etc. ONe think I always liked of the empeg is the player software itself. I would not want to lose something like that, honestly...
Posted by: Mach

Thoughts of more RAM... - 02/02/2004 11:27

Last year in Amersfoort, adding more RAM was discussed as a what-if conversation. With the use of Alpha5, does the player software issue with the use of the additional RAM go away?

If so, anyone with steady enough hands want to try the add-on at this year's meet?
Posted by: tman

Re: Thoughts of more RAM... - 02/02/2004 11:54

The bootloader isn't changed by upgrades. It's in the bit of the flash that is read only.
Posted by: mlord

Re: Thoughts of more RAM... - 02/02/2004 12:16

I think there were two issues:

(1) bootloader won't "enable" the ram -- fixable in the (Hijack) kernel.

(2) player s/w may not use the extra space (dunno) due to internal assumptions or whatever -- gotta try it and see, I suppose.

-ml
Posted by: Mach

Re: Thoughts of more RAM... - 02/02/2004 22:39

As I understand things, there a 3 issues to solve

1-Physically install the RAM via some soldering magic

2-Flash the boot loader or as Mark suggest solve it in Hijack

3-Make the player software use the extra RAM

AFAIK, the Karma has 32 MB of RAM. V3 software is a branched from the Karma software. So is #3 now solved for the Empeg? Or is there other software that this issue affects?
Posted by: tman

Re: Thoughts of more RAM... - 03/02/2004 02:28

Karma's have 16MB of RAM...
Posted by: Roger

Re: Thoughts of more RAM... - 03/02/2004 02:46

So is #3 now solved for the Empeg?

Not as far as I know. That particular bit of code isn't (IIRC) shared between the two codebases.
Posted by: Mach

Re: Thoughts of more RAM... - 03/02/2004 10:34

Okay wrong again. I'm still would like to get someone to try to add the RAM. I figure the software issues won't get resolved unless a test is made to install additional RAM. Hugo, Patrick, Rob S, Stu? Any interest in trying this?
Posted by: mlord

Re: Thoughts of more RAM... - 03/02/2004 10:58

I know that RobS was working on adding the extra chips to his Mk1 at one point, but I never did get to adding code to "enable" them in Hijack yet.

cheers
Posted by: Mach

Re: Thoughts of more RAM... - 03/02/2004 13:28

Any idea what the reason was? Or rather a question to which I could understand the answer, would the lack of code share cause #1 and #2 to be a lost cause if done?
Posted by: Mach

Re: Thoughts of more RAM... - 03/02/2004 13:32

I vaguely recall him discussing this at Amersfoort. How's the finger feeling these days? Care to do a little "enabling" if someone is agrees to play hummingbird with a soldering iron.
Posted by: mlord

Re: Thoughts of more RAM... - 03/02/2004 14:12

I might give it a go. I wonder if it would be easier to make up a little daughter board for the extra ram..

-ml
Posted by: Daria

Re: Thoughts of more RAM... - 03/02/2004 14:35

What of Karma's has 16mb of RAM?
Posted by: tman

Re: Thoughts of more RAM... - 03/02/2004 14:39

I d'o'n't k'n'o'w. I hear his wheel breaks sometimes tho...
Posted by: Mach

Re: Thoughts of more RAM... - 03/02/2004 15:39

Cool! Stu may have some ideas on the daughter board. I'll wait to see who weighs in on the topic.

I forsee a point where I'll need to do something different when I swap in another 80gb. Syncs are becoming a real drag with continual database rebuilds. I think some of my problems may be associated with how I'm tagging but I'm reluctant to re-edit tags and resync again. Is there a way to check how much memory my tags are using up?

Thanks-A
Posted by: maczrool

Re: Thoughts of more RAM... - 03/02/2004 18:53

Hmmm. a daughter board, well it would certainly require some support circuitry I would think. I doubt if the lines to the memory chips would be able to drive the cable leading to the daughter board without some kind of buffer arrangement at a minimum. Maybe I'm all wet, but I say stick with direct soldering.

Stu
Posted by: pgrzelak

Re: Thoughts of more RAM... - 03/02/2004 19:06

Hmm... Random thought...

We have seen folks rig up an IDE -> CF interface. Would it be possible / practical to have a CF memory card installed and use it as swap space, configuring the swap to load as part of the boot cycle?

Granted, I would not be willing to sacrifice an IDE drive...
Posted by: tman

Re: Thoughts of more RAM... - 03/02/2004 19:28

Flash memory has limited erase cycles so you'll wear it out quite quickly if you're using it as swap.
Posted by: altman

Re: Thoughts of more RAM... - 04/02/2004 05:21

Yup. You could put some SRAM or maybe SDRAM+controller on the IDE bus and use this for swap (I think this is what some of the TiVO expansion boards do) but really you just want more RAM.

On a Mk2a you should be able to solder two more EDO RAM chips ontop of the existing ones, with every pin common apart from pin 14. Pin 14 of both chips needs to be taken via white wire to pin 123 of the StrongARM. Bingo! Another 16MB of RAM (total 32).

I suspect that the main board is over-decoupled enough to support this.

Hugo
Posted by: tman

Re: Thoughts of more RAM... - 04/02/2004 05:35

The original TiVo cachecard did work by putting RAM onto the IDE bus and then using the RAM to cache requests for the database. The guy designing it found that it wasn't very reliable and greatly impacted performance as it would interfere with DMA. I guess this wouldn't really affect the empeg as it doesn't use DMA anyway.
Posted by: altman

Re: Thoughts of more RAM... - 04/02/2004 05:53

I've just tried this technique on a dead rio receiver; the trick is to straighten the pins as much as possible before bending them hard down. This way, they stick out the bottom enough that soldering the "sandwich" is very easy with a little SMT flux. Only takes 5 minutes or so per chip including bending time.

I was about to take my unit apart to try it when I remembered I have a mk2, not a mk2a. Doh! In theory I could add another 4MB to this to take it to 16, but it's not quite as fun as an extra 16MB!

Hugo
Posted by: tman

Re: Thoughts of more RAM... - 04/02/2004 05:55

Interesting... I'll have to see if I dare do this on my backup empeg
Posted by: pgrzelak

Re: Thoughts of more RAM... - 04/02/2004 06:04

Stu? Mark? Anyone interested in giving this a shot? Granted, this still assumes a lot, like the kernel being updated to support the extra RAM and the player being able to use it. But it could be an interesting experiment...
Posted by: BartDG

Re: Thoughts of more RAM... - 04/02/2004 06:11

It sure would mean you could also do the next harddisk upgrade, and get way with it!
Posted by: pgrzelak

Re: Thoughts of more RAM... - 04/02/2004 06:17

It sure would mean you could also do the next harddisk upgrade, and get way with it!

It would help. It would not answer all of the potential issues, but it would help...
Posted by: Shonky

Re: Thoughts of more RAM... - 04/02/2004 06:29

I've triple stacked RAM on one of our products boards for development purposes. What sort of package are the EDO DRAMs in a Mk2a?

Hugo, are they easy enough to obtain? Assuming you've decoupled adequately and I'm sure you have, I very much doubt it will be a problem.

Basically I'm willing to have a go.
Posted by: mlord

Re: Thoughts of more RAM... - 04/02/2004 08:31

I'm keen to have a go at this. I will definitely get enough chips to do 2 or three of my own units here as well.

Anybody got a Digikey part number for the chips?

Cheers
Posted by: mlord

Re: Thoughts of more RAM... - 04/02/2004 08:34

>It would help. It would not answer all of the potential issues, but it would help...

I suppose once I polish off the current contracts here, I could be coerced into making up a new diskbuilder package to remove any limitations from that part of the process. Heck, I think that nearly all of what it does can be done without much fuss (or much added code) from Hijack.

Cheers
Posted by: peter

Re: Thoughts of more RAM... - 04/02/2004 08:44

I'm keen to have a go at this. I will definitely get enough chips to do 2 or three of my own units here as well.

Anybody got a Digikey part number for the chips?
How many chips do you get on one of those sodding big 18in tape reels for feeding SMT production lines? Because that's how many spare ones we've got. It might not be too hard to persuade Hugo to turn up to Amersfoort with a couple of yards' worth. At 2Mb or 4Mb a pop, or whatever, it's not like they're useful for anything else.

Peter
Posted by: mlord

Re: Thoughts of more RAM... - 04/02/2004 09:06

Ahh.. good potential there!

Any chance of snipping off 3-4 10cm lengths from that reel, dropping them into an envelope, and entrusting the Royal Mail to get them over to Dominion-land here?

Cheers
Posted by: wfaulk

Re: Thoughts of more RAM... - 04/02/2004 10:04

I don't know why that made me think of this, but I ran across, down here in North Carolina, a Canadian quarter recently, which happens from time to time, but the face of this particular one had George VI on it. Ooooold.
Posted by: loren

Re: Thoughts of more RAM... - 04/02/2004 11:53

I'm so very down for giving this a go.
Posted by: JrFaust

Re: Thoughts of more RAM... - 04/02/2004 12:13

Sorry I must be a bit slow but what issues might more ram in the empegs fix?
Posted by: peter

Re: Thoughts of more RAM... - 04/02/2004 12:25

Sorry I must be a bit slow but what issues might more ram in the empegs fix?
12Mb - can run v3 players. 16Mb - can run debug v3 players, or have a Kanji font, or have more caching so the disk doesn't spin up so often. More than that - can run debug v3 players with a Kanji font, or just have lots more caching. And the more files there are on the player, the bigger the database is, and the more memory it takes up (at the expense of caching).

Peter
Posted by: mlord

Re: Thoughts of more RAM... - 04/02/2004 12:47

No big issues for most of us, other than more buffer space so that the drives don't have to spin as often (safer for the drives that way, in the car).

But for perhaps 20-50 of us, the extra RAM will allow us to have the empeg doing much more than just play music to itself..

Eg. alternative playlist browsers, fancier web applets, on-the-fly database updates (no more 10 minute rebuilds, yay!). Etc.

Cheers
Posted by: Mach

Re: Thoughts of more RAM... - 04/02/2004 13:44

It'll go to 11.

Cool, cool, cool. So playing out the what ifs. If the RAM sandwich works and then Mark works his magic with hijack. Is that it or does the player software need to be changed in some other way?

Shonky's comment about the triple stack is interesting. What's the physical limit on trying something like multiple stacks? Just curious as to what the boundaries would be to expansion.

A
Posted by: mtempsch

Re: Thoughts of more RAM... - 04/02/2004 14:57

It'll go to 11.

LOL!

/Michael
Posted by: image

Re: Thoughts of more RAM... - 04/02/2004 15:08

Sorry I must be a bit slow but what issues might more ram in the empegs fix?
it'll go to 11.
that just went over my head. was it an inside joke that requires study of both user's previous posts, Mach wasn't really replying to JrFaust's post, or am i out of it today, humorwise?
Posted by: genixia

Re: Thoughts of more RAM... - 04/02/2004 15:14

It'll go to 11.

You don't need extra memory to do this.
Posted by: Mach

Re: Thoughts of more RAM... - 04/02/2004 15:31

It's one Louder
Posted by: Mach

Re: Thoughts of more RAM... - 04/02/2004 15:32

too funny.
Posted by: Aragon

Re: Thoughts of more RAM... - 04/02/2004 16:54

I'm semi keen to give this a shot. But I'm an Mk2 owner. Is my only option to upgrade to 16 meg? Would this also involve the sandwich trick or replacing the existing chips?

Anyone know what component(s) on the Mk2 limit it from being upgraded to 32 meg?


Thanks,
Aragon
Posted by: altman

Re: Thoughts of more RAM... - 06/02/2004 08:37

The StrongARM can support 4 banks of EDO DRAM. The models are:

Mk1: 8MB fitted (2 banks of 4MB, 2 chips per bank). Easy to go to 16MB as there are pads on the underside of the board for another 4 chips (2 banks). Needs kernel mod to enable the memory, but this can almost certainly be done within the existing kernel as the kernel sits at the base of physical memory.

Mk2: 12MB fitted (3 banks of 4MB, 2 chips per bank). No spare pads. You could piggyback on one of the banks and get 16MB, adding bank 4.

Mk2a: 16MB fitted (one bank of 16MB, 2 chips per bank). You could piggyback up to 3 sets of chips (given enough vertical space; HDD interference might be a problem) to give you up to 64MB of RAM.

The Mk1/Mk2 chips are 1M x 16. I have shedloads of these (at least 1000 pcs), though you need to run the RAM test on them as maybe 1 in 50 seem to be bad. TSOP-42, with a gap in the pinning at the middle. I doubt you can buy these anymore. Incidentally, you could also use these to get 8Mbytes on a Rio Receiver.

Mk2a are 4M x 16. I have some of these (maybe 100pcs). TSOP-50 package. I think you can still find these about - micron list them as obsolete though. You need the 4k refresh variant (it can't support 8k refresh chips) - they're the same chips as used in the original TiVO memory upgrade, and so are available from http://www.9thtee.com/tivomemory.htm - this is probably the easiest place to get them, and they don't charge the earth for them either ($20). I may try and get some of these chips to someone who might want to do this sort of upgrade (maczrool?) but can't really just send them out individually as it'd take up a bit of time packaging them, as they're in a tray, not on tape.

Note! I've NOT tried this myself yet, but I don't see why it wouldn't work. The only change required is setting the necessary bits at the bottom of MDCNFG (bit 0=bank 0, bit 1=bank 1, etc).

Hugo
Posted by: Mach

Re: Thoughts of more RAM... - 06/02/2004 09:47

Thanks for the info and the link, Hugo. Time to order some ram.

PS - If you are forwarding ram, could you also forward some to mlord?
Posted by: mlord

Re: Thoughts of more RAM... - 06/02/2004 12:04

Hugo,

I am very interested in performing this upgrade to my own (3) Mk2a players as well as to those of others on the BBS. If you can spare 20 or so chips for here, that would likely suffice.

Cheers
Posted by: pgrzelak

Re: Thoughts of more RAM... - 06/02/2004 12:10

Greetings!

I am certainly interested in having it done as well!!!
Posted by: BartDG

Re: Thoughts of more RAM... - 06/02/2004 12:42

Yes, same here, for my three players too !!!
Posted by: genixia

Re: Thoughts of more RAM... - 06/02/2004 13:08

By the time you've done yours, Paul's and Robric's you'll need more...
Posted by: Shonky

Re: Thoughts of more RAM... - 06/02/2004 20:24

Hugo,

Is the micron part a MT4LC4M16R6 (12 rows, 10 columns) or MT4LC4M16N3 (13 rows, 9 columns)?

http://www.micron.com/products/dram/edofpm/part.aspx?part=MT4LC4M16N3TG-5
http://www.micron.com/products/dram/edofpm/part.aspx?part=MT4LC4M16R6TG-5
Posted by: maczrool

Re: Thoughts of more RAM... - 06/02/2004 20:26

If we can get the RAM we'll do the upgrades.

Stu
Posted by: canuckInOR

Re: Thoughts of more RAM... - 06/02/2004 20:49

I'll wait to see how yours turns out, before I send/bring mine up.
Posted by: Mach

Re: Thoughts of more RAM... - 07/02/2004 01:54

From Hugo's link, http://www.9thtee.com/tivomemory.htm, it looks like it's the MT4LC4M16R6TG-5.

Posted by: Shonky

Re: Thoughts of more RAM... - 07/02/2004 22:48

Yeah I looked at that picture and didn't see a normal looking part number. Then I went to the Micron page and found those two chips. Just didn't put 2 and 2 together.

Time to place an order methinks.
Posted by: Daria

Re: Thoughts of more RAM... - 07/02/2004 22:54

Indeed, if I could have 64mb I'd have an mDNS responder, a custom fileserver, and a few other goodies on the unit.

Sadly, I don't solder things which are that small, or I get a smoking pile of silicon.
Posted by: Taym

Re: Thoughts of more RAM... - 07/02/2004 23:01

I am totally interested too! I'll be very very happy to go up to 64Mb!
Posted by: Shonky

Re: Thoughts of more RAM... - 07/02/2004 23:11

Except shipping to Australia costs US$25! i.e. more than the actual chips themselves Although it's not that much money, I have issues with expensive shipping.

Anyone in AU/NZ want to share shipping costs?
Posted by: pgrzelak

Re: Thoughts of more RAM... - 17/02/2004 18:05

Greetings!

I refuse to let this thread pass into obscurity! To that end, I have ordered a few of the TiVo upgrade kits. LabRat will be experimented upon (I have already been in touch with one mad scientist in the US about this), and if it works I will be upgrading them all.

Some thoughts / questions for the more enlightened among us:

a) Given that the player is really only designed for 16MB (Mark2A), would there be much of a difference between / advantage in using 32, 48 and 64MB of RAM?

b) Is there any known physical limitation on the placement of the chips, limiting to one upgrade (32MB), or can three upgrades be added (64MB)?
Posted by: Shonky

Re: Thoughts of more RAM... - 17/02/2004 18:43

The main limit will be a physical limit. Hugo mentioned that stacking them too high might hit the drive tray.

Also there is the tolerance level of stacking chips 4 high. I have done chips 3 high and it was a tough job. These are different memory chips though to what I was using. The ones I used didn't stack very well.

IMO unless you are running a big custom app, 32MB should be ample - even for yourself. Remember this will do much more than double the space available for the database. The original 16Mb includes the kernel, player software etc. leaving somewhere around 8Mb possibly (on a Mk2a, 4 for a Mk2) for the DB. So adding an extra 16Mb will at least triple your potential playlist/database size.
Posted by: pgrzelak

Re: Thoughts of more RAM... - 17/02/2004 18:45

Cool!
Posted by: genixia

Re: Thoughts of more RAM... - 17/02/2004 22:09

I did some experimenting with an old laptop SIMM this weekend - using a hot air gun to pull some of the chips and then stacking them upon others. With a suitable iron, patience, and lots of flux, the second chip isn't too difficult(*) to solder. A third chip however is a bitch, as Shonky has alluded to. It's not even just getting the pins lined up and soldered - the CS pins need to be broken out of the stack. With only the second chip you just bend it up and solder the wire to it. You cannot easily do that when you need to stack a third chip on top - the best you can do it bend it straight out, but now you're soldering a 3D jigsaw with a 0.05" pitch. It adds a whole level of complexity and risk to a project that is already risky. I think I'll stick to 32MB when I do mine.

One issue that I haven't really resolved yet is how to straighten the pins effectively. Even after using an old DIP chip pin straightener to clamp and straighten the pins, they still have a curve to them. Any hints Shonky?

(*) "not too difficult" all being relative.
Posted by: adavidw

Re: Thoughts of more RAM... - 17/02/2004 22:39

Is there any legitimacy to the idea of wiring the second, third, and fourth chips in sequence on a board, and then wiring that board to the onboard chip (the old daughterboard upgrade)?
Posted by: Shonky

Re: Thoughts of more RAM... - 18/02/2004 02:37

Yes 32Mb should be enough anyway. I don't normally have too many problems with the extra pin. The main problems I have had are that the pins from the chip above don't physically reach the pins of the chip below. So you're stuck trying to build a solder bridge and that's not how soldering is supposed to work. Not sure whether this will be the case here though.

One issue that I haven't really resolved yet is how to straighten the pins effectively. Even after using an old DIP chip pin straightener to clamp and straighten the pins, they still have a curve to them. Any hints Shonky?
I usually use small needle nose pliers. You can usually grab ten or so pins at once and bend them all together straightening the bend that's already there.
Posted by: Shonky

Re: Thoughts of more RAM... - 18/02/2004 02:42

Is there any legitimacy to the idea of wiring the second, third, and fourth chips in sequence on a board, and then wiring that board to the onboard chip (the old daughterboard upgrade)?
Legit yes. Crazy yes.

Apart from the EMC type issues there's mounting the daughter board plus wiring every single pin by hand from the original RAM chips to the daughter board. Something like 56 wires. Don't think so.

If you could figure out a neat way to attach a daughterboard directly to the RAM, you might be in with a chance. But that would be impossible to solder I believe.
Posted by: loren

Re: Thoughts of more RAM... - 18/02/2004 02:48

Hm. Too bad there's not some sort of clamp on socket for something like this... guess it isn't needed all that often though eh?
Posted by: tman

Re: Thoughts of more RAM... - 18/02/2004 11:54

Yep. You can get SMD test clips but they're expensive and also large.
Posted by: belezeebub

Re: Thoughts of more RAM... - 18/02/2004 12:21

I am surprised one of you soldering Gods hasn't removed All the memory and retro-fited a SODIMM Socket to your empeg's

then you could add as much ram as the system could take all the way from 8 to 1Gig
and it mounts horizonal so space wouldn't be too bad.
Posted by: belezeebub

Re: How things could become more difficult... - 18/02/2004 12:23

Photo of a SODIMM socket
Posted by: peter

Re: Thoughts of more RAM... - 18/02/2004 12:25

Time to place an order methinks.
It's best pointed out that Hugo hasn't yet persuaded his dokt3red player to start the kernel properly, so folks might like to hold off until we can figure out why not, and whether there's a fundamental problem he hadn't thought of.

Peter
Posted by: Shonky

Re: Thoughts of more RAM... - 18/02/2004 14:55

It's best pointed out that Hugo hasn't yet persuaded his dokt3red player to start the kernel properly
I didn't see anything about him trying it on a real player - only on a dead receiver since he has a Mk2. Has he tried it on a real and previously working Mk2a?

Although I said it, I didn't actually get around to ordering anything yet. pgrzelak said he ordered some though.

Thanks for the heads up.
Posted by: pgrzelak

Re: Thoughts of more RAM... - 18/02/2004 17:25

Greetings!

I always try to be on the lunatic forefront / bleeding edge of things. If it works, great! If it doesn't work, I am sure that someone will figure it out sooner or later.
Posted by: mlord

Re: Thoughts of more RAM... - 18/02/2004 20:31

I'm with Paul. Most definitely this will be made to work!

Cheers
Posted by: adavidw

Re: Thoughts of more RAM... - 18/02/2004 21:51

I guess I'm remembering the old days when chips would stick up a half inch off the board, and the pins were a couple of millimeters across. I seem to remember some sort of daughterboard upgrades for something that actually did snap on the original chip like that.
Posted by: andy

Re: Thoughts of more RAM... - 21/02/2004 19:33

At the London meet tonight Hugo admitted to having got 16Mb of RAM working on a MK2a. It required a change to the kernel (and possibly even the player, can't remember), where he had put in a quick memory size = hardware revision hack in the past.

Hopefully Mark will be getting a nice email with some Hijack patches in in the future...

Sorry Hugo

P.S. Hugo was entertained to hear of Mark's "guess the player binary version by the file size" code...
Posted by: pgrzelak

Re: Thoughts of more RAM... - 22/02/2004 09:14

See?!?! The memory upgrades have not even arrived with 2nd day air shipment, and already the problem is identified, and it is likely a patch will be issued. I knew that someone would work it out...
Posted by: brendanhoar

Re: Thoughts of more RAM... - 22/02/2004 11:05

> At the London meet tonight Hugo admitted to having got 16Mb of RAM working on a MK2a.

That's sort of funny because I thought all MK2a's already had 16MB...

-brendan
Posted by: andy

Re: Thoughts of more RAM... - 22/02/2004 11:14

That's sort of funny because I thought all MK2a's already had 16MB

Well spotted. I expect I probably meant that Hugo had added 16MB to a Mk2a...
Posted by: peter

Re: Thoughts of more RAM... - 22/02/2004 14:38

Well spotted. I expect I probably meant that Hugo had added 16MB to a Mk2a...
Unless he did that in the train on the way down, I think you meant he upgraded a Mk2 (not 2a) to 16Mb, which is what he did last week!

Peter
Posted by: andy

Re: Thoughts of more RAM... - 23/02/2004 01:42

Unless he did that in the train on the way down, I think you meant he upgraded a Mk2 (not 2a) to 16Mb, which is what he did last week!

Doh ! Well, we all know how talented he is...

Sorry to get everyone's hopes up. I suspect the issue over the fix to the kernel/player assuming memory size tells it something about which hardware revision it is running on still apply though.
Posted by: altman

Re: Thoughts of more RAM... - 23/02/2004 07:29

Yes, but that's probably fixable with some lines in config.ini, for example, to increase the amount of memory the player thinks it has - sort of a negative cache reserve line, as you might want space kept aside for other tasks running on the player.

I can confirm that a correctly modded kernel lets my MkII be 16MB with no problems.

Stacking multiple chips will run into the drive cradle, which is a bit of an issue. One thing that currently worries me is the select line, which goes to the StrongARM and the two stacked chips, and it looks pretty fragile and susceptible to being whacked by the drive cradle. Needs some sort of protection from this (above the couple of bits of insulation tape I'm using!)

Hugo
Posted by: pgrzelak

Re: Thoughts of more RAM... - 23/02/2004 07:31

/me grabs pencil and starts taking notes... Thanks!
Posted by: mlord

Re: Thoughts of more RAM... - 23/02/2004 08:09

MM.. a few drops of hot melt glue might be a low-tech solution to securing the chip select wire.

Got a kernel patch for me?

Cheers
Posted by: altman

Re: Thoughts of more RAM... - 23/02/2004 08:32

I HMG'ed it already, the tape helps the tray not to catch on the glue!

No kernel patch, no, it needs doing properly, and I've not done it properly. Fancy doing it properly for me? (I'm not likely to get round to doing it for a few weeks, seeing as my player was dead and out of the car for almost 2 weeks until I got round to looking into why the 4MB upgrade wasn't working!)

It just needs to determine bank size (either by hwrev or by test writes) and then check if each bank is present before telling the kernel (a) the phys/virt mapping and (b) the total RAM size.

You also need a new e000.rom, as the RAM banks need to be enabled before the CPU is running out of RAM. This is attached, if it seems ok for people (./download e000.rom e000) I'll make sure it gets into in future releases.

I don't believe there are any problems with enabling banks that aren't there. It'll try to refresh them, but I doubt this will hurt anything. The attachment turns on all banks for mk2's and the bottom 2 banks (64MB) for mk2a's.

Hugo
Posted by: mlord

Re: Thoughts of more RAM... - 23/02/2004 08:50

Any chance of an e000.rom that doesn't ignore the serial port on DC power?

That way people could do serial upgrades while in a home dock.

Cheers
Posted by: mlord

Re: Thoughts of more RAM... - 23/02/2004 09:00

I just now installed the updated e000.rom file onto one of my MK2A players here, and it does not seem to have had any ill effects.

Here's a really easy way to install this on a Hijacked player:

ftp your.player.ip.addr
put e000.rom /proc/flash_0e000
site sync
quit

Note that the version number is still 1.04, even though the contents have changed. I verified correct programming by reading it back (from /proc/flash_0e000) and comparing with the original and uploaded ROM contents.

Cheers
Posted by: altman

Re: Thoughts of more RAM... - 24/02/2004 13:25

Sorry, that part isn't in e000, that part is in 0000 (ie, the protected bootblock). You can upgrade this if you fit the link, but if you mess this up then the player is toast without desoldering the flash...

Hugo
Posted by: Yonzie

Bump - 10/03/2004 10:56

So... To upgrade my mk2a to 32MB, I'll need to get two of these chips:
http://www.micron.com/products/dram/edofpm/part.aspx?part=MT4LC4M16R6TG-5
from here:
http://www.9thtee.com/tivomemory.htm
or from Hugo.
Pin 14 on the RAM goes to pin 123 on the ARM. Easy.

Now... to upgrade my mk1 to 16MB, I'd just need to solder on 4 additional chips in the existing spots, but since there's less than 400 mk1's in existence and mine will be pretty unique, the chance of it actually being useful (like v3/kanji support and not just caching and a massive db) is extremely slim.
Regardless, I'll volunteer my mk1 to test this out. I'm not into software hacking though, so I'll need a bit of help with that. Mark, you stated something about a hijack hack?

Hugo, how much will 8 mk1 chips be w/shipping to denmark? How would I go about testing for duds?

I'm thinking it should be possible to upgrade a mk1 (and a mk2(a)) to 64MB or more, if I replaced all of the RAM chips... I can't exactly say I know anything about this, but shouldn't it be possible to replace 2x 16bit wide chips with 4x 8bit wide chips?
Posted by: pgrzelak

Re: Bump - 10/03/2004 11:04

Please note:

I ordered a bunch of sets from 9th Tee - enough for my own players and for both Stu and Mark to play with. Other than the automated reply, I have not heard any confirmation or email back, even with multiple email attempts to contact them. I would wait on ordering from them until I can confirm if they are still around.

EDIT: Reviewing the site and link again, I see that they are now listed as out of stock until April 1st. It could be that my order wiped him out and more, and that he is waiting for a new shipment. An email letting me know would have been nice, but I feel a bit better now.
Posted by: Mach

Re: Bump - 10/03/2004 15:02

Interesting. I ordered 3 sets on 2/23 and they shipped the next day. UPS confirms them as delivered but I haven't had a chance to pick them up. When did you place your order?
Posted by: pgrzelak

Re: Bump - 10/03/2004 17:05

Interesting. I ordered 3 sets on 2/23 and they shipped the next day. UPS confirms them as delivered but I haven't had a chance to pick them up. When did you place your order?

February 17th. But there is a slight difference...

...I ordered twenty sets...

<running for cover>
<diving>
<shouting from behind barricade>

I told you I ordered a bunch for all my players, some for some folks I know on the board, plus some for Mark and Stu to play with... Why do people keep insisting on dealing with me as if I was a normal, sane individual???
Posted by: Mach

Re: Bump - 10/03/2004 17:45

Oh to have been in 9th tees office when they received that order. I'm guessing from the numbers that you're planning on maxing out to 64 MB if possible?

As to normal and sane, how's the 8 ball undertaking progressing?
Posted by: pgrzelak

Re: Bump - 10/03/2004 18:05

...to have been in 9th tees office when they received that order...

Indeed! That must have been pretty funny. Especially when it was a PayPal prepaid! I can imagine jaws hitting the floor - where would we get the chips?!?!? What is he *doing* with these? I did explain in the message field of the order that the memory would (likely) work to expand the empeg, with a very brief description of what the empeg is.

...planning on maxing out to 64 MB...

Well, I was leaving the option open, but I think it will be physically difficult to do with the install, and mostly unnecessary. This is based on the previous discussion of how much memory is possible / practical. Doubling the RAM should really help life without making it impossible to install.

8 ball / insanity

The final proofs have been approved and submitted. The bill has been paid. I expect them to be completed by late March, with shipping of the bulk of them taking an additional four weeks to arrive in late April. I am having a small batch (say, 25) of them shipped express, so I can show them around.

Many thanks to everyone who submitted ideas for the artwork. While many of the ideas were good, and the best submitted idea being this one by Erlend (Archeon), I wanted something that was much simpler graphically, more basic and plain. I went with my original idea, "binary" and all. They did a slightly blurry mock up for me.

I hesitate to post the answer sheet on here. It is not that everyone has not seen it a few times, but I don't want anyone to find a typo at this point. It is too late to change, I reviewed it many times and had others review it as well. Anything found now means significant problems and expense to correct. So, you will have to wait until they ship!

More will be posted in the For Sale forum when they are ready.
Posted by: Mach

Re: Bump - 10/03/2004 18:32

Cool! They look good. I'll keep a watch on the For Sale forum.
Posted by: CHiP

Re: Bump - 12/03/2004 02:00

sounds like maybe Stu can get a hold of some of these chip, and offer an upgrade service? I would be interested in upgrading my mk2a from 16mb to 32mb since my database is growing quite large, i have 120 gig, but only filled about 55 gig
Posted by: CHiP

Re: Bump - 12/03/2004 02:05

How neccessary is it to upgrade to 32 meg? The only reason i see to upgrade would be to cash more of the tunes, so the hard drives wont have to spin up as often, and to hold a larger database (sounds like there is a limit to the size you can have). I guess the main reason would be that after running custom apps, you might run out of space.... I'm basically asking, at what point do you NEED an upgrade from 16mb to 32, or 64 on a mk2a?? My guess is only if you're running some kind of application that uses a lot of memory (relative to how much is left).
Posted by: pgrzelak

Re: Bump - 12/03/2004 05:59

Greetings!

I think 32MB will be enough. I ordered the big batch mainly a) to have enough for my players, b) to have enough for a few other people I ordered for, c) to give Stu and Mark some samples to experiment with. I doubt I will push beyond 32MB.

As to why, I can always answer "because it can be done", but that is too easy. Basically, I am pushing the envelope on memory. 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.

I would recommend trying for more memory:

a) if you are running multiple third party applications on the player
b) if you find you need to tweak the ReserveCache option in config.ini
c) you cannot sync or fsck your drives without turning swap on
d) you are building an 80GB drive in a Mark2
e) your hard drives do not spin down because the player application does not have enough cache space

That would be my rough recommendations. Of course, this upgrade is still not proven yet. It is still experimental. And even my player still functions fine with 16MB. But I am looking forward to a day of 100GB+ drives, and I really prefer not having to think about memory use all the time.
Posted by: pgrzelak

Re: Bump - 14/03/2004 17:52

Damn.

My order was just cancelled / refunded. Apparently, 9th Tee can no longer get the chips because the manufacturer discontinued them.
Posted by: altman

Re: Bump - 15/03/2004 08:11

Ah. That's the problem with EDO DRAM chips. You really don't want to steal chips from (eg) a SIMM because the mounting is hard enough with brand new chips - with pulls it'd be even more frustrating.

Hitachi parts are ok too (the same type as are already on there) if that helps.

Edit: just found these guys:

http://www.memphis-electronic.com/datasheets.htm

...who appear to be making EDO DRAM... ie, a current product. Looking at their datasheet, it would also appear to be *the Micron part* (ie, the datasheet has Micron crossed out and Memphis written on it in crayon).

The part number is 4X16E43VTW-5 I guess. You need the 4k refresh model. Might be worth telling the Tivo guys about this stuff too, it'd work there...

Hugo
Posted by: CHiP

Re: Bump - 15/03/2004 16:55

can we start a list of people interested in this hack, so someone can order a bunch of chips for everyone. I'm willing to prepay someone if they can get the chips. Then hopefully the software will be updated to support the new memory, and stu can do the install.

I'm interested!
Posted by: genixia

Re: Bump - 15/03/2004 18:14

I've got an RFQ in at usbid.com for the Micron part number.
Posted by: pgrzelak

Re: Bump - 15/03/2004 19:19

I would certainly be interested in a good batch of them, if you get any offers.
Posted by: julf

Re: Bump - 16/03/2004 04:22

Likewise, both for my empegs and my tuxscreens/shannons
Posted by: maczrool

Re: Bump - 17/03/2004 19:48

We can get them too if needed. We'd have to submit an RFQ to find out the terms, but they are available.

Stu
Posted by: maczrool

Re: Bump - 30/03/2004 20:39

Okay, we're ready to do the memory upgrade on an MK2 but we're not quite clear on how to proceed. We've got the memory from Hugo. It sounds like we need to solder 4 additional chips to the player as they are supposed to be 1 MB each (as I understand it). Reading back from Hugo's posts, the MK2 has 3 banks comprised of 6 chips (apparently 2 MB units). He says "you could piggyback on one of the banks and get 16MB, adding bank 4." Meaning to me that we need to stack 2 chips on top of 2 of the stock chips. Is this correct? If so, which 2 stock chips can the stacks go on? Any 2, any adjacent 2 or what? It also sounds to me like a special modified kernel is needed. Will the player work normally without this kernel?

Thanks,
Stu
Posted by: mlord

Re: Bump - 30/03/2004 22:40

The Mk2 (not Mk2a) chips are 2MBytes/chip, as per Hugo's posting way earlier in this thread.

Cheers
Posted by: maczrool

Re: Bump - 31/03/2004 08:16

The Mk1/Mk2 chips are 1M x 16. Doesn't that make them 1MB?

Stu
Posted by: sn00p

Re: Bump - 31/03/2004 08:35

No! 1M * 16 is 2 megabytes.

Adrian
Posted by: mlord

Re: Bump - 31/03/2004 08:54

1MB = 1 megaByte = 8-bits times one million (1024*1024). These chips have 16-bits times one million, so therefore two megabytes.

Cheers
Posted by: maczrool

Re: Bump - 31/03/2004 09:03

For some reason I was thinking 16 bits. Alright so only two chips are needed. Do they stack one layer high on two different OEM chips on the MK2? Which two? any adjacent two. Any kernel needed?

Thanks,
Stu
Posted by: altman

Re: Bump - 01/04/2004 16:12

You need to put one chip on each of the two RAM chip nearest the CPU (no particular reason for thair pair - it has to be a side-by-side pair though as each chip covers half the databus).

You need to bend up the CS pin on both of these chips and wire them together and to the 4th DRAM bank select pin on the CPU. Sorry, I'm at home and don't have the datasheets on my laptop so I can't be more accurate about which pin numbers... I have pictures of mine to upload too...

I'll try to remember to do this tomorrow.

Hugo
Posted by: Glen_L

Re: Bump - 05/04/2004 13:08

Bump for any helpful pics or any info regarding a kernel update. Really hoping to have my upgraded empeg back by my birthday this Saturday
Posted by: maczrool

Re: Bump - 05/04/2004 15:07

I ordered 31 chips for the MK2A just to let everyone know. Most of them are already spoken for though.

Stu
Posted by: maczrool

Re: Bump - 13/04/2004 10:08

As soon as we know what the pins on the memory and CPU are for the MK2, we'll be ready to solder the upgrade in place.

As I understand it, to get 32 MB of total RAM into the MK2A we should have one 8 MB piece piggybacked on top of each of the two OEM memory chips, with pin 14 of each chip soldered ONLY to pin 123 of the StrongARM CPU. Is this correct? If so, we're ready to go on an MK2A as well.

Thanks,
Stu
Posted by: K447

Re: Are MK2a memory chips still available? - 18/04/2004 09:55

I have a pair of Mark 2a RioCar units that I would be interested in upgrading. I can handle the soldering involved.

How do I get in line for two pairs of 16MB upgrade chips?

I understand the related software issues are still being worked out (with some risk that a snag may arise).

Keith
Posted by: maczrool

Re: Are MK2a memory chips still available? - 18/04/2004 10:27

PM me.

Stu
Posted by: maczrool

Re: Are MK2a memory chips still available? - 18/04/2004 12:22

We've done the upgrade on an MK2, but we have no idea if the memory is good/bad/functional or not. Is there anyway to tell? We ran the RAM test and got the standard screen with everything passing and no additional memory showing. Do we need a special kernel for it to show up even in RAM testing? The player works fine by the way.

Stu
Posted by: wfaulk

Re: Are MK2a memory chips still available? - 18/04/2004 12:42

If you mean the Ctrl-T thing, I'm pretty sure that's firmware that bypasses the regular boot process. I don't think it ever gets to the kernel. You'd have to rewrite the RAM test application altogether and then upload it to the flash, and that area may be write-protected.

That being said, folks have claimed that a new kernel would be required to get the player to use the additional memory once booted normally. The kernel should produce some output on bootup in regards to the amount of memory it sees. What do you see there?
Posted by: maczrool

Re: Are MK2a memory chips still available? - 18/04/2004 12:52

This is what we got:
empeg-car bootstrap v1.00 20000601 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now, or forever hold their peace...
0000 empeg-car board test version 0.04
0100 ram test starting
0110 testing ic 1 (0-3mb, low word)
0120 testing ic 2 (0-3mb, high word)
0130 testing ic 3 (4-7mb, low word)
0140 testing ic 4 (4-7mb, high word)
0150 testing ic 19 (8-11mb, low word)
0160 testing ic 32 (8-11mb, high word)
01f0 ram test done
0200 ide detect
0210 command issued
0220 drive id IBM-DARA-206000
02f0 ide ok
0300 dsp/i2c test
03f0 dsp/i2c ok
0400 temperature detect
0410 temperature is 27
04f0 temperature ok
0500 usb detect
0510 usb rev 1012
05f0 usb ok
0600 ethernet detect
0610 ethernet rev 334b
06f0 ethernet ok
0700 cs4231 detect
0710 cs4231 rev a0
07f0 cs4231 ok
00f0 tests complete
Posted by: tman

Re: Are MK2a memory chips still available? - 18/04/2004 13:03

The RAM test by the looks of it is hardcoded for a specific amount of RAM as it mentions specific IC numbers.
Posted by: wfaulk

Re: Are MK2a memory chips still available? - 18/04/2004 16:53

Exactly. What does the normal bootup say?
Posted by: mlord

Re: Are MK2a memory chips still available? - 18/04/2004 16:57

There was a posting somewhere from Hugo with a FLASH update that he needed .. I've forgotten if it was applicable to Mk2, or only to Mk2a.

And a kernel update will be needed from Hugo or Me.

Cheers
Posted by: tman

Re: Are MK2a memory chips still available? - 18/04/2004 17:03

The kernel is told a specific memory size by the protected bootloader. "Command line: mem=16m"
Posted by: mlord

Re: Are MK2a memory chips still available? - 18/04/2004 21:13

Yup, that might be useful as well as the update to enable the memory selects.
Posted by: maczrool

Re: Are MK2a memory chips still available? - 19/04/2004 21:38

Just thought I'd post a picture of our MK2 upgrade work.

Stu

Posted by: mlord

Re: Are MK2a memory chips still available? - 20/04/2004 07:21

Very pretty!

What kind of soldering equipment do you use? Hot air?

Cheers
Posted by: maczrool

Re: Are MK2a memory chips still available? - 20/04/2004 08:37

Thanks! Nope just a plain old Weller soldering station with a micropoint. Funny though, I was just thinking about a hot air station, we just haven't decided to take the plunge yet.

Stu
Posted by: Mach

Re: Thoughts of more RAM... - 29/04/2004 20:19

O Empeg father, who hast graciously given unto us the digital audio before its time; We yield thee humble and hearty thanks for this thy bounty. We remember well the darkness of the Before; We laud your mercies in delivering us to the great After.

And to the Lord of the Hijack, who maketh the buttons to glow, senses the press of the knob, and sendest the dock of refuge, who by thy mighty power dost order all things in the modes of AC and DC, we yield thee hearty thanks for the features thou hast bestowed upon us filling our ears with gladness.

We beseech thee to hear our quiet plea, and the relief of those that need; thinks us not whiners nor hangers-on, but deliver to us word of the mystical kernel that make the RAM runneth over. Sow in our hearts the hope of the car player without end, now and for evermore. A-bump.
Posted by: pgrzelak

Re: Thoughts of more RAM... - 30/04/2004 04:46

Hahahahaha.

A-bump, brother...

Seriously, though, there are some upgrade chips for the Mark2A floating around out there. I know Stu was working on upgrading a Mark2, and should (very soon?) be receiving a Mark2A for experimentation.
Posted by: JBjorgen

Re: Thoughts of more RAM... - 30/04/2004 06:49

A-Bump brotha! Preach it!
Posted by: Mach

Re: Thoughts of more RAM... - 30/04/2004 12:41

Already done hence the "a-bump". Stu added an additional 16Mb to Nanci (MK2a) this past week but it's not being recognized. On the plus side, she still boots.
Posted by: mlord

Re: Thoughts of more RAM... - 30/04/2004 17:17

Okay, Paul has bribed me to have a look at this. I'm starting with Mk2a. Can Stu (or Mach?) perhaps tell me exactly how the added ram has been attached to the processor bank selects? I'm still hunting for Hugo's posting on how to wire it up, but seem to have misplaced it.

Cheers
Posted by: pgrzelak

Re: Thoughts of more RAM... - 30/04/2004 17:30

Greetings!

Please... Please... Bribes are illegal in the US. It was merely a token of appreciation for all of the work you have done for myself and for the rest of the people here.
Posted by: Mach

Re: Thoughts of more RAM... - 30/04/2004 17:51

I've emailed Stu for an answer but I believe this is Hugo's post that you were looking for.

Here's Stu's post re-iterating the same
Posted by: mlord

Re: Thoughts of more RAM... - 30/04/2004 17:54

Yeah, I've found it now.

Stand by.. I'll post a MK2A test kernel shortly.
Posted by: maczrool

Re: Thoughts of more RAM... - 30/04/2004 17:55

Hi Mark, thanks for your help! Pin 14 of each stacked RAM chip for the MK2A is connected together in series to pin 121(and only pin 121) of the StrongARM CPU.

The MK2 is the same, but with Pin 18 of the RAM chips used instead.

Stu
Posted by: mlord

Re: Thoughts of more RAM... - 30/04/2004 17:57

Far too modest Paul! Besides, I'm not in the USA..

For now I'm coding blind -- after yesterday's geo-caching adventures -- 3 guys, 5 travel-bugs, 450 kms, and 25 caches found -- my hands are nowhere near steady enough to lift a soldering iron!
Posted by: Mach

Re: Thoughts of more RAM... - 30/04/2004 17:58

Hi Stu, is that a typo? I thought it was pin 123? (from the posts)
Posted by: mlord

Re: Thoughts of more RAM... - 30/04/2004 18:01

Okay, here's blind attempt number one.

This Hijack kernel is only for Mk2a units with 32MB of DRAM.

http://rtr.ca/hijack.mk2a-32mb.zImage

It will crash and burn on any other hardware, but will not damage anything permanently. I thnk.

EDIT: and it may very well crash and burn even on the correct hardware.. but we'll get it right after a few attempts, I suspect
Posted by: maczrool

Re: Thoughts of more RAM... - 30/04/2004 18:02

Hugo told us in an e-mail to use nRAS3 which is pin 121.

Stu
Posted by: mlord

Re: Thoughts of more RAM... - 30/04/2004 18:03

nRAS3 is for Mk2, not Mk2a. Right?
Posted by: maczrool

Re: Thoughts of more RAM... - 30/04/2004 18:04

So does it matter that we are using pin 121 and not 123 as in the old posts? Seems like it would.

Stu
Posted by: mlord

Re: Thoughts of more RAM... - 30/04/2004 18:05

Mk2a should be using nRAS1, pin 123, as per Hugo's posting.

But if you have already used nRAS3 on a Mk2a, then let me know, and I'll respin the kernel appropriately. In the end, it doesn't matter too much, but life is easier for me if they're consecutive.

-ml
Posted by: mlord

Re: Thoughts of more RAM... - 30/04/2004 18:06

Mmm.. actually, it MAY matter.. gotta think about that some more.
Posted by: mlord

Re: Thoughts of more RAM... - 30/04/2004 18:15

Here is blind guess kernel number two, suitable ONLY for mk2a units with 32MB of DRAM, using RAS3 for the second bank:

http://rtr.ca//hijack.mk2a-32mb-ras3.zImage

Both this kernel, and the earlier one (for RAS1 units), require the e000 flash update posted by Hugo earlier in this thread.

Cheers
Posted by: mlord

Re: Thoughts of more RAM... - 03/05/2004 14:49

Has anyone tried one or the other of those special kernels yet?

Care to report back here?

Cheers
Posted by: Mach

Re: Thoughts of more RAM... - 03/05/2004 16:16

I haven't heard anything back from Stu. He was making good progress on the upgrade so I'm assuming non-Empeg things have accosted him. I'll post as soon as I hear something. Thanks for putting the kernel together.
Posted by: pgrzelak

Re: Thoughts of more RAM... - 03/05/2004 16:37

I do not have a player here yet able to use the hack. Stu should have (or already has) received my first test unit around now.
Posted by: mlord

Re: Thoughts of more RAM... - 03/05/2004 17:02

Ahh, okay.

I've just (now!) taken Rita apart, and added two chips to her.

Now trying to figure out how to get the kernel to see it all.

-ml
Posted by: maczrool

Re: Thoughts of more RAM... - 03/05/2004 17:43

I need to know how to safely load the Flash upgrade. I wasn't really following Mark's instructions on how to load it with Hijack. Once I know how to load it properly, I'll give it a shot.

Thanks for all of your work.
Stu
Posted by: mlord

Re: Thoughts of more RAM... - 03/05/2004 18:40

I do the flash upgrade by simply using FTP to upload the file Hugo posted into /proc/flash_0e000

I have a new kernel for you:

http://rtr.ca/hijack.mk2a-32mb.zImage

This finds 32MB for me, but later dies with memory errors. I'd like to see if it also dies for you, or if it works.

EDIT: Fixed -- I had a couple of data lines that needed more solder. When I eventually release full Hijack support, it will include a memory test for the extended DRAM to aid in diagnosis.

-ml
Posted by: mlord

Re: Thoughts of more RAM... - 03/05/2004 18:46

Oh yeah.. that latest kernel REQUIRES that you use RAS1 for the extra bank. This will be the only supported configuration in the long run.

-ml
Posted by: mlord

Rita (with implants!): my 32MB Mk2a Player - 03/05/2004 22:37

/proc/meminfo:
        total:    used:    free:  shared: buffers:  cached:

Mem: 31924224 31100928 823296 1249280 5005312 13398016
Swap: 0 0 0
MemTotal: 31176 kB
MemFree: 804 kB
MemShared: 1220 kB
Buffers: 4888 kB
Cached: 13084 kB
SwapTotal: 0 kB
SwapFree: 0 kB

Posted by: mlord

Re: Rita (with implants!): my 32MB Mk2a Player - 03/05/2004 22:44

Here's a photo of Rita's implants:


For scale, note that the white whispy streak on the left is a hair from our cat!
Posted by: BAKup

Re: Rita (with implants!): my 32MB Mk2a Player - 03/05/2004 22:54

Aren't implants supposed to be made out of silicone, not silicon?

Sorry, had to make the joke
Posted by: mlord

Re: Rita (with implants!): my 32MB Mk2a Player - 03/05/2004 23:37

Is that babe stacked or what!!

Posted by: mlord

Re: Thoughts of more RAM... - 03/05/2004 23:43

For that matter, Hugo's e000 rom code only enables RAS1 (and RAS0). Not RAS3.
Posted by: pgrzelak

Re: Thoughts of more RAM... - 04/05/2004 04:51

Beautiful work!!! Impressive!!!
Posted by: mlord

Re: Thoughts of more RAM... - 04/05/2004 09:35

Actually, that's the uglier of the two chips. I didn't straighten out the pins on that one, so they barely make contact. The other one (which I did second) is nicer, but harder to photograph.

Cheers
Posted by: mlord

Re: Thoughts of more RAM... - 04/05/2004 10:42

Okay, here are the Hijack-v384 kernels for upgraded players:

http://rtr.ca/hijack.mk2-16mb.zImage
http://rtr.ca/hijack.mk2a-32mb.zImage

These will NOT work on ordinary (non-modified) players.
Included in these is a memory test for the newly expanded chips. If this fails, you'll know it from watching the serial logs, and can use the info it dumps to figure out which pins need resoldering.

Also required (before the kernel change) is Hugo's e000 flash update. I would suggest that this update be installed ONLY on upgraded players, not non-upgraded players -- because I may use it to test for upgrades in the kernel some time in the future.

Hugo's e000 update is also available here:

http://rtr.ca/flash_0e000.extramem

To install the e000 update, just FTP to the player (running any recent Hijack), cd to /proc, and put the flash file on top of "flash_0e000". It will install instantly, and is permanent once installed.

Cheers


Posted by: wfaulk

Re: Thoughts of more RAM... - 04/05/2004 11:05

So the conclusion is that adding more memory works. Has anyone looked to see if the player software actually uses the additional memory, or does it just malloc the amount it thinks the hardware has? Would negative cache settings help?
Posted by: mlord

Re: Thoughts of more RAM... - 04/05/2004 11:36

The player does not appear to use much of the extra 16m I added, but Linux uses it for general operations and disk-caching. I think peter may do something about the player s/w, though..
Posted by: pgrzelak

Re: Thoughts of more RAM... - 04/05/2004 11:47

If so, you may have found a way to get me to load alpha code...
Posted by: Daria

Re: Thoughts of more RAM... - 04/05/2004 13:24

So what memory should I be buying and where should I be sending my player?

Posted by: Mach

Re: Thoughts of more RAM... - 04/05/2004 13:43

Most excellent! Thank you very much!
Posted by: maczrool

Re: Thoughts of more RAM... - 04/05/2004 16:47

Okay, we're going to move the line to RAS1 and try later today. I wonder why the e-mail Hugo sent instructed we use RAS3? Oh well. Thanks for the work!

What is needed for the MK2 to have 16 megs? We did a memory upgrade on one which I guess will have to come back so we can move the line to the appropriate line.

Stu
Posted by: mlord

Re: Thoughts of more RAM... - 04/05/2004 17:11


MK2 == RAS3

MK2A == RAS1

There are kernels for each, see links above.
Posted by: mcomb

Re: Thoughts of more RAM... - 05/05/2004 11:18

Very cool! So did anyone come up with a memory supplier yet? And like dbrasher said, how much and where do I send it
Posted by: Mach

Re: Thoughts of more RAM... - 05/05/2004 12:43

Hugo pointed us to this supplier earlier in this thread. http://www.memphis-electronic.com/datasheets.htm

As far as the installation, both mlord and maczrool (eutronix) can do the upgrade but you may have to get in line. Maczrool had sourced a series of memory chips but most of these were spoken for IIRC.
Posted by: mcomb

Re: Thoughts of more RAM... - 05/05/2004 12:56

Hugo pointed us to this supplier earlier in this thread

Ah, cool. I missed that. Email inquiry sent to eutronix...

-Mike
Posted by: mlord

Re: Thoughts of more RAM... - 05/05/2004 13:26

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
Posted by: mlord

Re: Thoughts of more RAM... - 05/05/2004 13:33

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
Posted by: mlord

Re: Thoughts of more RAM... - 05/05/2004 14:51

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
Posted by: maczrool

Re: Thoughts of more RAM... - 05/05/2004 20:27

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
Posted by: mlord

Re: Thoughts of more RAM... - 05/05/2004 20:45

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
Posted by: maczrool

Re: Thoughts of more RAM... - 05/05/2004 21:06

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
Posted by: mlord

Re: Thoughts of more RAM... - 05/05/2004 21:11

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
Posted by: maczrool

Re: Thoughts of more RAM... - 05/05/2004 21:39

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
Posted by: mlord

Re: Thoughts of more RAM... - 05/05/2004 21:52

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
Posted by: mlord

And the world awaits.. - 06/05/2004 09:14

News?
Posted by: mcomb

Re: Thoughts of more RAM... - 06/05/2004 10:57

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
Posted by: mlord

Re: Thoughts of more RAM... - 06/05/2004 11:02

I've updated Hijack to v388 here.

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

Cheers
Posted by: maczrool

Re: Thoughts of more RAM... - 06/05/2004 11:53

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.
Posted by: mlord

Re: Thoughts of more RAM... - 06/05/2004 12:21

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
Posted by: mlord

Re: Thoughts of more RAM... - 06/05/2004 14:21

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.
Posted by: pgrzelak

Re: Thoughts of more RAM... - 06/05/2004 16:04

Bulk order in progress... Please stand by...
Posted by: pim

large player databases, v3 and memory - 06/05/2004 19:30

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
Posted by: Daria

Re: large player databases, v3 and memory - 06/05/2004 20:52

The root playlist crashes my player too. I just don't play it.
Posted by: pgrzelak

Re: large player databases, v3 and memory - 08/05/2004 15:31

Link to memory bulk order info in the For Sale forum.
Posted by: tonyc

Re: large player databases, v3 and memory - 08/05/2004 16:04

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.
Posted by: mlord

Re: Thoughts of more RAM... - 10/05/2004 17:04

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

Re: Thoughts of more RAM... - 11/05/2004 09:55

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
Posted by: maczrool

Re: Thoughts of more RAM... - 11/05/2004 21:17

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
Posted by: mlord

Re: Thoughts of more RAM... - 11/05/2004 21:43

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
Posted by: mlord

Re: Thoughts of more RAM... - 11/05/2004 21:47

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
Posted by: maczrool

Re: Thoughts of more RAM... - 11/05/2004 23:00

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

Stu
Posted by: maczrool

Re: Thoughts of more RAM... - 16/05/2004 21:24

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
Posted by: altman

Re: Thoughts of more RAM... - 17/05/2004 04:23

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
Posted by: maczrool

Re: Thoughts of more RAM... - 17/05/2004 22:13

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
Posted by: genixia

Re: Thoughts of more RAM... - 17/05/2004 22:41

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.

Posted by: andym

Re: Thoughts of more RAM... - 18/05/2004 04:07

I've done very little SMT (basically I did the button and knob light mod) and was wondering whether you use solder paste in jobs like this or is that only when you're soldering straight onto the board.
Posted by: maczrool

Re: Thoughts of more RAM... - 18/05/2004 07:43

You must have smaller probes. That was one of the first things we tried, but we can't quite get into the pins on the inside row.

And we use very fine gauge rosin solder, although there is more than one way to skin a cat. Paste could work as well.

Stu
Posted by: genixia

Re: Thoughts of more RAM... - 18/05/2004 10:05

Solder paste doesn't work very well in this situation as it is very hard to get the amount right. It also tends to get behind the pins whereupon it doesn't heat very well and wont wick easily. I practiced various techniques on an old SIMM card, and just couldn't get the paste to work well.

The approach that works best (for me anyway) is to use the iron to 'paint' the connection. The blob of solder on the end of a 1/16" tip is enough to solder several pins. Start by fluxing all the pins, position the new chip and tack two opposing corners. Verify the alignment, add more flux, and then drag the blob slowly along the line of pins, allowing a couple of seconds per connection. When each pin heats up it will wick solder off of the iron and into the connection whereapon it heats the other pin and results in a good solder joint.


|| || || || ||
(OOO)
[TTTTT] Drag slowly --->
[TTTTT]

The keys to this technique are flux and patience. If you don't allow a enough time per pin then the solder won't wick properly and you'll end up dragging a bridge of solder across _all_ the pins. If you don't have enough flux then you will also bridge adjoining connections. With a hundred connections to make it is likely that one or more bridges will be made anyway ('cos we're not pro's). Clean all solder off of the iron, add flux to the bridged pins and reheat. Often this is enough to wick out the bridge - the solder wicks back onto the iron. In stubborn cases where this doesn't work, fine desoldering braid will wick it out (with flux, obviously). When this happens you'll need to repaint the connection and also a couple each side of it as the braid isn't fine enough to only hit one connection.

This technique is used by many professionals to mount fine SMT chips to boards - they paint the pads and rely on the wicking action to draw solder under the pin. In this way they avoid physical contact with pins that are easy to bend. Allegedly they use the biggest tip size that they can get into the board as it holds the most solder.

I managed to stack 4 chips on my SIMM using this method. I haven't tested each and every connection, but they looked good.

DISCLAIMER - This post is purely informational in nature. I do not accept any responsibility for any actions taken based upon this post,
Posted by: genixia

Re: Thoughts of more RAM... - 18/05/2004 11:11

You must have smaller probes.

Hmm. Both of my 2 sets are the same size, One set is BK Precision, and the other Extech, I don't think that they're especially small - kinda standard.

If you're having problems with the probe touching other pins then heatshrink can help to insulate most of the probe. Orient the board so that you're looking face on at the pins and bring the probes in from each side - this way you're running the bottom probe through the gap and not across it.

Posted by: genixia

Re: Thoughts of more RAM... - 18/05/2004 11:17

Check pins 48 & 49. If I'm understanding Mark's debug output correctly then these two pins are floating/shorted high. Note that pin 50 is Vss.
Posted by: maczrool

Re: Thoughts of more RAM... - 18/05/2004 19:01

One thing I've noticed is that part of the boot log reports as above with the same error we've been getting, while another part of the boot log says:

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

So which part is to be believed?

Stu
Posted by: genixia

Re: Thoughts of more RAM... - 18/05/2004 20:22

Not sure...Mark will have to chime in. One thing that I can tell you is that the kernel appears to try to test for beyond 32MB, and that you will get "c2000000 wrote ffffffff, read 00000000" as it tries to test the first location beyond 32MB.
Posted by: mlord

Re: Thoughts of more RAM... - 19/05/2004 10:55

Both parts are to be believed.

If you see (as posted) 32MB being reported by the kernel, then the memory has passed Hijack's DRAM test and is now being used!

So look very closely at the Hijack "Checking for extra DRAM" messages.. probably failed on c2000000 rather than c1000000, right? Hijack has detection support for up to 64MB of DRAM now, though I think there was something somewhere I needed to fix for it all to work properly.. forgotten now..

Cheers
Posted by: pgrzelak

Re: Thoughts of more RAM... - 19/05/2004 10:58

64MB?!?!? Hm!!! That sounds rather interesting! Has anyone done it yet? I still have a bunch of chips left... Very tempting...
Posted by: skibum

Re: Thoughts of more RAM... - 19/05/2004 11:06

I have a feeling Paul would be the first to go for the 1gb ram upgrade if someone managed to work out how to do it :-)
Posted by: pgrzelak

Re: Thoughts of more RAM... - 19/05/2004 11:15

Just think of the caching I could do!
Posted by: BartDG

Re: Thoughts of more RAM... - 19/05/2004 11:20

It has been said that it would be do-able though very difficult.
IIRC, it wouldn't work for another reason : with four chips stacked onto one, the stack would become too high. Well, high enough to get in the way of the drive bay anyway.
Posted by: maczrool

Re: Thoughts of more RAM... - 19/05/2004 18:40

Actually we're still getting "Checking for extra DRAM at c1000000: wrote 00000000, read c0000000 " or sometimes "Checking for extra DRAM at c1000000: wrote 00000000, read c0" at the beginning of the boot log and further down it reports 32 MB, hence the confusion.

Stu
Posted by: mlord

Re: Thoughts of more RAM... - 19/05/2004 19:24

Make sure you are using Hijack v391 for this. What you say it's doing should not be possible with Hijack v391.

-ml
Posted by: andym

Re: Thoughts of more RAM... - 20/05/2004 10:28

They've arrived, funny, they look a lot smaller in real life than on the pictures in the forum.
Posted by: skibum

Re: Thoughts of more RAM... - 20/05/2004 10:31

It's funny that. I noticed the same thing. As have the people I've asked to solder the things :-(
Posted by: frog51

Re: Thoughts of more RAM... - 20/05/2004 15:03

Heh - I'm going to wait till the early adopters have ironed out the bugs, then I'll need to have a brave day when the kids are out to try it. I'll probably go the whole hog and actually buy a small soldering iron too which I maybe should have used for the button light hack.
Posted by: andym

Re: Thoughts of more RAM... - 21/05/2004 02:50

Right then, I've sorted out access to the SMT stuff at work for this afternoon. Wish me luck....

BTW: Who's currently doing repairs to damaged empegs? Just covering all eventualities.

EDIT: Just realised I'm now officially a veteran, next stop Pooh-Bah!!!
Posted by: Shonky

Re: Success - 21/05/2004 05:40

Aw yeah. Worked first time...



Checking for extra DRAM:

c1000000: passed.
c1100000: passed.
c1200000: passed.
c1300000: passed.
c1400000: passed.
c1500000: passed.
c1600000: passed.
c1700000: passed.
c1800000: passed.
c1900000: passed.
c1a00000: passed.
c1b00000: passed.
c1c00000: passed.
c1d00000: passed.
c1e00000: passed.
c1f00000: passed.
c2000000: wrote ffffffff, read 00000000

empeg:/empeg/bin# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 31920128 15552512 16367616 1306624 8257536 4747264
Swap: 0 0 0
MemTotal: 31172 kB
MemFree: 15984 kB
MemShared: 1276 kB
Buffers: 8064 kB
Cached: 4636 kB
SwapTotal: 0 kB
SwapFree: 0 kB


Thanks Paul, Mark, Hugo, Stu and everyone else who took the punt.
Posted by: pgrzelak

Re: Success - 21/05/2004 05:58

Nice work!!!

If you see any performance changes (improvements), please
post them! Let us know what we can look forward to. I know
Mark has already started to do so, but it is nice to see what
others find as well. Thanks!
Posted by: andym

Re: Success - 21/05/2004 12:36

Okay then, well I'm getting there. I'm currently stuck at:

Checking for extra DRAM:
c1000000: wrote ffffffff, read fbffffff



So nearly there.
Posted by: genixia

Re: Success - 21/05/2004 15:05

Pin 43, I think. Can't remember which chip.
Posted by: maczrool

Re: Thoughts of more RAM... - 21/05/2004 17:36

It's Hijack 3.90. Does that make a difference?

We get this from the web-based memory report:

total: used: free: shared: buffers: cached:
Mem: 31928320 31211520 716800 1568768 8466432 10616832
Swap: 0 0 0
MemTotal: 31180 kB
MemFree: 700 kB
MemShared: 1532 kB
Buffers: 8268 kB
Cached: 10368 kB
SwapTotal: 0 kB
SwapFree: 0 kB

Stu
Posted by: genixia

Re: Thoughts of more RAM... - 21/05/2004 17:56

It's Hijack 3.90. Does that make a difference?

It looks like Mark rewrote the memory management code in v391. It's not clear why, but I'd suggest upgrading anyway. It's entirely possible that there was a bug in v390 that you are seeing.
Posted by: andym

Re: Success - 22/05/2004 09:17

Pin 43, I think. Can't remember which chip.

Bingo!


Checking for extra DRAM:
c1000000: passed.
c1100000: passed.
c1200000: passed.
c1300000: passed.
c1400000: passed.
c1500000: passed.
c1600000: passed.
c1700000: passed.
c1800000: passed.
c1900000: passed.
c1a00000: passed.
c1b00000: passed.
c1c00000: passed.
c1d00000: passed.
c1e00000: passed.
c1f00000: passed.
c2000000: wrote ffffffff, read 00000000
.....
Memory: 31240k/32M available (980k code, 20k reserved, 524k data, 4k init)

Posted by: andym

Re: Success - 22/05/2004 09:40

Oooh! Lovely....


empeg:/empeg/bin# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 31920128 10387456 21532672 1335296 3674112 4747264
Swap: 0 0 0
MemTotal: 31172 kB
MemFree: 21028 kB
MemShared: 1304 kB
Buffers: 3588 kB
Cached: 4636 kB
SwapTotal: 0 kB
SwapFree: 0 kB

Posted by: genixia

Re: Success - 22/05/2004 10:15

Congrats! Which method did you use in the end?
Posted by: pgrzelak

Re: Success - 22/05/2004 10:21

"I want my...
I want my...
I want my memory..."

(sorry Dire Straits fans...)
Posted by: andym

Re: Success - 22/05/2004 13:30

Congrats! Which method did you use in the end?

A bit of yours and a bit of something else.

I managed to get the afternoon in our test room on Friday. So I started by straightening the pins and making sure they sat nicely on the existing pair of chips. Once I was happy a dab of Pritt-Stick held them in place. To do the actual soldering I used what the guys at work affectionatley call the Nanoprobe, which looked like a minature temp-controlled Weller iron to me. The tip is smallest I've seen. I then did the soldering under their microscope setup which was quite cool.

Under the scope I applied a small amount solder to the tip of the iron (which actually looked like half a tonne under magnification) and then press it against the pin until the solder flowed off the tip and onto the leg of the chip. I repeated this process until I'd done all the legs on the first chip. After feeling quite pleased with myself I then went and tried your method. This worked well too. In the end there was just that one dodgy leg on the first chip. A quick press of the iron onto the leg must've resweated it.

The most difficult bit was making a satisfactory connection to RAS line on the StrongARM.

Here it is:

Posted by: maczrool

Re: Success - 22/05/2004 14:03

Upgraded to Hijack 3.91 we get:

Checking for extra DRAM at c1000000: wrote 000 .....
Memory: 15016k/16M available (980k code, 20k reserved, 364k data, 4k init).....
Memory: 31240k/32M available (980k code, 20k reserved, 524k data, 4k init).....

The web utility gives:
total: used: free: shared: buffers: cached:
Mem: 31928320 29294592 2633728 1703936 8466432 9687040
Swap: 0 0 0
MemTotal: 31180 kB
MemFree: 2572 kB
MemShared: 1664 kB
Buffers: 8268 kB
Cached: 9460 kB
SwapTotal: 0 kB
SwapFree: 0 kB

It is only showing around 2 MB free. Where did all of the rest go if it's got 32 total as reported?

What gives? Why do we get all of these different values reported?

Stu
Posted by: genixia

Re: Success - 22/05/2004 17:00

I'm confused about seeing the two lines in the boot log.

The memory report following is correct for 32MB though - the first line reports in bytes, the following lines in kB. If you divide 31928320 by 1024 you get 31880. The low 'free' memory count is because linux uses an aggressive caching strategy and does not discard old data immediately upon the premise that it may be needed again soon. Read here for an overview of linux page caching.
Posted by: mlord

Re: Success - 24/05/2004 14:14

Post the boot log, in its entirety, please.

-ml
Posted by: maczrool

Re: Success - 24/05/2004 21:25

Here's a really dumb question. How do you get hyperterminal to copy in Windows XP? Sometimes it will and sometimes it won't. Right now it's not. I've selected all and hit control+c as well as selecting copy in the menu, but there is nothing to paste, even with a screen full of boot log! My only solution has been to be to a W2K computer.

Anyway, here it is:

empeg-car bootstrap v1.02 20001106 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.03
Copying kernel...
Calling linux kernel...
Uncompressing Linux................................... done, booting the kernel.

Linux version 2.2.14-rmk5-np17-empeg43 (mac@aphex.internal.empeg.com) (gcc versi
on 2.95.2 19991024 (release)) #214 Sat Jun 23 16:38:57 BST 2001
Processor: Intel StrongARM-1100 revision 11
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 40104008)
Command line: mem=16m temp=N90
Calibrating delay loop... 207.67 BogoMIPS
Memory: 15064k/16M available (960k code, 20k reserved, 332k data, 8k init)
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Linux-IrDA: IrCOMM protocol ( revision:Tue May 18 03:11:39 1999 )
ircomm_tty: virtual tty driver for IrCOMM ( revision:Wed May 26 00:49:11 1999 )
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 206f6972 'rio '
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0004500).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hda: FUJITSU MHL2300AT, ATA DISK drive
hdb: FUJITSU MHL2300AT, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: FUJITSU MHL2300AT, 28615MB w/2048kB Cache, CHS=58140/16/63
hdb: FUJITSU MHL2300AT, 28615MB w/2048kB Cache, CHS=58140/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman (erik@vt.edu)

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:28:0f:a
8
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
hdb: hdb1 < hdb5 hdb6 > hdb2 hdb3 hdb4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 8k initEXT2-fs: ide0(3,4): couldn't mount because
of unsupported optional features.
empeg-car 1.03.
3bb31168 DHCP Our mac is 00:02:d7:28:0f:a8
3bb31168 DHCP Our address is 255.255.255.255
3bb31168 DHCP Broadcast address is 255.255.255.255
3bb31168 DHCP Current IP address is 255.255.255.255
3bb31168 DHCP Sending DHCP discover
3bb31169 DHCP Sending DHCP discover
3bb3116b DHCP Sending DHCP discover
3bb3116e DHCP Sending DHCP discover
3bb31175 DHCP Sending DHCP discover
3bb31184 DHCP Sending DHCP discover
3bb311a3 DHCP Sending DHCP discover

empeg-car bootstrap v1.02 20001106 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.03
Copying kernel...
Calling linux kernel...
Uncompressing Linux................................... done, booting the kernel.

Linux version 2.2.14-rmk5-np17-empeg43 (mac@aphex.internal.empeg.com) (gcc versi
on 2.95.2 19991024 (release)) #214 Sat Jun 23 16:38:57 BST 2001
Processor: Intel StrongARM-1100 revision 11
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 40104008)
Command line: mem=16m temp=N90
Calibrating delay loop... 207.67 BogoMIPS
Memory: 15064k/16M available (960k code, 20k reserved, 332k data, 8k init)
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Linux-IrDA: IrCOMM protocol ( revision:Tue May 18 03:11:39 1999 )
ircomm_tty: virtual tty driver for IrCOMM ( revision:Wed May 26 00:49:11 1999 )
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 206f6972 'rio '
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0004580).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hda: FUJITSU MHL2300AT, ATA DISK drive
hdb: FUJITSU MHL2300AT, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: FUJITSU MHL2300AT, 28615MB w/2048kB Cache, CHS=58140/16/63
hdb: FUJITSU MHL2300AT, 28615MB w/2048kB Cache, CHS=58140/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman (erik@vt.edu)

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:28:0f:a
8
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
hdb: hdb1 < hdb5 hdb6 > hdb2 hdb3 hdb4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 8k initEXT2-fs: ide0(3,4): couldn't mount because
of unsupported optional features.
empeg-car 1.03.
3bb311e5 DHCP Our mac is 00:02:d7:28:0f:a8
3bb311e5 DHCP Our address is 255.255.255.255
3bb311e5 DHCP Broadcast address is 255.255.255.255
3bb311e5 DHCP Current IP address is 255.255.255.255
3bb311e5 DHCP Sending DHCP discover
3bb311e6 DHCP Sending DHCP discover
3bb311e8 DHCP Sending DHCP discover
3bb311ed DHCP Sending DHCP discover
3bb311f8 DHCP Sending DHCP discover
3bb3120f DHCP Sending DHCP discover
3bb3123e DHCP Sending DHCP discover
Player received SIGINT, user interruption
Switching to shell-player loop
Starting bash.
úShell exit
empeg-car 1.03.
3bb3124b DHCP Our mac is 00:02:d7:28:0f:a8
3bb3124b DHCP Our address is 255.255.255.255
3bb3124b DHCP Broadcast address is 255.255.255.255
3bb3124b DHCP Current IP address is 255.255.255.255
3bb3124b DHCP Sending DHCP discover
3bb3124c DHCP Sending DHCP discover
3bb3124f DHCP Sending DHCP discover
3bb31256 DHCP Sending DHCP discover
3bb31263 DHCP Sending DHCP discover
3bb3127e DHCP Sending DHCP discover
3bb312b4 DHCP Sending DHCP discover

empeg-car bootstrap v1.02 20001106 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux..................................... done, booting the kerne
l.
Linux version 2.2.14-rmk5-np17-empeg51 (mac@aphex) (gcc version 2.95.3 20010315
(release)) #17 Wed Jul 24 18:23:20 BST 2002
Processor: Intel StrongARM-1100 revision 11
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 40104008)
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 15024k/16M available (964k code, 20k reserved, 372k data, 4k init)
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Linux-IrDA: IrCOMM protocol ( revision:Tue May 18 03:11:39 1999 )
ircomm_tty: virtual tty driver for IrCOMM ( revision:Wed May 26 00:49:11 1999 )
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 206f6972 'rio '
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0004980).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hda: FUJITSU MHL2300AT, ATA DISK drive
hdb: FUJITSU MHL2300AT, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: FUJITSU MHL2300AT, 28615MB w/2048kB Cache, CHS=58140/16/63
hdb: FUJITSU MHL2300AT, 28615MB w/2048kB Cache, CHS=58140/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman (erik@vt.edu)

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:28:0f:a
8
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
hdb: hdb1 < hdb5 hdb6 > hdb2 hdb3 hdb4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k init player.cpp : 385:empeg-car 2.00-be
ta13 2002/07/24.
! tags.cpp : 61:Failed to open tags (0xc0041014).
Prolux 4 empeg car - 2.1434 Jul 24 2002
Vcb: 0x4086d000

empeg-car bootstrap v1.02 20001106 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux..................................... done, booting the kerne
l.
Linux version 2.2.14-rmk5-np17-empeg51 (mac@aphex) (gcc version 2.95.3 20010315
(release)) #17 Wed Jul 24 18:23:20 BST 2002
Processor: Intel StrongARM-1100 revision 11
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 40104008)
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 15024k/16M available (964k code, 20k reserved, 372k data, 4k init)
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Linux-IrDA: IrCOMM protocol ( revision:Tue May 18 03:11:39 1999 )
ircomm_tty: virtual tty driver for IrCOMM ( revision:Wed May 26 00:49:11 1999 )
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 206f6972 'rio '
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0004d00).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hdb: FUJITSU MHL2300AT, ATA DISK drive
hda: FUJITSU MHL2300AT, ATA DISK drive
hdb: FUJITSU MHL2300AT, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: FUJITSU MHL2300AT, 28615MB w/2048kB Cache, CHS=58140/16/63
hdb: FUJITSU MHL2300AT, 28615MB w/2048kB Cache, CHS=58140/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman (erik@vt.edu)

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:28:0f:a
8
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
hdb: hdb1 < hdb5 hdb6 > hdb2 hdb3 hdb4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k init player.cpp : 385:empeg-car 2.00-be
ta13 2002/07/24.
! tags.cpp : 61:Failed to open tags (0xc0041014).
^T^T^TProlux 4 empeg car - 2.1434 Jul 24 2002
Vcb: 0x4086d000

empeg-car bootstrap v1.02 20001106 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...
0000 empeg-car (issue9) board test version 0.05 <hugo@empeg.com>
0100 ram test starting
0110 testing ic 1 (0-15mb, low word)
0120 testing ic 2 (0-15mb, high word)
01f0 ram test done
0200 ide detect
0210 command issued
0220 drive id FUJITSU MHL2300AT
02f0 ide ok
0300 dsp/i2c test
03f0 dsp/i2c ok
0400 temperature detect
0410 temperature is 00
04f0 temperature ok
0500 usb detect
0510 usb rev 1012
05f0 usb ok
0600 ethernet detect
0610 ethernet rev 334b
06f0 ethernet ok
0700 cs4231 detect
0710 cs4231 rev a0
07f0 cs4231 ok
00f0 tests complete

empeg-car bootstrap v1.02 20001106 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux..................................... done, booting the kerne
l.
Linux version 2.2.17-rmk5-np17-empeg52-hijack-v391 (root@ibbm) (gcc version 2.95
.3 20010315 (release)) #2 Wed May 12 16:43:07 EDT 2004
Processor: Intel StrongARM-1100 revision 11
Checking for extra DRAM:
c1000000: passed.
c1100000: passed.
c1200000: passed.
c1300000: passed.
c1400000: passed.
c1500000: passed.
c1600000: passed.
c1700000: passed.
c1800000: passed.
c1900000: passed.
c1a00000: passed.
c1b00000: passed.
c1c00000: passed.
c1d00000: passed.
c1e00000: passed.
c1f00000: passed.
c2000000: wrote ffffffff, read 00000000
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 30102420)
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 31240k/32M available (980k code, 20k reserved, 524k data, 4k init)
Dentry hash table entries: 4096 (order 3, 32k)
Buffer cache hash table entries: 32768 (order 5, 128k)
Page cache hash table entries: 8192 (order 3, 32k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 32768 bhash 32768)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 206f6972 'rio '
Tuner: loopback=0, ID=-1
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0005500).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: IBM-DJSA-220, 19077MB w/1874kB Cache, CHS=38760/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman (erik@vt.edu)

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:26:09:7
4
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
Timezone: /usr/share/zoneinfo
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k initTimezone: /usr/share/zoneinfo/Atlantic/Azor
es
Hijack: intercepting config.ini

hijack: removed menu entry: "Serial Port Assignment"
khttpd: listening on port 80
kftpd: listening on port 21
player.cpp : 385:empeg-car 2.00-beta13 2002/07/24.
Prolux 4 empeg car - 2.1434 Jul 24 2002
Vcb: 0x4086d000
Posted by: genixia

Re: Success - 24/05/2004 21:45

I don't know why you've got so many boot logs there (what's the story??) but the last one looks good as far as I can tell:

Linux version 2.2.17-rmk5-np17-empeg52-hijack-v391 (root@ibbm) (gcc version 2.95
.3 20010315 (release)) #2 Wed May 12 16:43:07 EDT 2004
Processor: Intel StrongARM-1100 revision 11
Checking for extra DRAM:
c1000000: passed.
c1100000: passed.
c1200000: passed.
c1300000: passed.
c1400000: passed.
c1500000: passed.
c1600000: passed.
c1700000: passed.
c1800000: passed.
c1900000: passed.
c1a00000: passed.
c1b00000: passed.
c1c00000: passed.
c1d00000: passed.
c1e00000: passed.
c1f00000: passed.
c2000000: wrote ffffffff, read 00000000
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 30102420)
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 31240k/32M available (980k code, 20k reserved, 524k data, 4k init)


The c2000000 'failure' is where the kernel is trying to test beyond 32MB.
Posted by: tfabris

Re: Success - 24/05/2004 23:18

I don't know why you've got so many boot logs there (what's the story??)
Because Hyperterminal on Windows saves a certain amount of scrollback as part of the .ht file. I don't think there's actually a way to clear the scrollback in hyperterminal other than to delete the .ht file and start over again. Yeah, I know it sucks.
Posted by: Shonky

Re: Success - 25/05/2004 01:52

One thing I have notice and it's probably also due to the extra inherent disk caching built in to Linux the Mark mentioned.

Before the RAM upgrade with 3.0a7 I would get frequent short music pauses when entering the playlists menu (I think the disk was spinning up) or each time I'd type a letter in the search function. This is completely gone now probably due to the empeg not having to access the disk quite as much.

BTW: Could an admin delete my image please - I can't edit the post anymore. I apologise for making it so big causing everyone's browsers to stretch everything out.
Posted by: Roger

Re: Success - 25/05/2004 07:51

How do you get hyperterminal to copy in Windows XP?

Use TeraTerm instead.

Alternatively, set Hyperterminal to log to a file, and pick up the relevant data from there.
Posted by: mlord

Re: Success - 27/05/2004 10:00

Yup, looks good. I believe that Stu has a working 32MB player in hand!

The old logs in hyperterm were just confusing things.

cheers
Posted by: maczrool

Re: Success - 27/05/2004 10:51

Thanks for the QC and of course Hijack!

Stu
Posted by: Mach

Re: Success - 29/05/2004 16:39

Woot! I'm now a member of the 32 club. Thanks Stu!
Posted by: mlord

Re: Success - 30/05/2004 10:55

Hey, welcome aboard Alvin!

I think that makes about five of us already, with many more to follow in the near future!

Cheers
Posted by: StigOE

Re: Success - 31/05/2004 10:14

Yep, I can report two more success stories. Both my main and backup are now at 32Mb:

Checking for extra DRAM:
c1000000: passed.
c1100000: passed.
c1200000: passed.
c1300000: passed.
c1400000: passed.
c1500000: passed.
c1600000: passed.
c1700000: passed.
c1800000: passed.
c1900000: passed.
c1a00000: passed.
c1b00000: passed.
c1c00000: passed.
c1d00000: passed.
c1e00000: passed.
c1f00000: passed.
c2000000: wrote ffffffff, read 00000000

empeg:/empeg/bin# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 31928320 18505728 13422592 1306624 4046848 12496896
Swap: 0 0 0
MemTotal: 31180 kB
MemFree: 13108 kB
MemShared: 1276 kB
Buffers: 3952 kB
Cached: 12204 kB
SwapTotal: 0 kB
SwapFree: 0 kB

Thanks to Paul for the two memorysets.

Stig
Posted by: Folsom

Re: Success - 01/06/2004 11:23

I also successfully upgraded both of my players to 32 MB.

Also, many thanks to Paul for making the memory available!
Posted by: FireFox31

Re: Success - 01/06/2004 18:08

I just want to chime in and say you guys are hardware hacking champions. These 32 meg upgrades are really something.
Posted by: frog51

Re: Success - 02/06/2004 14:05

Hi Andy,

I think I'll give my Mk2a a shot over the next couple of weeks, but thought I'd get some reassurance. Did you come up against anything difficult? Aside from everything just being very small and fiddly? Is it easy to accidentally splurge (technical term) solder across adjacent pins?
I gather it is just a case of soldering the two chips on - all except pin 14 on each which gets wired to pin 123, correct?
Posted by: andym

Re: Success - 02/06/2004 14:21

In my experience, patience, a good light, a half decent iron and possibly some magnification is all you need. Straighten the pins on the new chips (dead important), line them up on the existing ones (make sure your pin 1 spots match up). Try genexias tips for soldering the pins down, with the right amount of solder on the tip it works a treat. Keep pin 14 out of the way and wire the pin on both chips to 123.

I would look at the pictures on this thread so give you an idea of which CPU pin to use, that's the bit I like the least. I sure that if mine fails it'll be that connection.
Posted by: maczrool

Re: Success - 02/06/2004 16:40

Yeah, be careful how you handle pin 14. It becomes stressed when it gets bent upward and even the slight stress from attaching the C/S line to it can cause it to break. This happened to us and getting at the remaining lead that is buried inside the package is not easy.

Stu
Posted by: Waterman981

Re: Success - 02/06/2004 20:11

That just happened to me last night when installing mine. Unfortunately where it broke I know I don't have the skills to repair it. So yeah, be careful on pin 14.
Posted by: maczrool

Re: Success - 02/06/2004 21:02

So did it break flush with the side of the package? That's what happened when ours broke, but we just dug and dug until enough lead was exposed to attach the wire. You could try that if that's what happened. The worst part of replacing the chip rather than repairing it is removing the damaged one without disturbing the OEM ones below.

Stu
Posted by: Waterman981

Re: Success - 02/06/2004 21:45

It did break flush. It was of course after every leg was attached. I did remove both of them after that until I can get new chips. I had no problems removing them and everything is working just like before. How did you get through the package to get to the lead?
Posted by: maczrool

Re: Success - 02/06/2004 22:09

We used a sharp X-acto blade to slowly chip away at the epoxy material until we got enough of the lead exposed. It was probably easier than desoldering the damaged chip (cheaper too).

Stu
Posted by: frog51

Re: Success - 03/06/2004 02:14

Cheers. I will let you know how it goes
Posted by: SE_Sport_Driver

Re: Success - 03/06/2004 16:31

Does anyone have any tips on pulling the main board out of the player? Will it be obvious when I start? I'm sending my player off to Mark for and IDE repair and he requested I send only the board.
Posted by: genixia

Re: Success - 03/06/2004 19:01

It's fairly obvious. Just take usual anti-static precautions and don't forget to remove the hex huts from the serial port!
Posted by: tfabris

Re: Success - 03/06/2004 21:28

Does anyone have any tips on pulling the main board out of the player?
Yeah, there's a specific list of tips including some movie files in the usual place.
Posted by: pgrzelak

Re: Success - 04/06/2004 04:56

How badly is this complicated (if at all) by the addition of a digital out card?
Posted by: SE_Sport_Driver

Re: Success - 04/06/2004 05:38

Wow Tony. I keep thinking I know what's in the FAQ and you always seem to have so much more than I thought! You're like a ninja sneaking around there adding content while nobody is looking!
Posted by: SE_Sport_Driver

Re: Success - 04/06/2004 13:08

Wow, that was really easy! Hopefully, I'll be able to get the display to line up when I put it back together (I remember adjusting the height of my Mk2 way back when).

Thank you!
Posted by: tfabris

Re: Success - 04/06/2004 13:16

That's just some careful trial-and-error, you'll be fine.

While you've got the display off and the motherboard out, I recommend tightening and using loctite on all the screws that connect the handle, those loosen rather easily. If you've got the skills, I also recommend this. A rattling handle is annoying. My friend Tod's handle actually squeaks as it rattles and I keep telling him I'll fix it for him if only I he'd let me get my mitts on the player for long enough.
Posted by: genixia

Re: Success - 04/06/2004 16:39

Your .sig is out of date.
Posted by: pgrzelak

Re: Success - 04/06/2004 16:43

Ah, but is it???
Posted by: genixia

Re: Success - 04/06/2004 16:45

Yes.
total: used: free: shared: buffers: cached:
Mem: 48553984 33345536 15208448 921600 16404480 6012928
Swap: 0 0 0
MemTotal: 47416 kB
MemFree: 14852 kB
MemShared: 900 kB
Buffers: 16020 kB
Cached: 5872 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Posted by: pgrzelak

Re: Success - 04/06/2004 16:46

HAHAHAHAHAHAHAHAH! Excellent!!! Very cool! Thanks!
Posted by: pgrzelak

Re: Success - 04/06/2004 16:52

Is this better???

Meanwhile, any trouble? Any ill effects? Any noticeable differences? Any photos???
Posted by: BartDG

Re: Success - 04/06/2004 17:03

48Mb of RAM ? COOL !
Posted by: genixia

Re: Success - 04/06/2004 17:12

I'm soak testing it now. To be honest I expect that to be a formality as I have already soak tested each of the extra 32MB layers independently during testing. You've got a mlord custom kernel at the moment, needed to activate the third bank. I expect that change will make it into the next official hijack release.

I hereby offer a 6 pack to the first person to successfully install 64MB. Be warned that dealing with the RAS pins becomes an exercise in frustration and lost pins when you add a third layer.
Posted by: andym

Re: Success - 04/06/2004 17:17

That sounds like an interesting challenge....
Posted by: skibum

Re: Success - 04/06/2004 17:19

I think we need photo's of this masterpiece. So, whats going to be first. 200gb of disc space or 1gb ram ;-)
Posted by: SE_Sport_Driver

Re: Success - 04/06/2004 17:22

Speaking of hard drives, once the empeg software takes advantage of this, even 32MB will extend the life span of hard drives quite a bit. I imagine that they'll stay spun down quite a bit.
Posted by: mlord

Hijack v394: support for up to 64MB DRAM on Mk2a - 04/06/2004 17:24

Hijack v394 has been available for several hours now.

The only change is that I completed some coding from earlier, so that as much as 64MB of DRAM can now be used with Mk2a units. Earlier kernels detected and enabled such, but couldn't properly handle it all in other parts of the kernel. Now fixed.

The kernel on Paul's player is identical to v394 (and probably says "v394" at startup).

Cheers
Posted by: pgrzelak

Re: Hijack v394: support for up to 64MB DRAM on Mk2a - 04/06/2004 17:49

Actually, I think that is still 391... It takes a lot to keep the players in sync (with the big disk drives and all), so I haven't done any updates for a little while. Edit: Nevermind... I understand now. It just took a little extra time...

Do you think there would be any added concerns with handling the player? Does the higher stacked RAM add any (extra) fragility to the player?
Posted by: genixia

Re: Success - 04/06/2004 18:11

Is this better???

Yes!
Meanwhile, any trouble?

Ha! As I earlier predicted, adding a third layer added an order of magnitude of difficulty. The air turned blue when I lost the RAS pin of one of the middle chips in a stack. Attempts to dig the epoxy on that one hadn't suceeded by the time all the excavation had disturbed the RAS pin on the chip above it to the point where that one disappeared too. At that point I removed and replaced both chips on that stack. Fortunately desoldering the extra chips was easy (so much so that if I had known I would have not bothered digging at all). Added two new chips, wired up the RAS line for the bottom layer and and then noticed that I'd lost the top RAS pin on the other stack that now had a wire running across it (that I had absolutely no desire to remove.)
After turning the air blue again, that one did excavate (easier to excavate the top of the package down). Got the second RAS line wired.

Tested, removed one short and one open pin (not bad considering) to pass the memory test. But it fell over whenever I quit the player app on the serial port or whenever the (huge) database was being loaded, always with the same 'Bad Address' error. Spent an age carefully testing and retouching all the address lines (which aren't exhaustively tested by the kernel) to no avail, same error every time. Finally broke down and rewired the RAS lines at the CPU for 32MB only which passed a soak test. Rewired to use the other 16MB as part of 32MB which also passed a soak test. Paged Mark who spun a kernel fix in a few minutes. (New kernel should work for 64MB too apparently.) Installed kernel, tested fine on 32MB, rewired both RAS wires for 48MB, prayed to the God of Small Things Containing Magic Smoke and booted into 48MB nirvana.
Any ill effects?

Only a few frayed nerves.
Any noticeable differences?

I don't know that I'm qualified to tell. Obviously the player is still only using 16MB, and that is where you will see the biggest improvement when the empeg guys can be persuaded to spin a tweaked player binary sometime, your disks just down spin down.
The web interface is very snappy - I can refresh /proc/empeg_screen.png without any delay.
Any photos???

Not yet. My (old) digital camera doesn't do macro. I'll try and take a couple anyway.
Posted by: pgrzelak

Re: Success - 04/06/2004 18:21

Wow! I am just in awe!!! THANKS!!!
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 04/06/2004 18:26

Does the higher stacked RAM add any (extra) fragility to the player?

The stacking itself shouldn't - you've got 49 soldered connections holding each layer down. What will add fragility is that each layer takes the RAS wires closer to the IDE cable and that vibration could be transmitted through the cable to these wires that could cause them to work loose or (worse) pull a RAS pin off of a chip. This risk will be mitigated by gluing the wires to the tops of the chips where they cross to prevent them moving. I'm also going to run a length of electrical tape across the top for extra protection. Hmm. Maybe I'll hotglue a small piece of polycarbonate across instead - less 'gooey'.
Posted by: pgrzelak

Re: Hijack v394: support for up to 64MB DRAM on Mk - 04/06/2004 18:30

Would the longer IDE cables help in any way? I have a few of them that I meant to install next time I was inside the players...
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 04/06/2004 18:47

Would the longer IDE cables help in any way?

Might do. The issue is that this is where the cable bends under the end of the drive tray and that the cable doesn't naturally bend with a zero radius. I thought about either taping or gluing the cable to the underside of the tray to keep it raised up off of the chips, but I don't think that can be done with the stock cable because there wouldn't be enough slack to insert or remove the cable end on the motherboard header. A longer cable might make this a possiblity - if it does I'd recommend doing that as an additional precaution.
Posted by: mlord

Re: Hijack v394: support for up to 64MB DRAM on Mk - 04/06/2004 21:17

Go with the (very thin) polycarbonate instead. One really does NOT want to restrict the movement of longer IDE cables in any way -- defeats the whole purpose behind them.

Cheers (and congrat's!)
Posted by: russell

Re: Success well failure actually :-( - 05/06/2004 11:17

I successfully soldered in the extra bank with very little difficulty, Perfoming a Ctrl-T mem test before connecting the RAS line which passed first time. I then connected the RAS line to RAS#1 on the SA. But Linux didn't detect the RAM, ( V394 of Hijack) re checked all pins with a meter and touch up a couple. But still no good, downgraded to hijack.mk2a-32mb.zImage and the modified 0e1000 image. got errors from the ramtest in the kernel, but they were the same with and without the RAS line connected!
More out of deperation than anything I removed the chips and tried a second set. Same result!

These chips were sent to the UK by Airmail is there any chance they were damaged in transit, I know a while back the US were nukeing post as a precaution. Is this still happening, or have i just f##ked up, should I order another set do you think?

On a plus note the player still works!!!
Posted by: pgrzelak

Re: Success well failure actually :-( - 05/06/2004 11:34

Greetings!

I don't think they are irradiating stuff anymore. If they did, I would not think that the envelope would survive with the chips being nuked.

Do you have any saved log files or boots that might show errors or if some of the RAM is being seen? It might just be a solder bridge or one line.
Posted by: genixia

Re: Success well failure actually :-( - 05/06/2004 11:35

Boot logs would be useful (the memory test in particular). From the description it sounds like an issue with your RAS line.

To disable the extra RAM you have to tie its RAS pin high to VDDX on the SA. It's active low and will probably interfere with the original RAM is left floating. VDDX is available at pin 120.

I find it highly unlikely that two sets have been damaged in transit. Try again.
Posted by: russell

Re: Success well failure actually :-( - 05/06/2004 11:43

Thanks, I'll try again tommorow. Only thing is the chips ( and my empeg are covered in flux, whats the best way to remove this before i start? )

Attached is the boot log for the last attempt
Posted by: mlord

Re: Success well failure actually :-( - 05/06/2004 11:47

Sounds like you perhaps were not getting the bank select pin correct.

-ml
Posted by: genixia

Re: Success well failure actually :-( - 05/06/2004 20:29

Any photos???

Photo Album.

Excuse the dodgy 'macro' shots.
Posted by: pgrzelak

Re: Photographs and memories... - 06/06/2004 07:41

Photographs and memories... (How many people recognized the reference there?)

Wow!!! Very nice!!! Excellent work!!!

I am just wondering if there is any easier way of dealing with the RAS pins for other installation. They seem incredibly fragile with only two chips stacked, let alone three... Note: I am not good at this kind of thing, so I leave it to the experts to see if there are any alternatives...

But - just a thought: all of the other pins need to be straighted to make contact with the chip below it. What if the RAS pin is left bent (as original from the package) or rebent so that the bottom portion of that pin is flush against the bottom of the chip? Would it be possible to use a small piece of cardboard with a conductor on it, or a very thin wire (I am thinking circuit board trace material here), place it under the chip and solder and secure the RAS line to it from below before placing it on the stack? Run that thin wire between the stacked chips rather than above. It might be more stable and, because the RAS pin doesn't need to be bent back, might be easier for RAS soldering with less risk of the pin breaking off. I do not know how much of a gap you can have between chips - this might be too much.

A thought. I am just trying to see if there is a way to make it easier - losing a RAS pin seems both a common problem and annoying to fix.
Posted by: russell

Re: Photographs and memories... - 06/06/2004 08:22

Thats more or less what i'm going to try this afternoon, i've got some very thin enambled wire that i'm going to try runing under it's chip and out the bottom. can't think of a nice way of joining the two chips together so i guess it will be a solder joint at the bottom of the middle chip..

On another note which of the two chips is the Low half of the bank?

Is 64MB our max or could we replace the existing chips with 16mb versions and run the extra address line to the SA! 128mb would be intresting!

R.
Posted by: BartDG

Re: Photographs and memories... - 06/06/2004 08:32

According to Hugo, IIRC, 64Mb is indeed the maximum amount of memory the Empeg will take.
Posted by: skibum

Re: Photographs and memories... - 06/06/2004 08:52

according to the guy that develops linux for the sa1100 cpu, it can take 128mb (32mb per bank). Now whether our little empegs can use 16mb chips is a different matter.
Posted by: russell

Re: Photographs and memories... - 06/06/2004 10:13

According to the SA data sheet it can take 128mb per bank, but i'm guessing that those chips would have a higher pin count!

R.
Posted by: mlord

Re: Photographs and memories... - 06/06/2004 10:26

The SA-1100 CPU (Empeg/RioCar) can have up to 128MBytes of DRAM per bank. The processor supports up to four banks, so the absolute hacker's limit on the Empeg/RioCar is 512MBytes of DRAM without adding any more external logic.

The practical limit appears to be 48MB, but it may be possible to install 16MB chips in place of the current 8MB chips, which would give a practical limit of 96MB.

Cheers
Posted by: BartDG

Re: Photographs and memories... - 06/06/2004 10:34

If it's possible to use 16MB chips, wouldn't it be easier to use those then? I imagine it must be easier to desolder those 8MB chips and put 16MB chips in their place (to reach 32MB, which I think would be enough), than to piggy-back chips ontop of each other. There would also be less risk of breaking a pin on the chips while soldering them.
(this is just guesswork from my part ; I can't solder to save my life !)
Posted by: mlord

Re: Photographs and memories... - 06/06/2004 10:38

No, actually.

It is MUCH easier and safer to just piggy-back on top of the existing chips, for the first (added) layer. Beyond that, it's probably easier to remove all and solder directly to the pads. But not safer. It is always safest to leave the existing working factory chips in place. No doubts.

Cheers
Posted by: BartDG

Re: Photographs and memories... - 06/06/2004 11:21

Ah, ok, I stand corrected !
Posted by: SonicSnoop

Re: Photographs and memories... - 06/06/2004 11:22

Ok guys I expect you to have the 512MB hack worked out by this weekend so I can get someone to do mine..
Posted by: russell

Re: Photographs and memories... - 06/06/2004 13:36

Does anyone one which pins are likely to be the cause of this error
0110 testing ic 1 (0-15mb, low word)
0101 memory error at c0000000 (00000000!=0000257f)

I've just installed the first additional 16mb but can't see anything wrong with the soldering

Thanks
R.
Posted by: pgrzelak

Re: Photographs and memories... - 06/06/2004 14:03

At a guess, I would say that it would be a bad RAS pin on one of the banks. That is just a guess, though.
Posted by: genixia

Re: Photographs and memories... - 06/06/2004 18:36

I am just wondering if there is any easier way of dealing with the RAS pins for other installation.

You are correct in recognising that the RAS pins are the problem. RAS pin management is the key to this - getting the other 49 pins soldered is relatively easy.

Part of the problem is that all the other pins need to be aligned for good contact so you cannot straighten the pins individually - they have to be done together.

Having had to desolder one of the stacks gave me an insight that I think will be useful - it isn't difficult to desolder a pin because of the relatively limited contact area. I am considering next time building up the stack _including_ the RAS pin, metering all the pins to eliminate as many bridges or open connections as possible and only then to heat the RAS pins and bend them out. ie, keep the RAS pins safely tucked away for as long as possible.

This wouldn't help if you had bridge/open near to the RAS pin taht you didn't discover until a boot test as you'd still have to retouch that pin, but I think it is a workable proposition.
Posted by: gbeer

Re: Photographs and memories...A suggestion - 06/06/2004 19:00

Only a suggestion since I'm not trying to upgrade my player.

I'm wondering if some aluminum foil would be useful here. Stick the stack together with a bit of double side. Then take two strips of foil and slip them between colums of pins, fold back and around. Admittedly this may be easier said than done. The alum, if it will stay in place, should keep the solder from bridging. Hummm, some more two side tape, not near the pins, could help. Maybe all that is needed is a piece of foil with a slit in it. Tuck the slit down around the column of pins...

I hope some of this helps.
Posted by: genixia

Re: Photographs and memories... - 06/06/2004 20:03

The practical limit appears to be 48MB, but it may be possible to install 16MB chips in place of the current 8MB chips, which would give a practical limit of 96MB.

Well, assuming that don't want or need to remove the original chips then that would really give us a practical limit of 32+32+16 = 80 MB.

More to the point, 16MB chips would be a far nicer way to get to 48MB. I'd much rather do that than stack 3 up, but Micron never made a 16MB chip in that configuration (EDO/FPM, 50 pin TSOP), but instead went to SDRAM, 54 pin TSOP II. Does anyone know if any manufacturer did make a compatible 64MB chip?
Posted by: mlord

Re: Photographs and memories... - 06/06/2004 22:27

I am considering next time building up the stack _including_ the RAS pin, metering all the pins to eliminate as many bridges or open connections as possible and only then to heat the RAS pins and bend them out
And my strategy is the near-exact opposite Bend and solder the recalcitrant RAS pins as soon as possible in the process, so that not much work need be undone should they snap off!

Cheers!
Posted by: Folsom

Re: Photographs and memories... - 07/06/2004 07:57

It is MUCH easier and safer to just piggy-back on top of the existing chips, for the first (added) layer.


If you have a good heat gun/pencil, it would have been much easier (at least for me) to reflow 16MB chips instead of piggybacking 8MB chips. The parts should come off easily, and since the pads are so big, it wouldn't be hard to add solder for reflowing.
Posted by: SE_Sport_Driver

Re: Photographs and memories... - 07/06/2004 09:27

My cat's breath smells like cat food.
Posted by: skibum

Re: problems with memory - 09/06/2004 14:35

anyone got any clues on where the problem is with :-

Checking for extra DRAM:
c1000000: wrote ffffffff, read ffffefff
Posted by: skibum

Re: problems with memory - 09/06/2004 14:41

got
Checking for extra DRAM:
c1000008: wrote aaaaaaaa, read aaaaa2aa

now. getting somewhere
Posted by: genixia

Re: problems with memory - 09/06/2004 14:42

Pin 46 open. Stack nearest StrongArm.
Posted by: genixia

Re: problems with memory - 09/06/2004 14:44

Ok, pin 44 now, also open.



Posted by: skibum

Re: problems with memory - 10/06/2004 03:12

thanks for the quick response. After a few more attempts my mate got it right. Did get a complete ram failure at boot up initially. However, now both machines are 32mb
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk2a - 11/06/2004 13:07

Am i the first person to get 64mb working?
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk2a - 11/06/2004 13:09

And some pics
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk2a - 11/06/2004 13:09

Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk2a - 11/06/2004 13:11

Forgot to say a big thank you to PGrzelak and MLord, who have made this all possible.
Thanks guys.

Now i just need to get the car sorted out so i can do the install :-)
Russell
Posted by: speedy67

Re: Hijack v394: support for up to 64MB DRAM on Mk2a - 11/06/2004 13:14

no pics... too big? (200000 max)
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 13:14

Attachments no worky. Probably too big, limit is 200k IIRC.
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 13:23

whoops your right the limits 200k and these files are around 600k. I might put them up on a web page tommorrow if i can be bothered!
Posted by: skibum

Re: Hijack v394: support for up to 64MB DRAM on Mk2a - 11/06/2004 13:34

I think Paul is going to put a contract out on you (or your player)
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 13:40

If you want to claim that six-pack...

I would like to see some pictures. Did you modify the drive tray mounting at all? What techniques did you use? (Especially, how did you avoid losing RAS pins?)
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 13:53

Pics can be found at www.whitedwaft.co.uk
The sites not pretty but it works, someday i'll do a proper one!

With regards to the Beer, I think it would be way to expensive to send it over hear. ( and i have my own brewery :-)) so have a drink for me!

Russell
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 13:56

Ras pins were easy, i soldered a thin wire on from underneath then superglued it to the bottom of the chip and brought it out the end.

The Ras wires are held in place by daps of superglue onto the pcb

I havn't modified the drive tray. i can push it down to touch the chips, but it's never going to move that far on it's own, If it dows i will probably be killed by the impact that caused it!!!
Posted by: msaeger

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 13:58

That is madness. How long did it take to solder.
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 14:03

the first pair of chips took about 8 hrs all in but I had lots of errors.
the last 2 sets (32mb) took 4 hrs in total, i had no errors at all with the step from 32 to 48, but the final jump had a few missed joints.

Now if the very nice empeg people would release some software that would use the extra ram, i could start listening to my FLAC collection.

Russell
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 14:12

i soldered a thin wire on from underneath then superglued it to the bottom of the chip and brought it out the end.

I contemplated that but decided that there possibly wasn't enough pin spare to deal with the standoff created by the thickness of the wire (even 30ga). Obviously I was wrong.

Did that create any hassle?
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 14:37

It may have made it a little more difficult to solder one side down, but I think most of my problems were cause by the leads not being straight enough and at the right angle. and as i said 32 -48 was easy no problems at all!

Russell
Posted by: pgrzelak

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 16:40

That is sick, twisted and evil! Congratulations!!! !!!

By the way, you really should fsck your drives when you have time...

And if anyone is feeling lucky or adventurous and wants to order more RAM, I still have some left.
Posted by: loren

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 18:06

hold on to one or two for me... i think one of my chips is bad i just haven't had a free second to finish troubleshooting it.
Posted by: mlord

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 22:30

Very well done!!!

You win!
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 11/06/2004 22:36

He certainly does!

<Me checks fhe SA datasheet for RAS4>

Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/06/2004 02:27

now whos going to be the first person to use some external logic to go further :-))

Russell
Posted by: mlord

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/06/2004 14:53

Actually, external logic may not be needed -- the higher address lines are still there waiting for something to connect to them.. I suppose an invertor might be needed if the same size chips were used, but with larger chips..

Cheers
Posted by: pgrzelak

A Tommy moment, with apologies to The Who. - 12/06/2004 15:08

Greetings!

I had a brief moment of panic with LabRat today, just back from having been brought to 48MB of RAM. Plugged it into the car for the first time since the upgrade. Nothing. I could see it boot, but then it went into "Tommy mode" (deaf, dumb and blind). Nothing I did would get it to work. And me without a redundant player at the moment!!!

So I brought it back in under AC power. No problems. Reflashed. Same thing, same results. Then it finally struck me:

LabRat had never been in the car before! The dimmer was 0% (on a very sunny day with a clear lens), volume was -infinity, no beeps. So, no feedback, no matter what button or knob pressed (deaf); no audio out, beeps or anything (dumb); no visuals, screen display or even hijack menu (blind).

Duh.

Found it in the (dark) house with AC power in use, but forcing the player to think it was on DC. Adjusted my settings and now everything works fine!

Duh...

I thought I would share that with everyone, for your amusement...
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/06/2004 15:15

My Boolean algebra is a little rusty but this is the logic i belive would be nessecery

RAS1a= RAS1 and not A13
RAS1b = RAS1 and A13

I have no idea what effect this would have on chip refresh!

If someonw can confirm that this won't affect refresh, i have another 16mb here :-))

Russell
Posted by: tfabris

Re: A Tommy moment, with apologies to The Who. - 12/06/2004 15:36

went into "Tommy mode" (deaf, dumb and blind).
LOL, I'm going to have to remember that one for future re-use.
Posted by: mlord

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/06/2004 17:28

Something like that. But Hijack won't find or use anything beyond 16MB/bank on the Mk2a.

-ml
Posted by: altman

Re: Hijack v394: support for up to 64MB DRAM on Mk - 14/06/2004 06:25

I think the issue may also be that if you add more ram like this, it won't be refreshed by the CPU, hence won't actually store anything.

It's almost certainly not worth the hassle. If you wanted more memory beyond 64MB then you'd be better off putting a ramdisk on the IDE bus and swapping to it.

Hugo
Posted by: genixia

Re: A Tommy moment, with apologies to The Who. - 14/06/2004 09:34

<Must resist temptation to set Hermit's AC dimmer to 0%>
Posted by: pgrzelak

Re: A Tommy moment, with apologies to The Who. - 14/06/2004 09:36

AC Dimmer??? Neat concept, but...
Posted by: genixia

Re: A Tommy moment, with apologies to The Who. - 14/06/2004 09:50

Good point.

<Must resist temptation to set Force DC Mode and Dimmer to 0%>
Posted by: pgrzelak

Re: A Tommy moment, with apologies to The Who. - 14/06/2004 09:52

LOL. Much better!
Posted by: russell

Re: Hijack v394: support for up to 64MB DRAM on Mk - 14/06/2004 13:25

I thought that was the case, Looking at the datasheet for the SA all the banks have to be of the same configuration. Whilest it would be possible to add another 32 or 64 mb. I won't be the first to try that one!

64mb is plenty at the moment, as i'm not currently running any other software. It would be nice if the player could be tweaked to use more ram especially for those of us wishing to play FLAC's etc.

Russell
Posted by: altman

Re: Hijack v394: support for up to 64MB DRAM on Mk - 14/06/2004 23:54

Yep, a release which deals with extra memory is high on the list of things to get done

Hugo
Posted by: skibum

Re: Hijack v394: support for up to 64MB DRAM on Mk - 15/06/2004 02:09

Hugo iis this likely to be a new v3 (alpha or beta) or maybe a v2.01 or similiar?
Posted by: andym

Re: Hijack v394: support for up to 64MB DRAM on Mk - 15/06/2004 04:06

I seem to remember something about V2.00 staying as it is and all changes are made to the current code (V3).
Posted by: msaeger

Re: Hijack v394: support for up to 64MB DRAM on Mk - 15/06/2004 06:09

I was detecting sarcasm in that post but maybe it's just me ?
Posted by: tfabris

Re: Hijack v394: support for up to 64MB DRAM on Mk - 15/06/2004 09:12

Hugo iis this likely to be a new v3 (alpha or beta) or maybe a v2.01 or similiar?
There will not be a 2.01. Another release of the V3 alpha code is likely. If tradition holds, Amersfoort will be The Place To Be...
Posted by: skibum

Re: Hijack v394: support for up to 64MB DRAM on Mk - 15/06/2004 09:14

Well I'm off to Amersfoort this year so thats what I was hoping anyway.

I'd just prefer a v2 as its nice and stable and I don't require anything that v3 currently gives me.
Posted by: SE_Sport_Driver

Re: Hijack v394: support for up to 64MB DRAM on Mk - 15/06/2004 16:25

Naw, V3 is the way to go. I'm just waiting for it to emerge from the Alpha stage.
Posted by: bjoern

Re: Hijack v394: support for up to 64MB DRAM on Mk - 16/06/2004 00:23

Hmmm interesting and long thread. Will there possibly be a write-up of the procedure, similar to the disk upgrade page? I'd be interested in memory upgrading, but I'm not confident enough I'd get all the important steps right without some nice documentation.
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 16/06/2004 11:57

This is one of those "If you really have to ask then perhaps you shouldn't be doing it" kind of mods. The pitch of the memory chips' pins is 0.8mm. The CPU pins have a pitch of a mere 0.6mm.

But since you asked;

1). Wear an antistatic wriststrap, use an ESD-safe temperature-controlled soldering iron. and plenty of flux.
2). Straighten the pins on the new chips so that they will reach the old chips. Bend the RAS pins out slightly.
3). Solder the new chips to the old chips, pin for pin with the exception of the RAS pins.
4). Use a continuity meter to probe for open and bridged pins.
5). Wire both RAS pins on the new chips to RAS1 on the StrongArm.
6). Test, decipher any memory error messages using the memory datasheet to identify pins*.
7). Retouch problem pins to remove errors.
8). Test and rejoice.

The SA1100 datasheet is easy to google for, and Micron keep the memory datasheet available in their support section.

* - To decipher error messages;
The memory test uses 4 patterns written across the data lines, 0x00000000, 0xFFFFFFFF, 0xAAAAAAAA, and 0x55555555.

0x00000000 - An error from this write is usually caused by a data pin shorted to an adjacent VDD pin.
0xFFFFFFFF - An error from this write is caused either by a data pin shorted to an adjacent VSS pin or more usually by an open connection.
0x55555555 and 0xAAAAAAAA are caused by two adjacent pins shorted together - the patterns translate to binary 0101...0101 and 1010...1010 respectively. What should be a zero comes back as a one because of the short.

The error message reports what was written and what was read. Compare one to the other and see where the error is. The highest 16 bits of the data are on the chip furthest from the CPU.

So for example, "wrote 0xFFFFFFFF, read 0xFFAFF1FF" can be broken down to;

Chip furthest from CPU - 0xFFAF. We can futher break this down visually - 0xFF means that the high 8 bits are correct, 0xAF means that the lowest 4 bits are correct, and the problems are in D7...D4. 0xA is binary 1010, so the problem pins are D6 and D4, both low when they should be high. Looking at the datasheet you will see that pins 7 and 9 are probably open.

Chip nearest CPU - 0xF1FF. Breaking it down again, lowest 8 bits are fine as are topmost 4 bits, problem is in D11...D8. 0x1 is binary 0001. Pins D11, D10 and D9 are all low when they should be high. Looking at the datasheet shows that pins 44, 43 and 42 are the culprits. You will also notice that pin 45 is Vss, so it's possible that one or more of those pins are shorted together with pin 45. Or they might simply be open.

Another example, "wrote 0xAAAAAAAA, read 0xAAAAAAEA";

Problem is in lowest 16 bits, ie chip nearest CPU, 0xAAEA. Further breaking it down, highest 8 bits and lowest 4 bits are fine, problem is in D7...D4.
Wrote 0xA = binary 1010. Read 0xE = binary 1110. Problem is D6 high when it should be low, shorted to either D7 or D5. Datasheet gives D6 as pin 9. (D7= 10, D5 = 8)

There are three problems that won't fall into any of those error classes. A bad RAS connection or a bad OE connection can both manifest as an error where the whole chip refuses to talk back, such as the error that Stu had earlier in this thread.
A totally non-booting empeg, or one that crashes even after passing the memory test is usually caused by soldering errors on the address lines. Some errors will prevent the flash from being read and hence the kernel can't load, whereas others won't affect the player until the kernel attempts to use the memory space impacted.
Unfortunately it isn't possible to debug this further to individual pins.

For 48MB, rinse and repeat using RAS2 on the CPU.
For 64MB add another spin cycle using RAS3.

Note that 48MB or more increases the physical complexity signicantly and is really not recommended.

BIG FAT DISCLAIMER - I ACCEPT NO RESPONSIBILITY FOR ANY ACTIONS TAKEN UPON INFORMATION CONTAINED WITHIN THIS PURELY INFORMATIONAL POST.

Posted by: RobotCaleb

Re: Hijack v394: support for up to 64MB DRAM on Mk - 16/06/2004 14:46

holy crap
nice write-up
Posted by: bjoern

Re: Hijack v394: support for up to 64MB DRAM on Mk - 17/06/2004 01:34

Cool write-up, thanks!

I sort of figured that it's a "if you really have to ask then perhaps you shouldn't be doing it" kind of mod. But from what I've learned from this thread, all you theoretically need is a steady hand, good equipment and good instructions.
I work at a university, so we have the equipment. I'm a biologist and have dissected fruitfly brains out of their head capsules under a dissecting 'scope (yes, the tiny flies that start buzzing around your house if you let fruit sit on your table for too long), so I got the steady hand. But I'm by no means an electronics freak, so I couldn't figure any of this out on my own. I've built PCA's tuner kit, but I don't know if it's working, because I haven't had time to test it, yet.
But maybe I could get the RAM upgrade done if the instructions were detailed enough?
I dunno, you tell me

So I see the RAS is on pin 14 of the memory chip you linked to. And on the StrongArm it's pin 18, according to this datasheet.
From the pics in this thread it all seems to be a matter of proper soldering? Also, I take it that the #1 pins need to be matched?
How much are the memory chips and are they easily obtainable in any reasonable electronic store? On the micron page, e.g., I find three products linking to the datasheet you provided. Which of these is it? Also, I couldn't find any prices on micron.com.

Again, thanks a lot for your write-up!
Posted by: pgrzelak

Re: Hijack v394: support for up to 64MB DRAM on Mk - 17/06/2004 04:24

I thought I knew most of the basic concepts for biology, but I have never heard of dissecting fruit flies. That certainly makes you qualified on the coordination front. But I have to ask - I can understand removing a friut fly's brain, but what studies can you do based on that?

As for some of the other questions, those I can answer. The exact part number you should watch for is MT4LC4M16R6TG-5. I have already done a bulk purchase of the memory chips for folks on the board. See instructions in this thread. You might be able to get them from an electronics store, but I have not really seen them available. This was a bulk order from a parts locator company that specializes in buying remainders, etc. The memory is obsolete now (according to the datasheet on the Micron site), so you do not see it often except in older devices.
Posted by: bjoern

Re: Hijack v394: support for up to 64MB DRAM on Mk - 17/06/2004 05:43

But I have to ask - I can understand removing a friut fly's brain, but what studies can you do based on that?
You can use various techniques to visualize e.g. three-dimensional gene expression in the brain:
http://www.flybrain.org/Flybrain/html/vrml/3dbrain.html
That link is fairly old, but shows the basics.

So I just PayPal you $33 and will get the ram in the mail? Hell yeah I'll do that. It'll take me years to find the time to install them, but at least I know I can do it any time
Posted by: pgrzelak

Re: Hijack v394: support for up to 64MB DRAM on Mk - 17/06/2004 06:35

Cool link! I knew that genetics was one of the big fields of study for fruitflies, but I had not know this. Excellent.

As for the PayPal, you are correct. I have plenty here...
Posted by: mlord

Re: Hijack v394: support for up to 64MB DRAM on Mk - 17/06/2004 08:02

RAS1 is pin 123 of the StrongArm, not 18.

-ml
Posted by: bjoern

Re: Hijack v394: support for up to 64MB DRAM on Mk - 17/06/2004 08:50

Ok, so I should add "connect pin 14 on the memory chip with pin 123 of the StrongArm" to the write-up.
The problem then is, how do I count the number of pins on the StrongArm? The pin numbering seems clear from the memory datasheet, but it's not that clear from the datasheet for the StrongArm. Or is there a datasheet where I can see which pin is pin #123?
Like this one? But here RAS1 is pin 133? And it doesn't show which pin is the number 133 pin either.
Posted by: mlord

Re: Hijack v394: support for up to 64MB DRAM on Mk - 17/06/2004 09:01

Manual and pinout (page 14-1) are available for the SA-1100 CPU at this location.

-ml
Posted by: bjoern

Re: Hijack v394: support for up to 64MB DRAM on Mk - 18/06/2004 00:32

Fantastic! Thanks!
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 18/06/2004 10:31

Do you think there would be any added concerns with handling the player?

Just to revisit this topic... I did some calculations;

The smallest in-tolerance pin size is 0.3mm wide by 0,13mm thick. Assuming that only the end of the pin is in contact with the pin below, that gives a contact surface area of 0.039mm^2.
One square inch is 25.4^2 mm^2 or 645.16mm^2. That means we have a contact area of 0.039/645.14 = 6.045x10^-5 square inches per pin. 49 pins are connected, so that gives a total surface area of 0.00296 square inches.

The tensile strength of 63/37 solder is given as 7500 psi. That means that the force required to break the joints is 7500x0.00296 = 22.2lbs, or near exactly 100N.

ie, if you attached a mass to the top chip and turned your empeg upside down then the smallest mass needed to pull the chip off would be 10Kg.

Repeating the calculations for tip only contact with the maximum in-tolerance pin size gives an answer of 46lbs or 210N (21Kg mass).

I don't think we need to worry.
Posted by: pupvogel

Re: Hijack v394: support for up to 64MB DRAM on Mk - 22/06/2004 09:00

Hi folks,

I'm trying to upgrade my player to 32MB, but now I get this at boot-time:

empeg-car bootstrap v1.02 20001106 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux.....(data abort vector)


So I tried to re-install the V2.00 kernel, but when the Upgrade Process starts, I get:
Error "Hardware revision check failed" occurred during stage 0x04.

Any ideas ?
Posted by: pgrzelak

Re: Hijack v394: support for up to 64MB DRAM on Mk - 22/06/2004 09:13

Check for solder bridges between your pins. You may have a few lines tied together, and it is causing the original memory chips to fail.
Posted by: skibum

Re: Hijack v394: support for up to 64MB DRAM on Mk - 22/06/2004 09:29

That happened a few times when my players were being done. Scared the sh*t out of me. However, no harm done. Do as Paul said and check for bridges. Its funny, 1 of my players went from this error to 32mb in 30secs :-)
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 22/06/2004 09:33

Pay particular attention to the address lines. A bridge is preventing the flash from being read.
Posted by: pupvogel

Re: Hijack v394: support for up to 64MB DRAM on Mk - 22/06/2004 10:32

Thanks guys, good to know there's still hope !
But dammit...I really think I need to get some more light here !
Posted by: bjoern

Re: Hijack v394: support for up to 64MB DRAM on Mk - 23/06/2004 06:53

use an ESD-safe temperature-controlled soldering iron

What temperature do I need to set the iron to?
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 23/06/2004 08:49

Try 450F and see how you get on. Whatever you do, don't go above 550F.
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 25/06/2004 13:03

I've recently re-upgraded my empeg to 64MB to see whether it was feasible to do on Paul's players. I've decided that it's just too risky, but here are some photos of the upgrade. Note that I raised the drivetray to get more clearance.
Posted by: andym

Re: Hijack v394: support for up to 64MB DRAM on Mk - 25/06/2004 14:12

Yup, those photos are proof I'd rather stick with 32MB.
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 28/06/2004 22:36

Yup, those photos are proof I'd rather stick with 32MB

What? Too many RAS wires for your liking?
Posted by: andym

Re: Hijack v394: support for up to 64MB DRAM on Mk - 29/06/2004 08:54

What? Too many RAS wires for your liking?


Those bloody RAS wires, I just can't get the buggers to solder together. I just don't seem to be able to tin the pins and then heat the wire and pin together properly.
Posted by: bjoern

Re: Hijack v394: support for up to 64MB DRAM on Mk - 01/07/2004 13:13

Worked first try! 32MB available:
Quote:
Checking for extra DRAM:
c1000000: passed.
c1100000: passed.
c1200000: passed.
c1300000: passed.
c1400000: passed.
c1500000: passed.
c1600000: passed.
c1700000: passed.
c1800000: passed.
c1900000: passed.
c1a00000: passed.
c1b00000: passed.
c1c00000: passed.
c1d00000: passed.
c1e00000: passed.
c1f00000: passed.
c2000000: wrote ffffffff, read 00000000
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 10101626) 32MB DRAM
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 31240k/32M available (980k code, 20k reserved, 524k data, 4k init)


But now I get weird stuff after it detects my harddrive. My primary harddrive died, so there's only my secondary in there now (without jumper = master). It started the player just fine before the RAM upgrade...
Will that go away once I add the new primary drive?

Quote:
empeg single channel IDE
Probing primary interface...
hda: IC25N080ATMR04-0, ATA DISK drive
hda: IC25N080ATMR04-0, ATA DISK drive
hda: IC25N080ATMR04-0, ATA DISK drive
hda: IC25N080ATMR04-0, ATA DISK drive
hda: IC25N080ATMR04-0, ATA DISK drive
hda: IC25N080ATMR04-0, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: IC25N080ATMR04-0, 76319MB w/7884kB Cache, CHS=9729/255/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman (erik@vt.edu)

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:22:06:5a
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
Timezone: /usr/share/zoneinfo
Unable to handle kernel paging request at virtual address 0000df20
memmap = C0004000, pgd = c0004000
*pgd = c012f801, *pmd = c012f801, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c00330e0>] lr : [<c0033a34>]
sp : c01f7f84 ip : c01f7f94 fp : c01f7f90
r10: c0103fc8 r9 : c0108704 r8 : 00000002
r7 : 00000004 r6 : 00000001 r5 : 00000000 r4 : c1f79aa0
r3 : 00000004 r2 : 00000000 r1 : 0000df20 r0 : c1f79aa0
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel
Control: C000517D Table: C000517D DAC: 0000001D
Process kupdate (pid: 3, stackpage=c01f7000)
Stack:
c01f7f60: c0033a34 c00330e0 60000013
c01f7f80: ffffffff c01f7fb0 c01f7f94 c0033a34 c003300c 00009a20 0000004e 00000001
c01f7fa0: 00000004 c01f7fe0 c01f7fb4 c003512c c00339cc c1f79aa0 00000001 c01f6000
c01f7fc0: c0104024 c0108794 c0100988 4401a11b c0008580 c01f7ffc c01f7fe4 c0035790
c01f7fe0: c00350a0 c0035720 c012b84c c0100760 c0003fb4 c01f8000 c000b6ec c003572c
Backtrace:
Function entered at [<c0033000>] from [<c0033a34>]
Function entered at [<c00339c0>] from [<c003512c>]
r7 = 00000004 r6 = 00000001 r5 = 0000004E r4 = 00009A20
Function entered at [<c0035094>] from [<c0035790>]
r10 = C0008580 r9 = 4401A11B r8 = C0100988 r7 = C0108794
r6 = C0104024 r5 = C01F6000 r4 = 00000001
Function entered at [<c0035720>] from [<c000b6ec>]
r6 = C0100760 r5 = C012B84C r4 = C0035720
Function entered at [<c001d36c>] from [<c0009b40>]
r10 = C0008580 r9 = 4401A11B r8 = C0122580 r7 = C0108794
r6 = C01218CC r5 = C0100768 r4 = 00000008
Function entered at [<c00099b4>] from [<c0009ba4>]
r8 = C0100988 r7 = C0100764 r6 = C0100760 r5 = C012B84C
r4 = C0009B94
Function entered at [<c0009b94>] from [<c000b6ec>]
r7 = C0100764 r6 = C0100760 r5 = C012B84C r4 = C0009B94
Function entered at [<c00096c4>] from [<c00098b0>]
Function entered at [<c00096dc>] from [<c0008080>]
r7 = C0121DA0 r6 = C0121CF4 r5 = C012C280 r4 = C012C280
Code: e5821034 e5803000 (e5812000) e59f10a8 e3a02000
Posted by: bjoern

Hijack v395 - 01/07/2004 18:10

I just found out that this just happens with hijack (394 and 395), not with the standard kernel. It happens with any of my disks in it, I just installed the new primary one.
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 05/07/2004 14:15

Double-check the address lines.
Posted by: bjoern

Re: Hijack v394: support for up to 64MB DRAM on Mk - 06/07/2004 03:58

Thanks! Even though all my pins measured between 0.3 and 0.5 Ohms, I just retouched every single pin (just for the Halibut). Now everything works perfectly! Thanks so much for you patience with me!
Posted by: peakmop

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 00:24

Whew, spent almost whole day on memory upgrade - now with 64MB RAM.
The chip stacking and soldering part was easy. The fourth level was soldered in about 40 min. I believe the trick is to use the smallest diameter solder wire or not use the solder at all if lower levels contain enough of it to be able to "paint" the upper joint. Even RAS pins were not that bad. For those pins I broke off the lower half of the pin and bent the pin half way up before bending the rest of the pins.
The worst part were the wires. I've got those teflon insulation ones which is a pain to strip. The hardest part with the wires was to solder three 30GA wires to RAS1,2,3 pins on the CPU.

Thanks to Paul for making the memory chips available.
Now I can do native compilation on the unit

The obligatory photo is included.
Posted by: adavidw

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 03:55

ooh, a heat sink!
Posted by: JBjorgen

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 11:11

Probably the nicest looking one I've seen yet.
Posted by: genixia

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 12:37

Very neat. One thing though - the corner of your heatsink is likely to eat your IDE cable.
Posted by: pgrzelak

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 12:41

<Homer voice>

Mmmm... ribbon wire...

</Homer voice>
Posted by: peakmop

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 13:29

Thanks!
About IDE cables - I actually couldn't even install the hard drive cradle on the top of the heat sink with existing ribbons. So, here's what I did... (see the attached picture)

No ribbon cable troubles any longer. Besides, I separated the ribbon part that goes to the empeg connector. I used to have problems of bad IDE connection and received a lot of IDE errors upon boot. After I separated the wires and put some dielectric grease on the header connector, all my problems went away.
Posted by: peakmop

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 13:34

On the additional note, here's what the empeg without the top cover looks like these days... (the picture is attached).
I don't have the fancy translucent buttons and front panel (yet), but I try to lobby for those on the other forums
Posted by: SE_Sport_Driver

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 19:31

OMG! That's sweet!

So you just put some dielectric grease on the pins of the IDE head and drives before you put the cable on? Where are you getting power for the fan and how is it mounted to the top of the drives?
Posted by: andym

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 21:35

Shame, what you guys are doing looks likely to be made redundant by something I've seen at Amersfoort, I won't say anymore but suffice it say I'm glad I didn't modify the spare!
Posted by: andy

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 21:39

Quote:
I won't say anymore but suffice it say I'm glad I didn't modify the spare!


Patrick's new approach to memory upgrades has already been discussed here:

http://empegbbs.com/ubbthreads/showflat.php/Cat/0/Number/225341/an/0/page/0#225341
Posted by: peakmop

Re: Hijack v394: support for up to 64MB DRAM on Mk - 12/07/2004 21:52

Quote:

So you just put some dielectric grease on the pins of the IDE head and drives before you put the cable on?


Yes, exactly the same way you put some of that grease on the automotive bulb and screw it in.

Quote:

Where are you getting power for the fan and how is it mounted to the top of the drives?



Check out this site I basically followed the instructions
I didn't however attach the fan to the top cover but rather to the hard drives using double sticky tape. I attached only rear of the fan with the front raised on the foam stands so there is a way for air to pass through. I also taped the top of the fan with the same tape but left the top side covered so it won't stick to the empeg cover.
The nice thing is that the fan turns off whenever empeg is in a standby mode. I have the ability to regulate the fan speed so once empeg plays I never hear the fan.
Posted by: mdavey

Re: Success - 23/09/2004 17:56

Well, I've just spent the last 6 hours upgrading my MK2a from 16MB to 32MB. This must be the least productive hardware upgrade i've ever undertaken!

Now, I've been soldering things since the age of about 10 (I am currently 28), including some rather bizare mods involving surface mount components on NetStations (don't worry, probably only means something to Hugo, and even then not much), so I wouldn't consider myself a amateaur.

All I can say is that is is way more difficult than, say, replacing the surface mounted StrongArm chip.

The things that, IMO, make this hack difficult are:

a) that the legs on the memory chip are very fragile and very small and very hard to straighten. Even then, they are only just long enough and you have to get them all at exactly the right angle, which is just shy of 90 degrees

b) you definately need a high-strength freestanding magnifying glass. My eyesight is very good yet there is no way I would have been able to complete the work without a glass (I did try, before giving in).

c) The solder prefers to bridge adjacent pins than join the two chips if there is even the tinest gap between the bottom of the pins on the top chip and the top of the pins on the bottom chip. I would very strongly recommend the use of a no-clean flux pen. Maplin (code HH62) and RS sell them.

It would certianly be useful to have all the info in one place (took me an age to find everything I needed on the bbs) - I might look to start doing just that over the weekend if I get a chance, then ask Tony to update the FAQ.

I won't be doing another one of these in a hurry, and definately won't be trying for 48MB or 64MB using this method. Howerver, no broken pins and I do get:
c1f00000: passed

Thanks to mlord, pgrzelak, Hugo, Stu and everyone else who helped to make this possible.
Posted by: tfabris

Re: Success - 23/09/2004 18:00

Quote:
I might look to start doing just that over the weekend if I get a chance, then ask Tony to update the FAQ.


That's a good idea. Someone should maintain a comprehensive memory upgrade page with instructions and photos and such. You want to do that?
Posted by: JBjorgen

Re: Success - 23/09/2004 18:03

I'll bring a camera to the meet this weekend and try to get some photos of genixia upgrading some empegs. If I can figure out how to use my buddy's Digital Rebel....
Posted by: loren

Re: Success - 23/09/2004 18:17

Yeah, i have the RAM chips sitting there but i haven't had the time to dredge up all the pertinent info, so i haven't done it yet. A guide would be super appreciated.
Posted by: mdavey

Re: Success - 23/09/2004 18:51

Quote:

That's a good idea. Someone should maintain a comprehensive memory upgrade page with instructions and photos and such. You want to do that?


Who looks after empegbbs.com and riocar.org? Could we get a wiki setup on one of these sites? It would make looking after information such as this a lot easier in the long run.

I'd be happy to colleate the information, but my contributions are somewhat erratic, so it would be good if the community as a whole were able to maintain it in my absence.
Posted by: mdavey

memory - random requests for information - 26/09/2004 16:43

Hiya,

So, I've started on the instruction manual for memory upgrades and have some random questions.

Can anyone point me at a datasheet for the MK1/MK2 memory chips (the ones that Hugo claims to have thousands of!). They are 1Mx16 TSOP-42.

Does anyone have a nice hi-res, in-focus image of either the chips for the MK1/MK2 or the MK2a before installation (ideally on a pale background)?

Does anyone have any installation images and boot-up logs for a MK1?

Many thanks,
Posted by: maczrool

Re: memory - random requests for information - 26/09/2004 18:11

I have the datasheet. If you would like, we can take pics of the memory chips and an MK2A before installation. The camera is a 12 MP S2 SLR with a dedicated macro lens. E-mail me if interested.

Stu
Posted by: mlord

Re: memory - random requests for information - 26/09/2004 23:26

Well, that's really a 6mp by anyone's count other than Fuji's. Still more than good enough for a <1mp web pic.

Cheers!
Posted by: maczrool

Re: memory - random requests for information - 27/09/2004 22:34

Actually resolution tests put in at about 9 MPs.

Stu
Posted by: loren

Re: memory - random requests for information - 21/10/2004 17:57

How goes the manual?! =]
Posted by: mdavey

Re: memory - random requests for information - 21/10/2004 19:16

Quote:
How goes the manual?! =]


Pretty much finished. I need to edit a couple of photos and check the quality of a couple of other ones. I am also waiting for one person to get back to me about permission to use their words, but haven't chased.

Actually, I have been finding it hard to motivate myself (mild depression) - I have been putting off getting this finished. I'll try to finish it over the next couple of days.

BTW, if anyone has memory installation pictures for a MK1, it isn't too late to include them in the manual - so please PM me.

Sorry for dragging my heels.
Posted by: loren

Re: memory - random requests for information - 21/10/2004 20:01

Hey man, no rush. I was just curious because i'm about to have a go at it... or send it to someone depending on how difficult your how-to looks! =]

Thanks again for doing it at all!
Posted by: mlord

Re: Thoughts of more RAM... - 30/08/2019 20:59

Today I decided to upgrade another of my Mk2a players to 32MB RAM by stacking a chip on top of each of the two existing chips. My eyesight is not as sharp as it once was, and my memory definitely isn't!

I put the two chips on using the ultra-fine 0.1mm tip on the soldering iron. BIG mistake. That tip is way too small to hold sufficient heat or sufficient solder. After fussing for a while trying to get the new chips to pass the memory test, I clued in and put the 1/32" tip on the iron instead, and then re-soldered all of the pins. Worked first try after that!

One useful thing I saw while fussing around during the non-functional stage, was that the Hijack memory test has had a slight bug. I got this message and the player continued without recognizing the extra RAM:
Code:
Checking for extra DRAM:
c1000000: wrote ffffffff, read ffffffff

So.. it wrote ffffffff and read ffffffff.. but still failed the test? BUG! Hijack wasn't caching the readback value for use in the error message, so when printing the wrote/read message it actually read it AGAIN.. getting the correct value after first having read an incorrect value. So I've fixed that now (Hijack v525 will be out shortly), and also added the missing mb() memory barrier there too. smile

So.. anyone else doing a new memory upgrade would be best served to have Hijack v525 installed before doing the upgrade.

Cheers!
Posted by: mlord

Re: How things could become more difficult... - 31/08/2019 14:06

Thusly encouraged, and still having a few more RAM chips in the box, I decided to tackle yet another memory upgrade while the technique was fresh in mind.

For some reason, this time I had more trouble straightening the pins on one of the two chips, but managed it after 10 extra minutes of fussing. The soldering went well (using the 1/32" tip this time!), and I hooked up the RAS1 line to the SA1100 and powered it on.

Nothing. Nada. Well, okay, blue LED at rear of player was lit, but nothing at all on the serial port.

20 minutes of panic and stuff later, and I finally touched up the solder on the SA1100 pins around the recently freed RAS1 pin. Success! Must have removed too much solder when lifting that pin. 90 minutes in all this time.

Maybe I'll stop now that I'm "ahead" (whatever that means).
Posted by: gmarsh

Re: How things could become more difficult... - 01/09/2019 23:48

My preferred tip for a job like this is a knife tip:

https://www.hakko.com/english/tip_selection/type_k.html

Put lots of flux on the pins and drag solder like you're soldering a LQFP to a PCB. Just make sure you get rid of the flux when you're done.

It doesn't look like there's any non-washable parts on the motherboard so don't be afraid of giving it a good soak in alcohol.
Posted by: mlord

Re: How things could become more difficult... - 01/12/2021 13:40

Another user was asking me for instructions on doing the memory upgrade, and I have pointed him back to this thread here.

But for some reason, I was unable to find a link to Stu's excellent Memory Stacking guide that he had on his Eutronix site.

So.. attaching it here now.