I-Appliance BBS
The Official Source for Internet Appliance Upgrades and Mods
Amazon Honor System Click Here to Pay Learn More
BBS Main List | Sign In | Sign Up | Search | Help | Linux-Hacker.netReply to Thread | Printer |

Home / MISC Areas / Mattel JuiceBox
Cartridge Update
Cartridge Update

New MessageCartridge Update (modified 0 times) prpplague
Profile
well folks had a breakthrough today!

was doing some reading about the different nand flash and ran across this page:

http://elm-chan.org/docs/sm_e.html


turns out smartmedia cards are NAND flash in removable media!

i grabbed a 32mb card from a local shop, proceeded to program it and solder it to the juicebox, and it works!

found this place to order prototype sockets from:

http://www.epboard.com/eproducts/parts/ESM-0015.htm

this will make it very easy to continue development as i can use a standard usb card reader to program the card.

08-30-2005 14:38:05

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile
i've tested with this card from samsung:

http://www.samsung.com/Products/Semiconductor/Flash/FlashCard/SmartMedia/32MByte/K9S5608V0B/K9S5608V0B.htm


its rebranded by several companies including simpletech:

http://www.superwarehouse.com/SimpleTech_32MB_SmartMedia_Card/STI-SM3_32/p/107153

this is recognized by the juicebox bootloader with no issues

08-31-2005 11:48:49

New MessageRE:Cartridge Update (modified 0 times) werejag
Profile
thats amazing thanks for the info.
08-31-2005 23:53:19

New MessageRE:Cartridge Update (modified 1 times) Tom61
Profile | Email
What's the largest size that the JuiceBox and bootloader can address?

Just a note, XD picture cards are just NAND flash as well. I didn't find the pinout for XD, but should be easy to figure out if anyone picks up a card reader that reads both SM and XD. Easier to find XD cards that are higher capacity, and it's not much bigger than SD.

Novel, here's an adapter to let you use XD cards in a SM slot:
http://www.xpcgear.com/bytxdsmadapt.html

09-01-2005 17:04:50

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile
i've not found anything specific that would indicate a limitation on the flash size. i think the only thing that would be a limiting factor is that after 64mb you need 4 read cycles instead of 3.


thanks for the url on the adapter. that adapter would actually be perfect. you can solder directly to the smartmedia connector and have the removable xD card. this works pretty well as the smartmedia slot is hard to come by, and is a little difficult to solder to. the current limiting factor with this whole design is that the usb->smartmedia adapters have some formating in the actual firmware which prevents me from writing at a low-level to the card. i've built a parallel port adapter so that i can access the smartmedia(or nand flash) directly. searching several mailings lists indicate that the sandisk sddr-09 smartmedia reader does allow low-level access, but currently none of the linux drivers allow this from userland. i'm still seeing that the bootloader on the rom does do some type of checking on the contents of the flash cartridge but not been able to determine as of yet what this is doing.

09-02-2005 07:41:35

New MessageRE:Cartridge Update (modified 0 times) jbfan
Profile
...i've built a parallel port adapter so that i can access the smartmedia(or nand flash) directly...

That could be useful, do you have a pointer to the schematic and software or is this totally home brew?
Found a reference to a Samsung parallel port NAND adapter apt-note but looks like it has been replaced by their NANDUSB product.

My attempt to splice the JB to a USB FLASH drive failed; even with the power pins lifted on the memory chip there was enough current getting to the controller that it was partially powering up. I could not find a data sheet for the Lexar controller (FC1610-TC).

Next step was to remove the memory chip from the USB drive and graft it to a "JuiceWare Chip" that had its OTP part liberated ("Trading Spaces" so no regrets). This appears to work; the memory test recognizes it as a 128M part, manufacturer ID "AD" (Hynix) and the checksum comes up the same every time. I was getting the wrong mfg ID and inconsistent chksums when the part was still attached to the USB drive.

Just starting to learn about NAND. It looks straightforward enough but a little more complicated than I would like. Apparently it is a bit like old hard drives that shipped with a bad block list. This page from Data-io (chip programmer company) has some useful info;
http://www.data-io.com/NAND/NANDApplicationNotes.asp
The top link "Programming NAND Flash" explains a lot about the various bad block strategies, ECC etc.

Question is does the JB do any bad block or ECC checking. I would think it needs to check for bad blocks so it can skip them on a read but ECC would probably be overkill in a product like this.

Guess only deciphering the boot ROM will tell.

-J

