I-Appliance BBS The Official Source for Internet Appliance Upgrades and Mods Click Here! BBS Main List | Sign In | Sign Up | Search | Help | Linux-Hacker.net Reply to Thread | Printer |

Home / MISC Areas / Mattel JuiceBox What next?

What next? (modified 0 times) newell Profile I now have an MMC socket (didn't have any SD slots on hand), JTAG, and UART I/O wired in to my 8MB juicebox. I can compile code, download it to sdram, and run it through the debugger (OCD Commander). By peeking around the CPU registers I think I've found the display backlight (timer 1 PWM), the display contrast (timer 2 PWM), the front panel buttons (port G), and the volume control (analog input 1). Now that it's running my code, it's pretty easy to dump the ROM and SDRAM out the serial port. Fun stuff! I've seen a few things that surprise me. Every time I break in and check the regs, it appears to be running in ARM mode. With a 16 bit memory bus, I was expecting most of the code to run in Thumb mode. The cpu has an 8kbyte cache, so maybe that makes up for it. Interrupt vectors appear to be stuck at 0x0 to 0x1c. Even with the cpu's vectored interrupt controller, I don't see any way to move the vector table into the sdram memory region. There's no MMU to remap the memory, and the memory controller doesn't allow you to change the base address of the memory banks. Maybe there's some kind of pseudo-vector-jump-table-in-ram trick? Wouldn't it be nice if there was something like a buffer overflow exploit for the MP3 player application? Maybe something to do with crafting a really long filename on the MMC card. Sounds like prplague is making progress with the NAND flash angle...should I get some smartmedia cards and sockets to hack on next? 09-24-2005 17:08:11

RE:What next? (modified 0 times) prpplague Profile the next step is for you to join the wiki at www.elinux.org and add you information. the current line of work is evolving in two directions. first to upload a program to the internal sram to program a smartmedia or xd card with neccessary bootloader code to copy the kernel and ramdisk from the smartmedia or xd. second is to use to a smartmedia/xd usb adapter to be able to write the bootloader code to the card. both methods will allow you to boot from the nand flash interface with custom applications. i've already proved this in concept but practical implemetion is still somewhat difficult. i am curious as to what program you are uploading to sram via the jtag, could you provide us with some code or more info? thanks 09-25-2005 12:25:35

RE:What next? (modified 0 times) newell Profile the next step is for you to join the wiki at www.elinux.org and add you information. I've been lurking around there and on the #elinux channel. I'll try and write something up later today. the current line of work is evolving in two directions. first to upload a program to the internal sram to program a smartmedia or xd card with neccessary bootloader code to copy the kernel and ramdisk from the smartmedia or xd. I'm not sure I follow...it sounds like you'd transfer the entire kernel/ramdisk to the JB, then use the JB to copy the entire kernel/ramdisk over to the card. Correct? There's only 8 kB of sram on chip (if you disable the cache), but plenty of sdram on board... second is to use to a smartmedia/xd usb adapter to be able to write the bootloader code to the card. USB adapter--check. Smartmedia card--nope, but I can check fleabay. Smartmedia socket--nope (any sources?). Do we know exactly how low-level the interface needs to be to write the bootload and have the JB accept it? I have accessed MMC cards under win2k at the sector level (under the filesystem level) to test out some embedded MMC projects that didn't run a filesystem, but that may not be quite low enough. It's been a while since I've handled a smartmedia card, but don't they have decent sized flush gold contact pads? Can you solder directly to those? I'd still rather do the card slot/socket, as it would make interchange between the PC and JB a lot nicer. i am curious as to what program you are uploading to sram via the jtag, could you provide us with some code or more info? Nothing special, just little test utilities written in C (minimal start up, no C runtime libs, etc.), cross-compiled with gcc, and downloaded to sdram. OCD Commander isn't a source level debugger like gdb, but it does allow downloading an .elf or s-record file. I guess I could clean up some demo code and make it available for download. So far I've been able to control the backlight intensity, read the volume control, transmit through the serial port, and read the keypad. No audio or LCD hacking yet. 09-25-2005 13:03:27

RE:What next? (modified 0 times) newell Profile I now have a white horizontal line onscreen, bouncing up and down. Not having much luck determining the relationship between the framebuffer memory and the color of each pixel. Right now, I'm just stuffing 360 consecutive 0xFF bytes in, which gives me the single pixel width horizontal white line. 09-25-2005 21:02:38

RE:What next? (modified 0 times) prpplague Profile I'm not sure I follow...it sounds like you'd transfer the entire kernel/ramdisk to the JB, then use the JB to copy the entire kernel/ramdisk over to the card. Correct? There's only 8 kB of sram on chip (if you disable the cache), but plenty of sdram on board... loading the initial bootloader to the 8kb internal sram is mainly due to the fact that i want to init the sdram and i/o specifically for my settings, once that is done, i have the sdram available for usage. the bootloader would them be able to receive the kernel and ramdisk to sdram, and when commanded to copy the kernel/ramdisk to the smartmedia card. USB adapter--check. Smartmedia card--nope, but I can check fleabay. Smartmedia socket--nope (any sources?). Do we know exactly how low-level the interface needs to be to write the bootload and have the JB accept it? I have accessed MMC cards under win2k at the sector level (under the filesystem level) to test out some embedded MMC projects that didn't run a filesystem, but that may not be quite low enough. first, not all usb->smartmedia adapters allow low level access to the media. most include a media translation layer for smartmedia and xD cards. why? see #2 second, mmc/sd is drastically different than smartmedia and xD cards. mmc/sd contain a controler chip that does the media translation layer. because smartmedia and xD do not contain a controler, this MTL needs to occur either in the adapter or in the software driver for the adapter. there are only two available adapters at present that we know that have raw access to the smartmedia/xD devices: http://alauda.sourceforge.net/wikka.php?wakka=SupportedDevices It's been a while since I've handled a smartmedia card, but don't they have decent sized flush gold contact pads? Can you solder directly to those? I'd still rather do the card slot/socket, as it would make interchange between the PC and JB a lot nicer. my initial tests of the smartmedia were soldered directly to the pads. they are pretty large solder pads with .1" center spacing, i.e. it would be easy to solder .1" pin header to the card. digikey as well as most electronic vendors carry the smartmedia socket, however i've found that the easy supply of smartmedia sockets is simply to purchase an inexpensive adapter and just remove the socket. other sources include some premade protoboards. http://www.wilke-technology.com/html/prod_SmartMedia_Interface.html http://www.sycard.com/ssfdc.html http://www.epboard.com/eproducts/memadapter.htm#SmartMediaCardtoDIPAdapter http://www.xpcgear.com/bytxdsmadapt.html http://www.clubmac.com/clubmac/shop/detail~dpno~342884.asp http://www.semsons.com/xdpiccartosm.html the final howto that i am working on will probably use a xD rather than smartmedia. since the smartmedia has large solder pads, use one of the listed xD->smartmedia adapters as the base socket would extremely easy. 09-26-2005 07:15:19

RE:What next? (modified 0 times) adeptwiz Profile Most interesting. I downloaded OCD Commander. From what I can tell it doesn't work with the wiggler interface? Otherwise it seems to be the perfect tool for the job? (examine juicebox environment, try out code snippets). Newell, could you give a more detailed description of your setup? At this point, I still haven't figured out how to put small code pieces into Juicebox and execute them. wiz 09-26-2005 09:00:18

RE:What next? (modified 0 times) newell Profile Most interesting. I downloaded OCD Commander. From what I can tell it doesn't work with the wiggler interface? Otherwise it seems to be the perfect tool for the job? (examine juicebox environment, try out code snippets). Newell, could you give a more detailed description of your setup? At this point, I still haven't figured out how to put small code pieces into Juicebox and execute them. wiz I'm using the latest OCD Commander under win2k with a generic, non-Macraigor wiggler (I think it's the Olimex arm-jtag http://olimex.com/dev/arm-jtag.html). Not all wigglers have pins 8 & 15 tied together, so you might need to make that mod before recent versions of OCD Commander will recogonize the wiggler. I don't think OCD Commander supports a wiggler under Linux. Any debug setup should work as long as you can read/write memory, halt, go, and download. (Does gdb support a parallel port wiggler, under Linux or windows? Source level debug would be really nice in the very near future, as the programs become more intricate.) The makefile, linker config, startup code, and test code on now on the Wiki. I would have stuck an .elf or s-record file up too, but I don't yet know how to do a file attachment to the Wiki. Let me know what image format your debuggers support and I'll put together some compiled demos. (I put a cpu register header file up as well, but I've switched to a bunch of #define statements instead, so I need to update that.) To test code, I first cross-compile (using the RTEMS ARM toolchain) on my win2k box. Then I start the JB, let it run a little bit to init the CPU registers, and halt it with the debugger. I like to set CPSR to turn off interrupts, but that's probably not required. The debugger can then be used to download the code (in my case, a .elf file) into sdram. Set the PC (OCD Commander will do this automatically as part of the download) and it's ready to go. If you could explain in more detail the trouble you're having with running code on the JB, I could try to be more helpful. 09-26-2005 09:49:23

RE:What next? (modified 0 times) adeptwiz Profile Hi Newell, Thanks for your note. I now know what my problem is. I don't run Windows :(. Otherwise I seem to be up and running. Jtag works fine (I built both Xilinx and wiggler interfaces.). I found a "jtager" program on the web that seems to work fine in non-thumb mode. I can upload memory from juicebox and use objdump to "disassemble" the code. Disassembled instructions seem to make sense, so I suspect my hardware is OK. As I am not about to load windows (VERY long story), guess I'll have to wait for some linux tools! Juicebox is a neat box to poke around. I bought 4 and have one wired into a wiggler. It sits on top of the PC and is fun to play with. I have the thought of using some sort of ARM processor in out new products (someday . Thanks for your most informative answer :) wiz 09-26-2005 10:15:08

RE:What next? (modified 0 times) newell Profile Thanks for your note. I now know what my problem is. I don't run Windows :(. Isn't that a good thing, not a problem? Otherwise I seem to be up and running. Jtag works fine (I built both Xilinx and wiggler interfaces.). I found a "jtager" program on the web that seems to work fine in non-thumb mode. I can upload memory from juicebox and use objdump to "disassemble" the code. Disassembled instructions seem to make sense, so I suspect my hardware is OK. So, what's missing? Can jtager download a file to the JB? What file formats does it support? If not, can you script it to write a file into memory one word at a time? As I am not about to load windows (VERY long story), guess I'll have to wait for some linux tools! I'm not at all suggesting you change your OS. What tools are you waiting for? If you need a cross-compiler toolchain, go to the RTEMS site and download the Linux RPMs. Or build binutils & gcc from source. There's tons of Linux tools out there to cross-compile and target ARM. I have the thought of using some sort of ARM processor in out new products (someday . My initial interest in the JB was as a cheap ARM+LCD dev kit. BTW, the LPC2xxx are fun little ARM microcontrollers. 09-26-2005 10:52:16

RE:What next? (modified 0 times) newell Profile I now have a white horizontal line onscreen, bouncing up and down. Not having much luck determining the relationship between the framebuffer memory and the color of each pixel. Right now, I'm just stuffing 360 consecutive 0xFF bytes in, which gives me the single pixel width horizontal white line. Hah. I forgot about the built in self test--the LCD test has nice solid color test screens. They made a lot of sense--one byte/pixel, using the LUTs, as expected. I copied that LCD config from the self test and now I'm slinging color pixels around. Maybe I'll put another demo together and upload to the Wiki. 09-26-2005 19:45:48

RE:What next? (modified 0 times) prpplague Profile Hah. I forgot about the built in self test--the LCD test has nice solid color test screens. They made a lot of sense--one byte/pixel, using the LUTs, as expected. I copied that LCD config from the self test and now I'm slinging color pixels around. Maybe I'll put another demo together and upload to the Wiki. great! good to hear someone doing some software dev! don't forget to visit the irc.freenode.net channels either #pixterdev or #elinux i'm currently doing a little rework of your example code you posted on the wiki for linux and adding some docs and stuff, however be up this week if i have time. 09-27-2005 06:43:48

RE:What next? (modified 0 times) newell Profile don't forget to visit the irc.freenode.net channels either #pixterdev or #elinux Didn't know about #pixter, but the logs will show I've been lurking around #elinux for a few days now. i'm currently doing a little rework of your example code you posted on the wiki for linux Please let me know what you needed to mod. I just checked by doing a cut-n-paste from the Wiki. Other than the expected space/tab confusion in the makefile, the lcd_1 project built fine (can't test right now) with gcc-4.0.0 under OpenBSD/sparc64. 09-27-2005 07:19:30

RE:What next? (modified 0 times) prpplague Profile Didn't know about #pixter, but the logs will show I've been lurking around #elinux for a few days now. same network as the #elinux channel but called #pixterdev, which nick were you using? Please let me know what you needed to mod. I just checked by doing a cut-n-paste from the Wiki. Other than the expected space/tab confusion in the makefile, the lcd_1 project built fine (can't test right now) with gcc-4.0.0 under OpenBSD/sparc64. the code is fine, mostly changes with the Makefile, i.e. adding a clean option, adding an entry for a .bin file (not all jtag apps can upload a .elf) 09-27-2005 08:12:57

RE:What next? (modified 0 times) prpplague Profile Please let me know what you needed to mod. I just checked by doing a cut-n-paste from the Wiki. Other than the expected space/tab confusion in the makefile, the lcd_1 project built fine (can't test right now) with gcc-4.0.0 under OpenBSD/sparc64. i've been unable to build the test_1 app with the arm-elf tools from uclinux.org. i get a problem with DTOR/CTOR references. this is probably a linker issue based on some mailing list readings. you have any problems with this during your initial build? 09-27-2005 09:37:11

RE:What next? (modified 0 times) newell Profile i've been unable to build the test_1 app with the arm-elf tools from uclinux.org. i get a problem with DTOR/CTOR references. this is probably a linker issue based on some mailing list readings. you have any problems with this during your initial build? Error messages? I would attempt to duplicate your setup, but I don't have a capable linux box handy. FWIW, I'm successfully building with gcc v3.2.3 (probably built from source) on Cygwin, and v4.0.0 (built from source) on OpenBSD/sparc64. 09-27-2005 10:22:25

RE:What next? (modified 0 times) prpplague Profile I'm successfully building with gcc v3.2.3 i've tested with both the 2.95.3 and the 3.4 from the uclinux.org site http://www.uclinux.org/pub/uClinux/m68k-elf-tools/ neither seems to finish linking when using the gcc for the final step, however, if you use ld for the final step it completes. would it be posible for you to post a copy of the .elf file on the elinux wiki so i can make some comparisions with my build to see if there are any differences? thanks 09-27-2005 10:48:45

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

I-Appliance BBS General - NEWS, Breaking NEWS - linux-hacker.net BBS on CD Questions - User Groups in Your Town - E-Bay, Yahoo Auction LINKS ONLY (MODERATED) - Jokes & Humor - usdtv box I-Opener Areas - I-Opener General Posts - I-Opener Technical Stuff - I-Opener Technical Info Reference (MODERATED) WebSurfer Areas - WebSurfer General Posts - WebSurfer Technical Stuff - WebSurfer Technical Info Reference (MODERATED) Other I-Appliances - Virgin Webplayer - WebPal - MailStation - 3Com Audrey - ThinkNIC / Oracle NIC - Gateway/AOL Connected Touch Pad - Philips/AOL-TV - ACER NT-150 STB - MSN Companion - Compaq IA - Emachines IA - IBM NetVista IA - Intel dot.station - MSNTV2 Network Computers - Fujitsu-Siemens Scovery Linux Net Computers - GallantWeb Server Consoles - Dreamcast - xbox hacking Web Pads - Epods One General Post - Panasonic CF-01 - Fujitsu Stylistic 1200 - Cybiko Thin Clients - Thin Clients DigitalVideoRecorders - DTV Recorders, Replay, TiVo, Etc... - Tivo Hacks Linux - Midori Linux General Board - ITX MotherBoards Single Board Computers - Earth Computers mARMalade Elite Member Area MISC Areas - The Swap Meet WE TAKE NO RESPONSIBILITY FOR ANY TRANSACTION HERE AND NO COMMERCIAL POST PERIOD !!! - Wireless Net - Cameras - Robotics - Routers/Gateways - Mattel JuiceBox