Tuesday, April 13, 2010

Fedora 12 on SDHC and booted on Sheevaplug!

Success, Success, Success!

So, continuing from my last post I learned a lesson that well, I've learned before but I guess I never want to face the reality of it: Things don't just magically happen lol.

The good news is, the Fedora 12 installation on the SD card was successful. However, I had to actually configure u-boot (the bootloader built into the SheevaPlug) in order to actually tell it to use the SD card when booting. (This is when I also reminded myself, "Hey Alex, this isn't Windows where you can just hit a function key and select which device to boot from...DUH!")

Before I could configure u-boot, I had to update it to the newer version. I used the following source to perform the update:

http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html

I was having some issues with the system reading the uboot.bin file from my USB key but I just re-copied the file over to the USB drive and it updated successfully.

I rebooted and could finally configure u-boot with the following commands:

Marvell>> setenv mainlineLinux yes
Marvell>> setenv arcNumber 2097
Marvell>> setenv bootargs_console console=ttyS0,115200
Marvell>> setenv bootargs_root 'rw root=/dev/mmcblk0p1 rootdelay=10 rootfstype=ext2'
Marvell>> setenv bootcmd_mmc 'mmcinit; ext2load mmc 0 0x800000 /boot/uImage-2.6.30-sheevaplug'
Marvell>> setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x0800000'
Marvell>> saveenv
Marvell>> reset

As soon as I reset the device, Fedora booted up. It prompted me for the username (root) and password (fedoraarm) and TADAAAA!

Saturday, April 10, 2010

First attempt at F12 install on SD card

So, as you may already have guessed just by the title of the blog post, I was unsuccessful at getting things to work the way I was hoping :( However, on a positive note, I learned a few things along the way.

I first wanted to try getting Fedora 12 on an SD card. Why? well assuming you haven't read my previous blog posts, my goal is to get F12 working on a SheevaPlug.

This is what I did:

1. I plugged an ethernet cable into the SheevaPlug and connected it to my network.

2. I checked the DHCP table on my router to find out the IP that was assigned to the SheevaPlug (192.168.15.109)

3. SSH root@192.168.15.109

4. I inserted the SD card into the SheevaPlug's card reader slot

At this point, I decided to use the steps found HERE to help me install F12 on the SD card. The only difference is the instructions on this page use an external media card reader (a usb based one) attached to a separate Linux machine instead of using the actual Sheevaplug to prep the SD card.

This difference is good to know when following Steps 2-5 (on the linked page). The instructions show that the device comes up as /dev/sdc. However in my case the device came up as mmc1.

I hit a snag at STEP 6 (on the linked page). wget didn't seem to be installed so I decided to install it. However, (yea that's right, just when things seem so simple lol) I had to configure the device's network settins (specifically the default gateway).

COMMAND: route add default gw 192.168.15.109

Then I added the name server to /etc/resolv.conf.

Finally, I could run apt-get install wget. Moving along with the f12 installation everything went smoothly (so I thought). I restarted the device, and noticed it was taking longer to boot up. While the boot up process was happening I was getting the following error messages:

Empty flash at 0x08b59008 ends at 0x08b59800
Empty flash at 0x08e5da90 ends at 0x08e5e000
Empty flash at 0x11e3606c ends at 0x11e36800
Empty flash at 0x1cd3b804 ends at 0x1cd3c000

Eventually the prompt to log-in came up and I knew at that point things didn't work the way they were suppose to. I logged into the SheevaPlug and ran dmesg | tail and this is what I got:

root@debian:~# dmesg | tail
Empty flash at 0x0881d338 ends at 0x0881d800
Empty flash at 0x08b59008 ends at 0x08b59800
Empty flash at 0x08e5da90 ends at 0x08e5e000
Empty flash at 0x11e3606c ends at 0x11e36800
Empty flash at 0x1cd3b804 ends at 0x1cd3c000
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 104K
JFFS2 notice: (259) check_node_data: wrong data CRC in data node at 0x08b59000: read 0x65d2282d, calculated 0xc228ad7.
JFFS2 notice: (385) check_node_data: wrong data CRC in data node at 0x1ba59000: read 0x7c0f9814, calculated 0xa9f38ad5.
fat: exports duplicate symbol fat_add_entries (owned by kernel)

As of right now, I am stuck at that. As soon as I get a clue on what went wrong I will post an update.

Tuesday, April 6, 2010

Connecting to the SheevaPlug using Windows 7

I got my hands on the much anticipated SheevaPlug today! Nothing better than opening up a new toy.


Tiny little bugger... I am still quite impressed on how small this device is. Fan-less design and low consumption... Ah yes, I can see David Suzuki smiling to the thought of a "Green" computer.

Accessing the device in Windows 7

Step 1: Connect the device using the mini USB -> USB cable.