09-16-2005 20:06:50

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile
[quoteThat could be useful, do you have a pointer to the schematic and software or is this totally home brew?[/quote]

the hardware is based on a design i found that was originally for an amiga parallel port. i hacked up some software to work with it however i'm not happy with the results. i've moved towards using either the JB itself to program the smartmedia/xD or using a custom driver for an aluada based usb adapter.

http://alauda.sourceforge.net/wikka.php?wakka=SupportedDevices


Found a reference to a Samsung parallel port NAND adapter apt-note but looks like it has been replaced by their NANDUSB product.

i saw the reference as well but was never able to find the app-note with a schematic and docs.


My attempt to splice the JB to a USB FLASH drive failed; even with the power pins lifted on the memory chip there was enough current getting to the controller that it was partially powering up. I could not find a data sheet for the Lexar controller (FC1610-TC).

yes i ran it to this problem as well, however i didn't post about it. i finally ended up adding a jumper to hold the usb controller in reset while i was using it with the JB.


Question is does the JB do any bad block or ECC checking. I would think it needs to check for bad blocks so it can skip them on a read but ECC would probably be overkill in a product like this.

ECC, from what i understand, should only be an issue when writing to the nand device, and as the juiceware carts are OTP, it really doesn't apply. now, bad block mangement does apply as even the OTP flash has some bad blocks, so there has to be some method for the jb to know which blocks to read from. the initial code for the juiceware cart is included in block 0 from what i can tell. block 0 is supposed to the only block that manufacturers guarrante to be good when leaving the production line, so its a good assumption that looking at the data contained in block 0 will yield alot of info about the overall cart.

09-26-2005 07:29:21

New MessageRE:Cartridge Update (modified 0 times) jbfan
Profile

ECC, from what i understand, should only be an issue when writing to the nand device, and as the juiceware carts are OTP, it really doesn't apply.
Yes, dumping the OTP cart shows that the "extra" 16 bytes at the end of each block is all 0xFF (erased state). This is, I think, where ECC is usually stored.


now, bad block mangement does apply as even the OTP flash has some bad blocks
Where did you see this? Could not find anything in the Matrix data sheet or web site to confirm it, if not it may be possible that the software is assuming all blocks are good. This could be a problem for NAND with bad blocks near the beginning of memory.


the initial code for the juiceware cart is included in block 0 from what i can tell.
Have had good luck dumping the cart with jtager batch files and an expect script. Once I have rewired the WP pin (stupid mistake) I plan on trying to write one of the demo programs to it.

-J

10-02-2005 18:49:20

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

Where did you see this? Could not find anything in the Matrix data sheet or web site to confirm it, if not it may be possible that the software is assuming all blocks are good. This could be a problem for NAND with bad blocks near the beginning of memory.

http://www.edn.com/article/CA495735.html


a detailed article on the Matrix 3DM technology. its also covers some of the differences in using the Matrix chips verses the standard Nand interface. pretty good read.

10-03-2005 07:43:33

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

Have had good luck dumping the cart with jtager batch files and an expect script. Once I have rewired the WP pin (stupid mistake) I plan on trying to write one of the demo programs to it.

Any hints? I've traced out the cart, but I don't fully understand the interface yet. Data 0-7--no problem. CPU /OE to NAND /RE, CPU /WE to NAND /WE, CPU GPF6 to NAND ALE, CPU GPF5 to NAND CLE. On my carts, it appears that /CE is held low by R1 (100k), and /WP is tied to ground.

I can't seem to get my head around the fact the with the cart's /CE line tied low, it's always looking at the /WE and /RE lines. Seems like *any* bus activity (such as SDRAM write) would be seen by the cart, which would screw up the command/address/data protocol.

I was running code from the onchip sram to eliminate bus cycles, but that didn't seem to help. I *really* expected to see pin 6 on the slot (/GCS2) used for bus decoding, but it doesn't even get a trace on my carts. Maybe I should double check the diagram on the Wiki...could it be incorrect?

My ID code check is:
ALE and CLE start low
CLE high, write 0x90 to 0x04000000
CLE low
ALE high, write 0x00 to 0x04000000
ALE low
read 0x04000000 three times

Sector read:
ALE and CLE start low
CLE high, write 0x00 to 0x04000000
CLE low
ALE high, write low 8 bits of sector to 0x04000000
ALE high, write middle 8 bits of sector to 0x04000000
ALE high, write next 8 bits of sector to 0x04000000
ALE low
read from 0x04000000 528 times.

10-03-2005 23:20:56

New MessageRE:Cartridge Update (modified 0 times) jbfan
Profile

Any hints? I've traced out the cart, but I don't fully understand the interface yet. Data 0-7--no problem. CPU /OE to NAND /RE, CPU /WE to NAND /WE, CPU GPF6 to NAND ALE, CPU GPF5 to NAND CLE. On my carts, it appears that /CE is held low by R1 (100k), and /WP is tied to ground.
Yes, I think this is correct.


I can't seem to get my head around the fact the with the cart's /CE line tied low, it's always looking at the /WE and /RE lines. Seems like *any* bus activity (such as SDRAM write) would be seen by the cart, which would screw up the command/address/data protocol.
Had not thought of this, you could be right. Access to the cart may need to be structured such that the operation completes before any other bus activity happens. I think how they get away with /CE always low is that /RD /WR are ignored until a transaction is kicked off by asserting CLE.


I *really* expected to see pin 6 on the slot (/GCS2) used for bus decoding, but it doesn't even get a trace on my carts. Maybe I should double check the diagram on the Wiki...could it be incorrect?
Yes, on the cart I buzzed out pin 6 (nGCS2) is a no connect, so it apparently has nothing to do with reading from the cart. From what I can tell the cart connector pin out on the Wiki is good.


My ID code check is:...
This looks like what I am doing in jtag. If you are running this in code the writes/reads may be happening too fast. Try a wait between each step; CLE high, wait, write command, wait, etc. Watching the r/b (ready /busy) bit could help as well.


Sector read:...
Same here although I am writing 4 bytes of address not three. This was in the spec for the 128M NAND I am using, not sure if this is needed for reading the OTP (32M?) but it works for both.
The only other thing I do is reset (command 0xff) the chip as a first step.

-J

10-04-2005 04:38:14

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

Had not thought of this, you could be right. Access to the cart may need to be structured such that the operation completes before any other bus activity happens. I think how they get away with /CE always low is that /RD /WR are ignored until a transaction is kicked off by asserting CLE.

Wow, I hope we're wrong. That would really suck--no interrupts, no DMA, no LCD, no SDRAM or ROM access while the NAND interface is active. Sounds like you'd have to run the code from internal SRAM as well (meaning half or no cache, at least temporarily), otherwise the instruction fetches could interfere. (This just doesn't seem right--even the SDRAM refresh looks like it will wiggle the /WE line and cause a problem. I must be mis-understanding the interface.)


From what I can tell the cart connector pin out on the Wiki is good.

Good to know. I may beep it out today just to satisfy myself.


If you are running this in code the writes/reads may be happening too fast. Try a wait between each step; CLE high, wait, write command, wait, etc. Watching the r/b (ready /busy) bit could help as well.

Yeah, I just didn't want to deal with polling the busy bit. (I think I had a delay in there, but after latching in the address, not between command and address bytes.)


The only other thing I do is reset (command 0xff) the chip as a first step.

Oops. That sounds like a really fine plan. Wish I'd thought of it.

10-04-2005 07:00:58

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

Yes, on the cart I buzzed out pin 6 (nGCS2) is a no connect, so it apparently has nothing to do with reading from the cart. From what I can tell the cart connector pin out on the Wiki is good.

based on code i found in the juicebox rom, i suspect that the was unit developed to use several different types of nand, including several models that needed the use of the nGCS2. the OTP from matrix doesn't need this so its not used. in addition i suspect that the nGCS2 was also used for some future carts that need to do some address decoding which would need the nGCS2.(i.e. a cart with a camera interface, also see the Gameboy cartridge specs http://www.devrs.com )


Had not thought of this, you could be right. Access to the cart may need to be structured such that the operation completes before any other bus activity happens. I think how they get away with /CE always low is that /RD /WR are ignored until a transaction is kicked off by asserting CLE.

that appears to be the case, i've looked at the schematics fro several usb thumb drives, all using nand flash, have the nCE tied low.

i need to re-do the juiceware cartridge pin out as the wiki was defaced a couple weeks ago and the JuiceBoxCartridge page was lost.


their is a section of code in the bootrom that reads the vendor and product id, this is a good section to look at as far as timing cycles for reading the nand flash interface.


Same here although I am writing 4 bytes of address not three. This was in the spec for the 128M NAND I am using, not sure if this is needed for reading the OTP (32M?) but it works for both.

implementing this is the prefered way as i understand it since its backwards compatible with older nand, and the newer nand chips(anything over 64MB) do require four cycles.

10-04-2005 07:58:49

New MessageRE:Cartridge Update (modified 0 times) newell
Profile
Ok, I'm getting 0x98, 0x75, 0x00 for the Matrix cart ID code, by hand inside the debugger. The sector dumps look correct as well--512 bytes of stuff, followed by 16 bytes of 0xff. I dunno, maybe the 0xff reset command helped? Here's my debugger script if anyone else is playing along at home:

; NAND reset
word 0x01d20038 = 0x19f ; ALE and CLE low (idle mode)
word 0x01d20038 = 0x1bf ; command mode
byte 0x04000000 = 0xff ; reset command
word 0x01d20038 = 0x19f ; idle mode

; NAND ID code
word 0x01d20038 = 0x1bf ; command mode
byte 0x04000000 = 0x90 ; read ID command
word 0x01d20038 = 0x19f ; idle mode
word 0x01d20038 = 0x1df ; address mode
byte 0x04000000 = 0x00 ; address 0 for ID code?
word 0x01d20038 = 0x19f ; idle mode
byte 0x04000000 3 ; read three bytes of ID (middle should by 0x7something)

; NAND read sector
word 0x01d20038 = 0x19f ; idle mode
word 0x01d20038 = 0x1bf ; command mode
byte 0x04000000 = 0x00 ; read 1 command
word 0x01d20038 = 0x19f ; idle
word 0x01d20038 = 0x1df ; address mode
byte 0x04000000 = 0x00 ; start at sector 0
byte 0x04000000 = 0x00 ;
byte 0x04000000 = 0x00 ;
word 0x01d20038 = 0x19f ; idle mode

; start dumping sectors
byte 0x04000000 528 ; read one sector

10-04-2005 18:15:42

New MessageRE:Cartridge Update (modified 0 times) newell
Profile
Sequential reads from code working (dumb typo--I had ALE and CLE shifted down by one bit!). Random sector reads appear to be dropping one byte every time I switch sectors. Odd. I've checked two 32MB cards (Liz Phair and Drake Bell)--neither has any sectors marked bad in the 16 byte ECC area. I agree--it looks like the first few sectors are code, and that there's no filesystem in that area at least. I'll try and clean the test code up enough to post tomorrow night. Should have my xD cards and slots in later this week!
10-04-2005 23:33:22

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

I'll try and clean the test code up enough to post tomorrow night.


that would be great! would make doing the last bit of work on an externally bootable xd/smartmedia card alot easier.

10-05-2005 11:21:00

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

that would be great! would make doing the last bit of work on an externally bootable xd/smartmedia card alot easier.

What would help? Straight sector by sector dump? With or without the 16 spare/ECC bytes? Or maybe a sector by sector display of the spare bytes for each sector?

10-05-2005 12:04:20

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

What would help? Straight sector by sector dump? With or without the 16 spare/ECC bytes? Or maybe a sector by sector display of the spare bytes for each sector?

straight sector by sector dump with the 16 byte space ( refered to as the "Out Of Band" area or OOB). this would allow me to match up some of the operations being done from inside the bootrom code.

10-05-2005 12:07:25

New MessageRE:Cartridge Update (modified 0 times) newell
Profile
Done. Any ideas on which checksum algo they're using? I tried a 32 bit wide 2's complement sum of the ROM and got 0. Think I'll try the same on a few carts and see what I get.
10-05-2005 19:48:24

New MessageRE:Cartridge Update (modified 0 times) newell
Profile
Is anyone else seeing two copies from cart to sdram? (I'm breaking on the 'copy multiple sector' sub at 0x5644.) I see sector 0 to 0x0c000100, and either 0x7a or 0x79 (cart dependent) sectors copied to 0x0C180000. I *think* that the bootloader first copies sector 0, then checks location 0x0c00019c (index 0x9c at the cart). This location seems to contain the length of the cart code. Also check out location 0x0c000188 (index 0x88 at the cart)--that's the destination of the second copy.

The bootloader then rounds the length up to the number of sectors and makes the copy to the destination.

Trading spaces claims code length of 0xf0a8 and copies 0x79 sectors.
Liz phair has 0xf3a4 at that location...and it requests 0x7A sectors to be copied.

I still suspect some kind of checksum test on the copied cart code before the bootloader will run it...anyone?

10-05-2005 22:32:12

New MessageRE:Cartridge Update (modified 0 times) newell
Profile
Nevermind. I don't think there's a check after copying code...I flipped some bits after the copy, and it still ran the cart app (and the dirty bits are still there). If it was checking the copied app's integrity, it should have caught my 0xdeadbeef intrusion.

BTW, the sector copy is a neat little piece of code: load multiple registers (8) from 0x04000000, store multiple registers to sdram destination. 32 bytes at a whack. I'm pretty sure that the 16 OOB bytes are just being dropped on the floor.

10-05-2005 23:15:39

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

Is anyone else seeing two copies from cart to sdram? (I'm breaking on the 'copy multiple sector' sub at 0x5644.) I see sector 0 to 0x0c000100, and either 0x7a or 0x79 (cart dependent) sectors copied to 0x0C180000. I *think* that the bootloader first copies sector 0, then checks location 0x0c00019c (index 0x9c at the cart). This location seems to contain the length of the cart code. Also check out location 0x0c000188 (index 0x88 at the cart)--that's the destination of the second copy.

The bootloader then rounds the length up to the number of sectors and makes the copy to the destination.


yea i noticed that the sector 0 was getting copied at the begining, but hadn't had time to dig really deep into it. what you say makes sense of the data i collected. your nand test app looks great, i won't have time to test until saturday. hopefully this is the last bit of info we need.

10-06-2005 07:26:23

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

hopefully this is the last bit of info we need.

So, does this mean I need to start working on NAND erase and program code? Maybe erase the first physical block (32 sectors), blank check, then program 16k from SDRAM? If I read the docs correctly, that will probably destroy the low-level formatting and logical->physical translation info on the SM or xD card.

10-06-2005 08:58:08

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

So, does this mean I need to start working on NAND erase and program code? Maybe erase the first physical block (32 sectors), blank check, then program 16k from SDRAM? If I read the docs correctly, that will probably destroy the low-level formatting and logical->physical translation info on the SM or xD card.

erase and program functionality would be helpful functions. it will destroy the xD/SM low-level formating information which isn't realyl useful to us anyway, but does make the card unreadable in most usb->xD/SM readers.

http://www.surpluscomputers.com/store/main.aspx?p=ItemDetail&item=DRV10768

this reader/writer provides full access to the xD/SM card so it can do the lowlevel access for programming the card to work with the JuiceBox. i've got a couple of these and i am currently modifying the linux kernel driver in preparation for programming the cards

http://alauda.sourceforge.net/

my intention was to use the usb->xD/SM device to program the cards, however, having a secondary method to program the cards is always good.

10-06-2005 10:20:57

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

this reader/writer provides full access to the xD/SM card so it can do the lowlevel access for programming the card to work with the JuiceBox.

Mine arrived this evening. I just checked, and under winblows, I can easily access xD at the logical sector level (below the filesystem), but not at the physical sector level. Oh well...


i've got a couple of these and i am currently modifying the linux kernel driver in preparation for programming the cards

I'll have to build up a minimal Linux machine (not sure I want to do the multiboot on my main box) to play along...any advice on a kernel version, distribution, etc.? If you're going to be doing driver work, I'd like to be able to use it without a lot of hassle.


my intention was to use the usb->xD/SM device to program the cards, however, having a secondary method to program the cards is always good.

Yep. I picked up a couple of xD cards and a couple of the SM->PCMCIA adapters (for stripping parts) along with my DPC-R1. That SM socket is rather large; large enough it's going to be an ugly bag on the side. Still waiting on my xD to SM adapter to arrive, so I can't actually test the NAND erase/write stuff just yet. I did scab a SD/MMC slot onto a cart, and the cart still plays...now I got to wonder if it would be quicker to read cart chunks into sdram, then copy them to MMC, rather than doing the serial port dump...

10-06-2005 21:45:29

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

Mine arrived this evening. I just checked, and under winblows, I can easily access xD at the logical sector level (below the filesystem), but not at the physical sector level. Oh well...

yea its my understanding that the windows driver does the logical sector translation, so using winblows is probably out of the question.


I'll have to build up a minimal Linux machine (not sure I want to do the multiboot on my main box) to play along...any advice on a kernel version, distribution, etc.? If you're going to be doing driver work, I'd like to be able to use it without a lot of hassle.

the original alauda driver is based on a 2.6 kernel, however, i'm tinkering around with a 2.4 kernel. my goal is to make it pretty easy to use. might be able to use it with a bootable cd like knoppix.


Yep. I picked up a couple of xD cards and a couple of the SM->PCMCIA adapters (for stripping parts) along with my DPC-R1. That SM socket is rather large; large enough it's going to be an ugly bag on the side. Still waiting on my xD to SM adapter to arrive, so I can't actually test the NAND erase/write stuff just yet. I did scab a SD/MMC slot onto a cart, and the cart still plays...now I got to wonder if it would be quicker to read cart chunks into sdram, then copy them to MMC, rather than doing the serial port dump...

my final design will use a xD not SM, so the socket size shouldn't be a problem. i ordered some of those SM->PCMCIA adapters too, but not received them yet. how usuable are the SM sockets from them? the SD/MMC won't work like that because the SPI lines are multiplexed with other functions. the only way to get sd/mmc at the same time as the nand flash is to bitbang the spi interface using the non-used gpio's. i've already tested this functionality.

10-07-2005 09:00:41

New MessageRE:Cartridge Update (modified 0 times) adeptwiz
Profile
Has anyone figured out how the juicebox CPU really boots?

From what I can tell the memory at 0x00 is read/write.
The Samsung spec. sheet seems silent on this matter?!

Somehow code gets stored into 0x00 and up. Presumably this code comes from the onboard flash memory. Perhaps this memory is located at 0x00 and there is some sort of cache which makes it look like R/W memory?

Maybe this is NOR flash?

Perhaps this "ROM" is write-once? In any case it must be programmed at the time of manufacture. The PCB has probe points for JTAG and one of the serial ports, so perhaps this is how this is done. If we assume that it is R/W flash, we could replace normal juicebox code with our own.

Does anyone have any thoughts?

wiz

FWIW - I have been using JTAGER to read/write and examine juicebox ( with a wiggler interface ).

10-07-2005 09:04:12

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

Has anyone figured out how the juicebox CPU really boots?

uh its completely documented in the datasheet from samsung



From what I can tell the memory at 0x00 is read/write.
The Samsung spec. sheet seems silent on this matter?!

if you look at the memory map provided in the data sheet you will see that the processor with boot from whatever is attached at the 0x00 address. this could be any number of devices. the samsung spec is vague on the matter because you can hook up different things including OTP roms.


Somehow code gets stored into 0x00 and up. Presumably this code comes from the onboard flash memory. Perhaps this memory is located at 0x00 and there is some sort of cache which makes it look like R/W memory?

the OTP is connected to nGCS0 which corresponds to the 0x00 bank. the code does come from the OTP rom.


Maybe this is NOR flash?

the OTP rom does have a NOR flash interface and is CFI(Common Flash Interface) compliant



Perhaps this "ROM" is write-once? In any case it must be programmed at the time of manufacture. The PCB has probe points for JTAG and one of the serial ports, so perhaps this is how this is done. If we assume that it is R/W flash, we could replace normal juicebox code with our own.

uhh yes its write-one (OTP=One Time Programmable). yes its done at the time of manufacturer and its done via JTAG as programming memory in circuit is one of the primary purposes of JTAG. the OTP rom isn't writeable after the first write, so replacing the code is not an option.

10-07-2005 09:57:02

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

uhh yes its write-one (OTP=One Time Programmable). yes its done at the time of manufacturer and its done via JTAG as programming memory in circuit is one of the primary purposes of JTAG. the OTP rom isn't writeable after the first write, so replacing the code is not an option.

I couldn't find programming info on the device used on my JB, but an older OTP ROM ('6402d) datasheet did include some programming info. That was enough to get me all excited about the possibility of overburning some of the ROM to modify the boot code. But then I noticed that the ROM requires 9.75V on one pin to put it in programming mode (and Vcc of 4V, instead of 3-3.3V), which seems to rule out in-circuit programming in this application.

I don't know--maybe the '6402G doesn't require the HV to enter programming mode, which would at least make it physically feasible. Not a lot of 0xff sections in the ROM left to play with, though...

10-07-2005 10:18:54

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

I don't know--maybe the '6402G doesn't require the HV to enter programming mode, which would at least make it physically feasible. Not a lot of 0xff sections in the ROM left to play with, though...


the 6402g datasheet is on the wiki. but based on my reading it is pre-programmed and not done in circuit. however the pads match for a wide range of OTP and flash devices, which means that the designers needed to have the jtag available for doing in circuit programming. the COB does appear to be programmer in circuit as the chip itself isn't complete untill it is epoxied to the board. if you don't want to use the onboard OTP, the easiest method of add a different boot flash chip is to simply cut the nGCS0 line to the chip and then add your own. i've already done this with on test unit. its a real pain soldering all those wires, but its doable.

10-07-2005 10:29:10

New MessageRE:Cartridge Update (modified 0 times) adeptwiz
Profile
It turns out the answer is obvious.

The CPU boots from the resident ROM (PROM/FLASH) chip and this is where the boot code is located.

Apparently my ability to Read and Write to it is an artifact of either jtager or the chip itself?

So, with jtager it should be relatively easy to write little programs, download them into RAM and execute them. Probably not as easy as with OCD Commander, but their support personnel say that OCD Commander is no-longer a supported product and so they won't be changing it to include wiggler support in the Linux version.

I asked whether they would consider making the sources available. I have yet to receive an answer.

Happy hacking.

wiz

10-07-2005 11:33:52

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

So, with jtager it should be relatively easy to write little programs, download them into RAM and execute them. Probably not as easy as with OCD Commander, but their support personnel say that OCD Commander is no-longer a supported product and so they won't be changing it to include wiggler support in the Linux version.

you can use jtager,jtag-tools or armtool(and probably several others) to upload test code:

http://www.elinux.org/wiki/JuiceBoxCodeTest

10-07-2005 11:37:30

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

you can use jtager,jtag-tools or armtool(and probably several others) to upload test code:

Hey, do any of these tools support the EmbeddedICE Macrocell watchpoints? (OCD Commander supports a single hardware instruction fetch breakpoint.) It'd be *really* nice to be able to break on memory location access as well. It looks like the ARM7TDMI EmbeddedICE watchpont hardware is pretty versatile, so it's just a matter of the tools supporting it.

10-07-2005 13:36:27

New MessageRE:Cartridge Update (modified 0 times) jbfan
Profile

Hey, do any of these tools support the EmbeddedICE Macrocell watchpoints?

Jtager gives you read write access to the ice registers. Not sure if this is what you are asking for. I have no idea how to use them, any pointers to ice documentation?

-J

10-07-2005 14:26:50

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

I have no idea how to use them, any pointers to ice documentation?

Yeah, Appendix B ("Debug in Depth") of the arm7tdmi core technical reference manual is pretty good:
http://www.arm.com/pdfs/DDI0210C_7tdmi_r4p1_trm.pdf

10-07-2005 14:39:37

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

Probably not as easy as with OCD Commander, but their support personnel say that OCD Commander is no-longer a supported product and so they won't be changing it to include wiggler support in the Linux version.

I asked whether they would consider making the sources available. I have yet to receive an answer.


I'll bet that at least some of the CPUs have debug protocols protected by NDA, so they may not be able to release source.

10-07-2005 18:21:26

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

my final design will use a xD not SM, so the socket size shouldn't be a problem.

Are you planning on spinning a PWB?


i ordered some of those SM->PCMCIA adapters too, but not received them yet. how usuable are the SM sockets from them?

Piece of cake getting the socket from the board, but it's still as wide as the PCMCIA card. Looks like it may have an ejector, which would explain some of the size.


the SD/MMC won't work like that because the SPI lines are multiplexed with other functions. the only way to get sd/mmc at the same time as the nand flash is to bitbang the spi interface using the non-used gpio's. i've already tested this functionality.

Now I'm confused again. I've got a cart with both Matrix ROM and a scabbed on SD slot. If I run the BIST with an MMC in the slot, the MMC is detected and identified correctly. BIST also finds the cart ROM and checksums it as ok. If I boot normally with the MMC containing MP3 files, the unit goes into the MP3 player and plays the music. If I boot normally with no MP3 files on the MMC, it runs the cart video. If I boot normally with no MMC in the slot, it runs the cart video.

I've not tried to write to the MMC, and I don't have any NAND flash connected yet. Maybe then I'll get a conflict? (Interleaved access to NAND and MMC are out, of course. I'm hopeful that the MMC could be accessed after the NAND is reset and placed in idle mode, because the SPI won't generate the /WE signal to the NAND. Take GPC11 high to de-select the MMC, and NAND access should be ok. I think. There might be a hitch if the MMC switches from SPI to MMC mode accidentally, but my MMC book implies that you can't go back after entering SPI mode.)

I do understand what you're getting at with the multiplexed lines. I'm still confused as to how the NAND interface works without that decoded chip select, and how it avoids conflicting with ROM reads, SDRAM writes, and the SDRAM refresh cycle (all of which should wiggle either the /OE or /WE line). It's an odd situation--things are working, and I don't understand how!

BTW, I've been able to access the ICE registers through OCD Commander...it's nifty being able to do stunts like break whenever 0x19A53027 is read to or written from memory. (Made it easy to find the BIST checksum functions.)

10-07-2005 23:32:47

New MessageRE:Cartridge Update (modified 0 times) adeptwiz
Profile
That ARM reference is MOST helpful.

Thanks.

The next goal for me is to actually write->compile/assemble->download->run some program.

As you point out all the tools appear to be there. Now just gotta get them working

Your two programs are most helpful. Again thanks.

On a related matter, the CPU should be fast enough to send 10base2 ethernet packets? Has anyone tried this? When one tries this with a PC, the i/o has been crippled to only update i/o at a 1 microsecond rate?!! This cannot be 'just' an accident :).

I suspect on the simpler micros this may not be the case, leading to the possiblity of a software ethernet interface. This is much easier if the 10baseT keep alive signal is disabled/disregarded. With 10base2 it is strictly a half-duplex shared media, so processor interactions should be pretty straightforward. The receive side interrupt response only needs to be fast enough to get into the 1-0-1-0 preamble before it ends. Just SMOP... (Small Matter of Programming! (old consultants joke)) :)

Happy hacking,
wiz

10-08-2005 03:04:25

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

the SD/MMC won't work like that because the SPI lines are multiplexed with other functions. the only way to get sd/mmc at the same time as the nand flash is to bitbang the spi interface using the non-used gpio's. i've already tested this functionality.

I've been able to copy and readback verify the 8MB boot ROM to an MMC/SD card, with a JB cart present in the slot. I'm using the same SPI lines that the stock MP3 kit uses. The code is still bit-banging the SPI instead of using the hardware SPI unit, but that's on my todo list. Filesystem is NFS: no file system. No problem reading the cards under winblows using the Cygwin 'dd' utility. (Explorer does complain about a missing filesystem and offers to format the card.) The outfile file from 'dd' is identical to the serial port ROM dump, as expected.

Once the code has been cleaned up (probably not tonight!), some sort of MMC/SD card demo will be uploaded to the Wiki. Any suggestions?

10-08-2005 23:42:11

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

Are you planning on spinning a PWB?

maybe later down the road, but for now, i'm working towards a howto using off the shelf parts.


Now I'm confused again. I've got a cart with both Matrix ROM and a scabbed on SD slot. If I run the BIST with an MMC in the slot, the MMC is detected and identified correctly. BIST also finds the cart ROM and checksums it as ok. If I boot normally with the MMC containing MP3 files, the unit goes into the MP3 player and plays the music. If I boot normally with no MP3 files on the MMC, it runs the cart video. If I boot normally with no MMC in the slot, it runs the cart video.