Step 2: Chances are Windows will struggle to find drivers for the device so just use the SheevaPlug_Host_SWsupportPackageWindowsHost.zip file that is included in the DevKit CD. Unzip it and use Device Manager to browse for the TeraTerm Drivers (located as a sub directory in the zip file you just extracted).

Step 3: Windows will find 2 devices (USB Converter A and B) A = JTAG port B = serial port. We want to connect to the serial port.

Step 4: Click on Port B, select properties and in the Advance tab ensure LOAD VCP is selected.

Step 5: Unplug the device, and plug it back in.

Step 6: Using PuTTY, connect to the COM port of "PORT B" and make sure the SPEED is set to 115200.




Step 7: You might need to press ENTER once or twice to get the prompt to actually show (sounds silly but it took me a while to figure that out lol).

Step 8: Login using the default authentication information (username = root ) (password = nosoup4u) (For you SEINFELD fans out there, this is a great password lol)



Other sources for Connecting to SheevaPlug:
Source 1
Source 2

I would have connected the device to my Linux box today but just like me, it seems the machine is feeling a little under the weather. I am going to do some troubleshooting so I can start the Fedora 12 installation on the SD card for the SheevaPlug.

I will keep everyone posted!

Monday, April 5, 2010

Preparing for the SheevaPlug

So, I know, I know, everyone misses my fantastic blog posts (lol) It has been a while but I've got myself another task.

The task is related to the ARM project and the SBR600 class and the objective is to get Fedora 12 installed on a SheevaPlug device. Although the device had just arrived today, I was unable to actually go and get it. HOWEVER, I decided to do some research and get some information for when I actually do have the device.

First off you may be thinking, what the heck is a SheevaPlug? Good question, I was thinking the same thing at first. After a quick google search, the answer to this question was answered! The SheevaPlug is one of the first "Plug computers". It gives the phrase "Plug and Play" a whole new more literal meaning! And fcourse, it has an ARM CPU (hence why it's related to the SBR600 ARM project)

For more info about the actual device click here.

According to the information I found it seems that the SheevaPlug comes loaded with a Ubuntu build. (That's soon going to change!) I have found a web page that explains a 10-step process of installing Fedora 12 on a SheevaPlug (a little too good to be true I think, but I guess I'll soon find out).

SheevaPlug....HERE I COME!

Tuesday, March 2, 2010

JShydra Packaging cont.. Stage 1 complete.

This blog is a direct continuation to my last blog post "Packaging JShydra - Stage 1".

I left off with a problem within the %setup section of my spec file. The issue was that the %setup -n option had to be used for this macro. Instead of %setup -q I changed it to %setup -n jshydra.

For more info on the %setup macro, click here.

With that fixed, the next issue was: http://pastebin.org/100301

This problem was due to the fact that there is no makefile and therefore for I had to specify where the build should happen.

I edited the %install section to look like this: %install rm -rf %{buildroot} install -d %{buildroot}/var/www/html/jshydra

I ran the rpmbuild again and well, success! After running rpmlint, everything seems to be going alright.

Here are the results of rpmlint:



Click here for my SPEC file!

Next up... MOCK!

Packaging JShydra - Stage 1

It's been a while since I've blogged, feels kind of nice to get back on here actually. Continuing with the DXR project I have obtained a "packaging" role. My new job now aside from being the REPO master is to package JShydra.

JSHydra Description: JSHydra is a static analysis tool that is capable of performing analysis of general JavaScript code. It is inspired by the Dehydra and Treehydra tools, which can perform similar tasks in C++ code. In its back-end, it uses the parse tree created by the SpiderMonkey engine. All analysis is performed by running JavaScripts.

More info on JShydra click here


I must admit, it has been a slow process getting started (It has been a while since I've had to package something).

There is no actual source tar file of JShydra out there, so I went into the GERMANY cdot machine and found jshydra on there. I created a tar file of the directory and moved the tar file over to my home directory under rpmbuild/SOURCES.

Using the INSTALLING JSHYDRA page off of Mozilla's developer site I started the SPEC file.

Issue #1 (Where I am currently stuck on...)

http://pastebin.org/100264

I will be blogging again as soon as I find a solution....

Monday, February 15, 2010

DXR Repo Update

Basically this week was just making sure any new releases coming into the dropoff directory were appropriately placed in the repo.

Boris Chao
released - dehydra-0.9-3.fc11.x86_64.rpm
dehydra-0.9-3.fc10.i386.rpm


Jonathan Deni
released - viewsource-1.1-2.fc11.noarch.rpm


I am still waiting on Adam Hilts for the matching source rpms.

Another major update/change to do with the repository was done by Jonathan Deni as he performed an audit on the repo rpm SPEC file to ensure it met Fedora Guidelines.

Check his blog post out.


Thats all for now!