thats because as part of the boot process it determines how to configure those lines based on the tests it does.


I've been able to copy and readback verify the 8MB boot ROM to an MMC/SD card, with a JB cart present in the slot. I'm using the same SPI lines that the stock MP3 kit uses. The code is still bit-banging the SPI instead of using the hardware SPI unit, but that's on my todo list.

add i should have been a little more exact when i made my statement, you can't use the SPI controller and the nand flash at the same time. you can bitbang using the same lines to create a soft SPI.


Once the code has been cleaned up (probably not tonight!), some sort of MMC/SD card demo will be uploaded to the Wiki. Any suggestions?

sounds great! look forward to testing. glad to see someone else doing some low level work!

10-09-2005 12:11:53

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile
adeptwiz wrote:


On a related matter, the CPU should be fast enough to send 10base2 ethernet packets? Has anyone tried this?

why 10base2? why not just use a packet wacker board from sparkfun?

http://www.sparkfun.com/shop/index.php?match_criteria=all&rec=&keywords=Ethernet+8-bit+Interface+Board&

would be very easy to hook up to the jb.

10-09-2005 12:18:10

New MessageRE:Cartridge Update (modified 0 times) adeptwiz
Profile
mmc_1.c most helpful :)

Juicebox serial port is up and running :)

I can now compile, upload and run mmc_1.c :)

Now just gotta get UART input up and running.

Happy hacking,
wiz

10-10-2005 08:02:51

New MessageRE:Cartridge Update (modified 0 times) adeptwiz
Profile
Getting the serial input port up turns out to be pretty easy.

Receive status bit is 0x01 in the status port.

Port E bit 2 has to be turned on for use as uart0 rx.

So in UART.C

PCONE&=!0x0C;
PCONE|=0x08;

becomes

PCONE&=!0x3c;
PCONE|=0x28;

Characters now come in and out :)

Now just gotta do something real with the serial port :)

Happy hacking,
wiz

10-10-2005 11:02:04

New MessagePacket hacking board (modified 0 times) adeptwiz
Profile
Hi,

I am sure packet hacking PCB would work.

But:

1. It costs $$$.

2. Takes lots of pins and wires to hook it up.

10 base 2 is just one wire to receive from and send to.

regards,
wiz

10-10-2005 11:04:53

New MessageRE:Cartridge Update (modified 0 times) codeman
Profile | Email
if you want to do 10baseT look at http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en022889
single chip ethernet controller with a SPI interface ..

codeman

10-10-2005 12:06:24

New MessageRE:Cartridge Update (modified 0 times) greghol
Profile

1. It costs $$$.

2. Takes lots of pins and wires to hook it up.

10 base 2 is just one wire to receive from and send to.


How is 10Base2 any easier than 10BaseT? The first one has a 50 ohm coax interface (2 signals) and the other 100 ohm (4 wire isolated interface). Not much of a difference between the two based on the signal count but big difference on the physical interface and method. Both require a 10 Mbps MAC (Media Acess Controller) interface chip that provides connection to your CPU. (parallel, serial - i.e. SPI) etc. You can not bit-bang the 10Base2 interface.

Greg

10-10-2005 14:25:38

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

Is anyone else seeing two copies from cart to sdram? (I'm breaking on the 'copy multiple sector' sub at 0x5644.) I see sector 0 to 0x0c000100, and either 0x7a or 0x79 (cart dependent) sectors copied to 0x0C180000. I *think* that the bootloader first copies sector 0, then checks location 0x0c00019c (index 0x9c at the cart). This location seems to contain the length of the cart code. Also check out location 0x0c000188 (index 0x88 at the cart)--that's the destination of the second copy.

hmm, it actually appears that the copy is done _three_ times, first at 0x595A7C of the bootrom code which copies sector 0 from the nand flash to 0xC1E48B8, the second copy to 0xC000100, and third to 0xC180000. 0x1D28 seems to be the common BL (jump) for the second and third copy. the first copy of sector 0 does include the OOB area, however later copies don't appear to do so.

10-10-2005 14:57:54

New MessageEthernet - 10base2 (modified 0 times) adeptwiz
Profile
Hi Greg,

The simple answer is that yes, 10base2 is LOTS easier from the processor point of view. But 10baseT isn't too bad either.

Why?

Like RF, 10base2, and 10base5 for that matter are a single coax cable. Because of this there is no possiblity of sending data in both directions at once. From the CPU's point of view it is either sending OR receiving, but not both. So the cpu doesn't need to try to do 2 things an once. It can turn off interrupts and devote it's full attention to the incoming or outgoing packet.

This is not the case with 10baseT which has 4 wires and can under certain circumstances be sending in both directions at once. Another problem is that 10baseT ordinarily runs with a "keep alive" signal when the line is otherwise "idle". This would mean that the CPU would have to sending these pulses "all" the time.

You suggest that both 'require' a Media interface chip. While this is "always" done, it is really optional. If your look around you will see examples of 10baseT and 10base2 interfaces being done without special chips and without transformers. Eliminating both actually makes the CPU interface cheaper and easier!

In fact it is most tempting to eliminate both of them and then note that the product must be close to a "hub" of some type. Since hubs are very cheap ($5-10) this is not really a problem! Let someone else buy those parts and sell them to you as a "hub" or whatever.

And to come straight to your "question". Yes, you most certainly CAN bit bang 10base2 or 10baseT packets. You have just got to be careful about program timing. You CAN also receive VIA the same method.

That is what I was asking. I have looked at this many times and done it at lower data rates and it works VERY well since you can easily control ALL the details with the CPU code rather than have chip problems that you can't fix easily.

Recent CPUs have gotten fast enough that it ought to be pretty easy to do the whole ethernet interface in software, as 10base2,10baseT have pretty simple bit patterns.

Driving the output line can be done with a 74hc04 or similar chip. Receiving means pre-biasing a gate as a line receiver. I have found it desirable to have some sort of chip between the CPU and the line. That way electrical surges on the line don't burn out parts of the CPU :)

Hope the above helps :)

Happy hacking,
wiz

10-11-2005 07:14:11

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile
newell,



"I've been able to copy and readback verify the 8MB boot ROM to an MMC/SD card, with a JB cart present in the slot. I'm using the same SPI lines that the stock MP3 kit uses. The code is still bit-banging the SPI instead of using the hardware SPI unit, but that's on my todo list."

and i should have been a little more exact when i made my statement, you can't use the SPI controller and the nand flash at the same time. you can bitbang using the same lines to create a soft SPI.



i've done some testing with the sd/mmc interface, it looks like we can move the SIOTxD(pin 12) to the nGSC2(pin 4) and set it as a GPIO rather than the chip select function. in addition we can move SIORxD(pin 18) to GPC2(pin2). this should give us clear access to the sd/mmc via a soft spi interface. this modification is pretty easy to do.

10-11-2005 12:58:08

New MessageRE:Cartridge Update (modified 0 times) greghol
Profile
Adeptwiz,

Might want to pickup a book on Ethernet or in the dryer form, IEEE 802.3x spec, and read about the interface. I see some missconceptions in your response. You can send data on 10BaseT both ways at the same time. Its called Full Duplex; disable collisions state machines. How are you going to handle collisions in Half Duples? You DO NOT need any CPU cycles to generate the keep-alive (i.e. link beat). That is the job of the physical layer (PHY) of the interface and its all in hardware. The transformer is used for impedance matching and for network isolation. It is needed for the real world. The media interface chip is not optional if you want to talk to other Ethernet compliant interface and you will have a hard time living in the LAN world. I have worked with Ethernet for 16 years and have done alot of or have been involved with checking out new MAC/PHYs/software on products.

On that note:

Tinkering with a slow Ethernet interface is nice and all with software timing but I dont see your point in its use other than academic reasons. Sure you can generate a packet with software but good luck on connecting it to the real world.

Greg

10-11-2005 21:20:21

New MessageRE:Cartridge Update (modified 0 times) adeptwiz
Profile
Hi Greg,

I see we have the makings of a friendly wager :)

You have won the first round....

I managed to reprogram PORTE bit 0 as an output yesterday. Then I wrote added a short segment to the mmc_1 program to alternately write 1s and 0s to that bit. All this in response to keystrokes.

I used objdump to disassemble the compiled code and found that my "fast" code had been compiled into 5 instructions for each 1-0-1 cycle. While I am by no means an expert in ARM programming, I suspect that the code could not be made significantly faster. If you have any suggestions about faster code that would accomplish the same function, PLEASE let me know.

I connected a digital oscilloscope to that CPU pin.

I observe that the CPU can put out a 3MHZ square wave. I further observe that there are what look like one cycle pauses in the wave. Perhaps these are due to dynamic RAM refresh, but I think not since the program should be running from CPU cache? Also, the first time the program is executed it runs much slower, suggesting that the CPU cache is being loaded during that first cycle.

So we have a "66MHZ" CPU that appears to run at 6 MHZ!

It's probably getting time to call Samsung technical support and ask some questions.

I will eventually try this same test with WRT54GS which has a 200MHZ MIPS processor and see if it's "real" speed is any faster.

It looks like Xilinx (The FPGA people) may have another customer. FWIW - Someone has been working on FPGA ARM code. Now that could get FAST :) And run linux :)

Thanks for your comments. Further comments appreciated.

Happy hacking,
wiz

10-12-2005 06:48:02

New MessageRE:Cartridge Update (modified 0 times) adeptwiz
Profile
Hi Greg,

Well you win round two too! (I hope you appreciate my attempt at humor).

I just compiled a similar program for WRT54GS which claims to have a 200MHZ MIPS Broadcom processor.

Results are WORSE?! It turns out that you can wiggle the LED at GPIO port 7.

So I wrote the same sort of program for MIPS and added it to the MMC driver.

When I "insmod mmc1.o" the driver, the segment executes. Objdump shows that the 1-0-1 cycle consists of 8 instructions.

The oscilloscope shows that same sort of thing as for the ARM processor but at a rate only a little in excess of 2MHZ.

So, the 200MHZ processor doesn't deliver to the I/O?

Most amazing to me. I wouldn't have guessed its I/O to be so slow.

Glad I measured it.

So I guess, Xilinx here we come! Harder to slow down FPGAs (I hope).

Happy hacking,
wiz

10-12-2005 09:07:10

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile
newell,

i took a sd/mmc adapter cart and epoxied a xd on the back of the pcb. then soldered to connections to the pcb, works great, even fits back in the original cart case. the pin outs appear to be correct, only item different is you need to connect nCE to ground as well. i had to make two mods to the cart though, i had to cut the traces for pin 12 and pin 18 and reconnect them to pins 2 and 4 respectively. second is i had to cut the trace to one of the resistors on the front side, the sd/mmc card has pin 22 pulled down and pin 20 pulled up, the flash cart needs both pin 22 and pin 20 pulled up. the pads on the xD card are pretty close together, if you gonna do this us a small knife to gouge out a little between each pad. the pads are pretty easy to, just have to watch out for solder bridges to the neighboring pad. i used 30ga wire to do the connections. the ground connection is pretty close to the case, so soldering to it would make the case not close, so i scrapped off some pcb cover for the ground area and soldered it.


prpplague

10-12-2005 10:22:45

New MessageRE:Cartridge Update (modified 0 times) adeptwiz
Profile
Hi,

My results reported for WRT54GS - Broadcom - MIPS are not correct :(

With a closer review of my program, it occured to me that my timings might have been due to cache misses.

This proves to be the case. The lessons are:

1. When a subroutine is called just once it is optimized out and place in line making sure there will be cache misses!

2. Now I call the wiggle routine from two different routines and

3. Call it multiple times in succession.

The first pass results are as stated.

The second and third passes are MUCH faster.

I measure 0.120us per 1-0-1 cycle. If we assume 200mhz CPU this is 24 cycles. There are 8 instructions in the 'cycle'. So it appears that each instruction takes 3 clocks to execute?

In any case we now appear to have a clear shot at generating a 10MB/S signal with CPU code on the front panel LED!

So generating 10BASE2 and 10BASET packets now appears within reach at least with a WRT54GS.

The only remaining question in my mind is whether Juicebox and can be coerced to make packets somehow?

Happy hacking,
wiz

10-13-2005 08:13:24

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

i took a sd/mmc adapter cart and epoxied a xd on the back of the pcb. then soldered to connections to the pcb, works great, even fits back in the original cart case. the pin outs appear to be correct, only item different is you need to connect nCE to ground as well.

Well, I'm almost caught up on the hardware side. I now have my smartmedia socket wired to a JB cart. I used a ROM cart, not a MP3 kit, so I didn't have to fiddle with the pullup resistors. Got /CE tied low at the socket. Lifted R1, which is a 100k pulldown for the cart rom /CE. Wasn't good enough--I could still detect and read the cart. Maybe the Matrix ROM has a weak pulldown itself? Once I brought /CE high (pin 6 on the TSOP), the cart was out of the way. I'll fix that better tomorrow. The rest of the wiring, while slightly tedious, was straightforward enough.

I'm seeing an ID code 0x98 (Toshiba?), size code 0x75 (32MB), 0xA5 (unique NAND serial present), and 0xBA (?) from the xD card. That's encouraging. I've also copied a pile of personal text files over to the FAT formatted xD card. The idea was to dump the xD sector by sector from the JB and be sure I can verify the contents. Looks good! I was also able to view the xD CIS (see http://www.digit-life.com/articles/smcrestore/ for some details).

I'm on hold until I can get a solid backup of the xD card. I'd also like to scan it and see if there are any bad sectors on a factory fresh card. Then I'll feel comfortable about doing an erase and burn. (My MMC cards are acting up right now...I may have weak batteries.)

BTW, will the NAND autoerase before programming, like an MMC, or do you have to explicitly erase it?

I'll try and put some pinouts up on the Wiki later tonight or tomorrow.

10-13-2005 22:16:53

New MessageRE:Cartridge Update (modified 0 times) jbfan
Profile

BTW, will the NAND autoerase before programming, like an MMC, or do you have to explicitly erase it?
Yes, erase before programming. Don't forget to read bit 0 of the status register (1 = error (bad block), 0 = no error) after a block erase or page program.

I have been able to erase and write to the NAND from jtag, by hand, but so far no luck automating the process. Jtag is rather slow anyway, reading at about 1 minute per block is the best my script can do. Writing will be even slower. Will nand_2.c have erase/write functionality?

On the subject of NAND; anyone else notice if you jump directly to Linux, with anything other than an MMC in the cart, the serial output shows the boot process trying to mount three devices;
/dev/sd
/dev/nand0
/dev/rom1

Anyone know enough about embedded Linux to say if this is just standard boot code or specific to the JuiceBox?

-J

10-14-2005 15:40:26

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

Will nand_2.c have erase/write functionality?

If you want, I guess.


On the subject of NAND; anyone else notice if you jump directly to Linux, with anything other than an MMC in the cart, the serial output shows the boot process trying to mount three devices;
/dev/sd
/dev/nand0
/dev/rom1

Nope. Is this with an MMC inserted, but no MP3/pics, or no MMC at all? What address are you jumping to?

10-14-2005 16:55:51

New MessageRE:Cartridge Update (modified 0 times) jbfan
Profile

Is this with an MMC inserted, but no MP3/pics, or no MMC at all? What address are you jumping to?
Non MMC cart (OTP, NAND, etc.), MP3 cart w/o MMC card, or no cart. Address 0x005D0000.

Here is the text segment;
[14]determine_play_mode:
MMC_CMD0 response timeout
MMC_CMD0 response timeout
mount /dev/sd: No such device
mount /dev/nand0: No such device
arena open of 1 failed!
mount /dev/rom1: No such device

If this isn't just normal fall back for when the primary device (MMC) fails it may indicate that three more cartridge types are supported by the Linux image.

-J

10-14-2005 18:08:39

New MessageRE:Cartridge Update (modified 0 times) jbfan
Profile
Not sure if it means anything - get the same Linux behavior with the first block of a NAND flash programmed with the beginning of a FAT file system (copied from a floppy).
This is without jtag, just power the unit up.
There is also a message displayed on the LCD "no cards found".

Also picked up 2 readers and some of the 32M xD cards from Supluscomputers (thanks for the link prpplague). The xD cards report ID and status correctly but for some reason I'm reading all 0xFF for data. Being Window-less have not tried the readers.

-J

10-16-2005 20:18:57

New MessageRE:Cartridge Update (modified 0 times) newell
Profile

The xD cards report ID and status correctly but for some reason I'm reading all 0xFF for data.

Something isn't right--you should at least be able to read the CIS data. Did the ID command reply with 0x98, 0x75, 0xA5?

10-17-2005 06:54:25

New MessageRE:Cartridge Update (modified 0 times) jbfan
Profile

Did the ID command reply with 0x98, 0x75, 0xA5?
Have only been reading the first two bytes and they are 0x98 0x75. The status is 0xC0 which should translate to ready and not write protect. Erase seems to work; no error in the status reg. Writing does return an error on just about all pages. I'm using the same procedure that works on the 128M flash chip and 32M OTP (read) but maybe this chip is not happy with the extra address cycle.

Can not find a data sheet specifically for the xD card but assume it just uses the 32M Toshiba NAND chip. Will have to check the addressing and compare timing diagrams between it and the Hynix part.

-J

10-17-2005 08:44:41

New MessageRE:Cartridge Update (modified 0 times) raspness
Profile
Someone was looking for a PC parallel port interface to NAND flash - there is a free design together with userland linux code at http://TheAudioBible.org

I need raw access to a NAND flash chip via USB - did anyone find a way to do this, e.g. via the sandisk sddr-09 smartmedia reader?
Thanks

11-16-2005 06:14:46

New MessageRE:Cartridge Update (modified 0 times) prpplague
Profile

I need raw access to a NAND flash chip via USB - did anyone find a way to do this, e.g. via the sandisk sddr-09 smartmedia reader?

check out the very bottom of this page:

http://www.elinux.org/wiki/JuiceBoxUMDCart


i've been totally swampped at work for the last few weeks, and probably will be for 3 or 4 more, so i've not had time to post any code.

11-16-2005 08:28:37

Reply to Thread | Printer |
All times are PSTPowered by UltraBoard v1.62



Copyright © 2000, Netmake Inc. All Rights Reserved.
See Terms and Conditions for more information.




i-opener opener laptop notebook computer help drivers dll free windows dos repair fix linux mac macintosh 2000 95 98 nt pc configure hardware software sound video netscape explorer network networking lan wan software cmos fat bios printer card mouse modem ide scsi cd rom controllers scanner tape hard drive cgi scripts source code mp3