My son got a toy Melman at McDonalds in a happy meal a while ago. He love the thing. He pounds it on EVERYTHING. When you pound it, Melman says one of three phrases. Recently, however, Melman's voice started to give out. So I thought I'd replace the batteries. Should be easy, right, since those toys are just held together with a couple of screws.
Turns out it wasn't quite so easy. The screws are triangular. This means that a regular screw driver wouldn't work. I tried forcing it with some precision screw drivers I had, but they were all just the wrong size. A few google searches later and I found a few places that have them. The cheapest one sells bits for about $3.00. Currently, there's a catalog link here, but who knows how long it will last. I also found amermeida who sells through amazon that sells a screw driver for the triangle recessed screws for $2.00, but with $5.00 for shipping. I wound up ordering there.
Once the screw driver arrived, I removed the screws. There were L738H cells in place that were drained. I didn't have any of these cells on hand, and it was a cold night, so I raided my watch battery drawer in my shop. I had Energizer 392's. These were about 1-2mm thinner than the L738, but were close enough. I was able to bend the battery holder a bit and they slid right in. I snapped Melman back together, and I had a happy 2-year-old again.
Maybe I'll be able to repair other toys with this screw driver. I hope so, since I don't think the original toy itself cost $7.00. There's a couple of cars that he has which are held together with the same type of screw.
More on FreeBSD/mips another time...
20090129
20090127
Alchemy Au1550 status update
I'm in the very early stages of bringing FreeBSD/mips on the Alchemy Au1550. Plat'Home was kind enough to put an OpenMicroServer into my hands for the port. After months of sitting idle, I've started putting the board to use again. I test booted my first kernel tonight. It is still early days, but I thought I'd mention that I'd committed the very preliminary code to the project/mips tree in svn.
As an aside, the FreeBSD/mips main development has moved from the so-called "mips2" tree in perforce to the projects/mips tree in svn. This move allows us to more easily share the work in progress mips ports that people have been asking for in the past. We'll see how well this works out and see if theory matches reality or not.
As an aside, the FreeBSD/mips main development has moved from the so-called "mips2" tree in perforce to the projects/mips tree in svn. This move allows us to more easily share the work in progress mips ports that people have been asking for in the past. We'll see how well this works out and see if theory matches reality or not.
20090125
More Video Creation hacks
I believe that I've blogged before about my video creation on FreeBSD. Here's some interesting tips for DIVX players that I've found.
First, to recap: I tape a lot of hockey games with my DV camera. I use
Recently, I had my DVD player of many years die on me. It refused to play disks. So I went out gone one that would play DivX disks, as well as normal DVDs. This one also has a USB port on it. Through trial and error, I discovered that I could save myself a lot of disks by putting the videos I wanted to test on a flash drive.
DivX videos, for those that don't know, are basically MPEG-4 AVI encoded rather than MPEGE-2 encoded like DVD movies. While DVD movies can play as low as about 4 or 5kbps, they are generally encoded at more like 10kbps. At that rate, the average single layer disc can hold about 2 hours of video. DivX movies are encoded at more like 1-2kbps, so are about 3-6 times smaller than their DVD encoded counterparts. Of course, these are gross generalizations, but good enough for people to understand.
Now, my problem is that I have about 18 hours of hockey games that I'd like to distribute to the parents of the other players. For my son's benefit, I had made one DVD per game, but with 11 other parents, the thought of making 200 DVDs filled me with dread: it was too much time, too much hassle and it was starting to get expensive.
So, I started experimenting with DivX encoded videos. I tried to get ffmpeg working, but ran into a number of snags that I basically punted on. I had used mplayer for years to watch other videos and DVDs, so I thought about using mencoder. kino had a mode that would encode the DV movies to something else, so I played around with it. I created two test videos. One was at 854x480. This is what you get when you film in 16:9 aspect ratio with a DV camera that has a resolution of 720x480. Google for anamorphic for all the reasons for this, but they can be summarized as non-square pixels converted to square pixels. For the curious, I used:
One of these days, I'll need to learn how to do the fancy two-pass encoding to ring every bit of quality I can out of my source material. But for now, I'm doing good to get things encoded. I also need to find some way to tame the insane complexity of this problem. The above commands were basically minor tweaks to ones I found in kino's scripts to encode the video.
As for the DivX disk, I just copied the files over, and they played in alphabetical order. No way I could see to create a menu. No way to encode them in the .divx format that has menus and such in it, since I couldn't find the equivalent to dvdauthor for divx movies (please leave comments if you know of one for FreeBSD/Linux). For the hockey games for the parents, this is likely good enough. For other things, I'd like to do better...
First, to recap: I tape a lot of hockey games with my DV camera. I use
fwcontrol -R name.dv -M dvto read in the tapes. I then use the kino port to do some editing and convert the .dv files into mpeg 2 files for the DVDs of the games I make. I convert the mpeg2 files to dvds using dvdauthor. When I want to be fancy, I use dvdstyler to create themes for the DVDs.
Recently, I had my DVD player of many years die on me. It refused to play disks. So I went out gone one that would play DivX disks, as well as normal DVDs. This one also has a USB port on it. Through trial and error, I discovered that I could save myself a lot of disks by putting the videos I wanted to test on a flash drive.
DivX videos, for those that don't know, are basically MPEG-4 AVI encoded rather than MPEGE-2 encoded like DVD movies. While DVD movies can play as low as about 4 or 5kbps, they are generally encoded at more like 10kbps. At that rate, the average single layer disc can hold about 2 hours of video. DivX movies are encoded at more like 1-2kbps, so are about 3-6 times smaller than their DVD encoded counterparts. Of course, these are gross generalizations, but good enough for people to understand.
Now, my problem is that I have about 18 hours of hockey games that I'd like to distribute to the parents of the other players. For my son's benefit, I had made one DVD per game, but with 11 other parents, the thought of making 200 DVDs filled me with dread: it was too much time, too much hassle and it was starting to get expensive.
So, I started experimenting with DivX encoded videos. I tried to get ffmpeg working, but ran into a number of snags that I basically punted on. I had used mplayer for years to watch other videos and DVDs, so I thought about using mencoder. kino had a mode that would encode the DV movies to something else, so I played around with it. I created two test videos. One was at 854x480. This is what you get when you film in 16:9 aspect ratio with a DV camera that has a resolution of 720x480. Google for anamorphic for all the reasons for this, but they can be summarized as non-square pixels converted to square pixels. For the curious, I used:
mencoder sample.mpeg -cache 8192 -aspect 16:9 -vf harddup,pp=ci,scale=854:480 \to encode the DVD-quality images into divx. This encoding resulted in a factor of 3-4 saving in file sizes. This was fairly good, but didn't get my 40GB of mpeg's to fit on one DVD. In addition, the DVD player I bought didn't like this resolution at all. I figured other people's DVD players wouldn't like it either. Next, I tried a reduced resolution version. I used
-ovc xvid -oac mp3lame -lameopts preset=192 -xvidencopts bitrate=2048 -ffourcc DX50 \
-o high.avi
mencoder - -demuxer rawdv -quiet -cache 8192 -aspect 16:9 -vf harddup,pp=ci,scale=426:240 \which resulted in a space savings more like 6-10, which puts the encoding project within striking distance of one DVD. It is well under the DL DVD range, and might be very close to the single layer limit of 4.7GB. We'll have to see how the encoding goes. It is moving about 4x faster than the previous encoding as well.
-af-adv force=1 -srate 44100 -ovc xvid -oac mp3lame -lameopts preset=medium \
-xvidencopts fixed_quant=4 -ffourcc DX50 -o medium.avi
One of these days, I'll need to learn how to do the fancy two-pass encoding to ring every bit of quality I can out of my source material. But for now, I'm doing good to get things encoded. I also need to find some way to tame the insane complexity of this problem. The above commands were basically minor tweaks to ones I found in kino's scripts to encode the video.
As for the DivX disk, I just copied the files over, and they played in alphabetical order. No way I could see to create a menu. No way to encode them in the .divx format that has menus and such in it, since I couldn't find the equivalent to dvdauthor for divx movies (please leave comments if you know of one for FreeBSD/Linux). For the hockey games for the parents, this is likely good enough. For other things, I'd like to do better...
20090123
Quick Mac OS X hack: Time Machine
I have two macs in my house. One has a 750GB drive on it for backups, plus its normal disk. It had been setup for Time Machine before and was working well. I also have a MacBook Pro that needs to be backed up. I didn't want to swap the disk back and forth between the two, since that would significantly erode the value of Time Machine's automatic backups. I didn't see any place where this was well documented, so I thought a quick note would be helpful to people. Most of the references I've seen have talked about different hacks to make this happen, or that it is only on a specialized Apple product that I didn't have.
I'm running Mac OS X 10.5.6 on both machines.
First, I went to the store and bought a 750GB drive. I plugged it into the mac mini that I have sitting on my desk. I configured it for Time Machine on the Mac Mini. I did a couple of time machine backups.
Next, I exported 750GB disk using the 'Sharing.' I clicked on 'File Sharing' tab to enable it. I clicked on the '+' button under the "Shared Folders" menus. I selected the volume that I had setup for Time Machine. I made sure that I was sharing via "AFP" in the "Options..." dialog.
Once I had things shared this way, I went to the other mac. I went to "Finder" and selected "Go->Connet to Server.." tab. Here I explicitly typed "afp://ipaddr/" and connected. Once I was connected this way, I proceeded to enable Time Machine. The remote disk appeared on the list of choices, so I just selected it and started it up.
I discovered that I have a 100Mbps switch, rather than a GigE switch. This made the initial backup very slow, on the order of 10GB/hr, which means I'm looking at a 10 hour backup time. Maybe it makes sense to head off to staples/best buy to get a GigE switch to plug them both into.
I've not tried to do this wirelessly, so I don't know how painful that will be. I've also not tried to connect this to the Samba server that I have running FreeBSD. I can normally see that volume on the macs without needing to do the manual step.
UPDATE: A GigE switch does help quite a bit. It was more like 6GB/hr with the 100Mbps switch, but with GigE I'm getting about 22GB/hr... So I have about 3 hours left in the backup now... 22GB/hr is about 6MB/s which seems way too slow (the hard disks are limited to about 15MB/s on each side, and the network to 125MB/s, so why the fall off in speed).
I'm running Mac OS X 10.5.6 on both machines.
First, I went to the store and bought a 750GB drive. I plugged it into the mac mini that I have sitting on my desk. I configured it for Time Machine on the Mac Mini. I did a couple of time machine backups.
Next, I exported 750GB disk using the 'Sharing.' I clicked on 'File Sharing' tab to enable it. I clicked on the '+' button under the "Shared Folders" menus. I selected the volume that I had setup for Time Machine. I made sure that I was sharing via "AFP" in the "Options..." dialog.
Once I had things shared this way, I went to the other mac. I went to "Finder" and selected "Go->Connet to Server.." tab. Here I explicitly typed "afp://ipaddr/" and connected. Once I was connected this way, I proceeded to enable Time Machine. The remote disk appeared on the list of choices, so I just selected it and started it up.
I discovered that I have a 100Mbps switch, rather than a GigE switch. This made the initial backup very slow, on the order of 10GB/hr, which means I'm looking at a 10 hour backup time. Maybe it makes sense to head off to staples/best buy to get a GigE switch to plug them both into.
I've not tried to do this wirelessly, so I don't know how painful that will be. I've also not tried to connect this to the Samba server that I have running FreeBSD. I can normally see that volume on the macs without needing to do the manual step.
UPDATE: A GigE switch does help quite a bit. It was more like 6GB/hr with the 100Mbps switch, but with GigE I'm getting about 22GB/hr... So I have about 3 hours left in the backup now... 22GB/hr is about 6MB/s which seems way too slow (the hard disks are limited to about 15MB/s on each side, and the network to 125MB/s, so why the fall off in speed).
20090122
Minor at91 hacking
The recent changes to the SD/MMC stack broke AT91. It seems like there was an assumption that was bogusly baked into the driver. We had assumed that the only data transfer commands would be 512 bytes.
The problem is that the newer stack does commands that are 16 and 64 bytes long. These aren't really needed for basic support of the stack, but to get things like SDHC and high speed transfers working, they are needed.
I've fixed this, and now things work again. I've also taken this opportunity to do some minor cleanups to the at91 mmc/sd driver.
The problem is that the newer stack does commands that are 16 and 64 bytes long. These aren't really needed for basic support of the stack, but to get things like SDHC and high speed transfers working, they are needed.
I've fixed this, and now things work again. I've also taken this opportunity to do some minor cleanups to the at91 mmc/sd driver.
20081216
Audio Ripping on FreeBSD
For years I've been batching up my new CDs to rip all at the same time. Sometimes, this means doing a couple a month. Other times, like this year, it means catching up with 12 months of backlog. And while my ripping habits likely are uninteresting to readers, what I've learned over the years may be helpful.
Years ago I installed the 'abcde' port, and update it from time to time. Having it in-place, and configured, makes all the difference in the world. I use cdparanoia as my reading method since it is the slow but reliable choice.
There are many silly process things that make things go faster. First, make sure that you have all the CDs in the cases that you have stacked up. A few days before I start to rip, I go through the stack to make sure that none are on walk-about. Next, grab a bottle of windex, and a lint-free cloth. Wash each of the CDs, assembly line style. Sometimes I only do this for the discs that fail, but often times it helps things go so much faster that it can be worth the up front time.
Once I have the discs prepped, I pick a time that I'm not using my laptop too much to do the ripping. For me, this is often my work day, since I look at it from time to time for email and irc messages only. My laptop DVD player isn't the best in the world, but that's OK. The ones that rip quickly, I don't have to do anything about. The ones that are scratched badly, I put aside for later. The easy ones are boring, since abcde makes them boring, so I'll not describe the process much further. Each disc takes about 10 minutes to rip and transcode them.
The scratched discs are more of a challange. I've used a lot of players over the years. They vary widely in their quality. The cheapo player I have in my laptop copes with most of the discs. If I see too many + signs in a disc, I'll set it aside for later. Here, too many is 'more + than spaces in the output' when I look over at the screen several times. Or if there's any 'V' indications on any of the tracks. These usually take longer to do anyway, and get in the way of breezing through the easy CDs. Each year, I have maybe 5 discs that are stubborn, out of maybe 30 that I do. Long term averages are that 1 in 10 newly purchased 'used' disc show this. Discs that have been knocking around in the car for months are more likely to suffer from this as well. Really stubborn ones are more like 1 in 100, but more on that in a bit.
I have a special CD-ROM (not DVD) that I use for the scratched discs. Of all the drives I've tested/used over the years, this one has the best success rate by far of any of them. This one happens to be a 52x/20x/20x IDE drive branded by HP I got at Target, of all places, several years ago. I can take a disc that has 20-30 V's on it with my cheapo laptop setup, and sometimes get a good read with this player. Often, the discs just read quickly, and that's the end of it.
Sometimes, however, the disc is badly damaged and is that it is very slow. I was able to rescue a Moxie Froovis CD and a Phil Collin's greatest hits CD with this drive. But it took a week each of reading. When the drive is connected to a server, it doesn't matter so much that it is doing this. The CPU time isn't all that great during the week, so it doesn't interfere with the normal server operations. I look in on them once an hour at first, then once a day until the songs are done. Since I rarely have more than one or two of these a year, the extra time isn't that big a deal.
At one point, I had a dozen laptops with CD Roms that I could use for ripping. I thought this would be great, since I could do so many in parallel. It turns out that the CD Rom drives in these were even cheaper than the one I'm using today. I spent so much time running between the laptops that I didn't get any work done. And the CPUs in these boxes were all, at best, squirrel powered, so they couldn't handle the encoding as well as my 2GHz HP Pavilion laptop does now. At the time, I just did it serially on the server I had (which was a 666MHz Intel), and changed it every hour or two. I could still run it remotely, so I wasn't running back to the server room except to change a disc.
Today, with iTunes and other music places online, the art of coaxing bits off of audio CDs seems a bit passe. However, it is still something I find I'm doing a lot. Used CDs cost almost nothing, compared to $1/song for iTunes. Plus, format shifting is so much easier with audio CDs than with iTunes. Also note: I'm not talking about sharing my collection over the internet, just making the archival copies, and format shifted copies, as allowed by law and court decision. I still have most of the original CDs, and those I no longer have had been destroyed by my two-year-old when he was younger... But that's a story for a different time...
Years ago I installed the 'abcde' port, and update it from time to time. Having it in-place, and configured, makes all the difference in the world. I use cdparanoia as my reading method since it is the slow but reliable choice.
There are many silly process things that make things go faster. First, make sure that you have all the CDs in the cases that you have stacked up. A few days before I start to rip, I go through the stack to make sure that none are on walk-about. Next, grab a bottle of windex, and a lint-free cloth. Wash each of the CDs, assembly line style. Sometimes I only do this for the discs that fail, but often times it helps things go so much faster that it can be worth the up front time.
Once I have the discs prepped, I pick a time that I'm not using my laptop too much to do the ripping. For me, this is often my work day, since I look at it from time to time for email and irc messages only. My laptop DVD player isn't the best in the world, but that's OK. The ones that rip quickly, I don't have to do anything about. The ones that are scratched badly, I put aside for later. The easy ones are boring, since abcde makes them boring, so I'll not describe the process much further. Each disc takes about 10 minutes to rip and transcode them.
The scratched discs are more of a challange. I've used a lot of players over the years. They vary widely in their quality. The cheapo player I have in my laptop copes with most of the discs. If I see too many + signs in a disc, I'll set it aside for later. Here, too many is 'more + than spaces in the output' when I look over at the screen several times. Or if there's any 'V' indications on any of the tracks. These usually take longer to do anyway, and get in the way of breezing through the easy CDs. Each year, I have maybe 5 discs that are stubborn, out of maybe 30 that I do. Long term averages are that 1 in 10 newly purchased 'used' disc show this. Discs that have been knocking around in the car for months are more likely to suffer from this as well. Really stubborn ones are more like 1 in 100, but more on that in a bit.
I have a special CD-ROM (not DVD) that I use for the scratched discs. Of all the drives I've tested/used over the years, this one has the best success rate by far of any of them. This one happens to be a 52x/20x/20x IDE drive branded by HP I got at Target, of all places, several years ago. I can take a disc that has 20-30 V's on it with my cheapo laptop setup, and sometimes get a good read with this player. Often, the discs just read quickly, and that's the end of it.
Sometimes, however, the disc is badly damaged and is that it is very slow. I was able to rescue a Moxie Froovis CD and a Phil Collin's greatest hits CD with this drive. But it took a week each of reading. When the drive is connected to a server, it doesn't matter so much that it is doing this. The CPU time isn't all that great during the week, so it doesn't interfere with the normal server operations. I look in on them once an hour at first, then once a day until the songs are done. Since I rarely have more than one or two of these a year, the extra time isn't that big a deal.
At one point, I had a dozen laptops with CD Roms that I could use for ripping. I thought this would be great, since I could do so many in parallel. It turns out that the CD Rom drives in these were even cheaper than the one I'm using today. I spent so much time running between the laptops that I didn't get any work done. And the CPUs in these boxes were all, at best, squirrel powered, so they couldn't handle the encoding as well as my 2GHz HP Pavilion laptop does now. At the time, I just did it serially on the server I had (which was a 666MHz Intel), and changed it every hour or two. I could still run it remotely, so I wasn't running back to the server room except to change a disc.
Today, with iTunes and other music places online, the art of coaxing bits off of audio CDs seems a bit passe. However, it is still something I find I'm doing a lot. Used CDs cost almost nothing, compared to $1/song for iTunes. Plus, format shifting is so much easier with audio CDs than with iTunes. Also note: I'm not talking about sharing my collection over the internet, just making the archival copies, and format shifted copies, as allowed by law and court decision. I still have most of the original CDs, and those I no longer have had been destroyed by my two-year-old when he was younger... But that's a story for a different time...
20081214
DLink DIR-615 Rev C1
Today I saw that Office Depot had a DIR-615 on sale for $40.00. It was a new hardware revision: C1. I took a chance that it was a new non-Ubimax based router. I'm glad I did, at least so far.
The router is based around the Atheros AR9130 CPU. This is MIPS based, so there's a good chance that I'll be able to put FreeBSD onto it. We'll see how it goes.
I'll report more when I get a chance to examine the RAM and Flash parts, as well as map out the serial port to see what is reported there. Stay tuned.
The router is based around the Atheros AR9130 CPU. This is MIPS based, so there's a good chance that I'll be able to put FreeBSD onto it. We'll see how it goes.
I'll report more when I get a chance to examine the RAM and Flash parts, as well as map out the serial port to see what is reported there. Stay tuned.
20081213
More CardBus fixes
After I committed my previous set of CardBus fixes, reports came in about interrupt storms, first with 16-bit cards, and later with 32-bit cards. These have been corrected in my latest fixes. We always act the CSTS interrupt when we see it. In addition, I've changed the acking of the 16-bit ExCA register to only happen when there's a "R2" or 16-bit card in the slot. Otherwise we now skip it. Hopefilly, this will help the shared interrupt case as well by eliminating some PCI bus cycles...
The CSTS bit is interesting. It is the least well documented bit in the CardBus standard. It is unclear when it fires from reading the standard, but seems to be related to the card finishing its reset sequence. How this differs from the power-up interrupt, I'm not sure. I think we could further optimize the bring up of CardBus cards with it.
In addition, I noticed there's a READY bit in the ExCA CSC register. We're currently doing busy waits to bring up the cards, including a couple of millisecond long DELAYs. I'll have to look into the prospect of using that interrupt to get around these issues there.
Finally, I'm looking in earnest at the Alchemy Au1550 CPU for the OpenMicroServer port I'm doing. I've noticed that it uses a 16-bit PC Card interface. Maybe I'll finally need to rewrite the old PCIC driver from OLDCARD to make use of it (snagging the exca routines to make that easier). The OpenMicroServer has a CF card attached to it.
The CSTS bit is interesting. It is the least well documented bit in the CardBus standard. It is unclear when it fires from reading the standard, but seems to be related to the card finishing its reset sequence. How this differs from the power-up interrupt, I'm not sure. I think we could further optimize the bring up of CardBus cards with it.
In addition, I noticed there's a READY bit in the ExCA CSC register. We're currently doing busy waits to bring up the cards, including a couple of millisecond long DELAYs. I'll have to look into the prospect of using that interrupt to get around these issues there.
Finally, I'm looking in earnest at the Alchemy Au1550 CPU for the OpenMicroServer port I'm doing. I've noticed that it uses a 16-bit PC Card interface. Maybe I'll finally need to rewrite the old PCIC driver from OLDCARD to make use of it (snagging the exca routines to make that easier). The OpenMicroServer has a CF card attached to it.
20081204
Cardbus Fixes
I just checked into the tree some CardBus fixes. The biggest change was to the power-up sequence, as well as transitioning to using filters for the card change events. These two changes are somewhat intertwined, unfortunately, since the latter exposed some holes in the former. In a nutshell, we now register a filter for the card status change events. This means we can mark the card as bad right away before any additional interaction can happen to the card. We defer doing anything about the badness for a little bit (basically until the machine is idle enough for the cardbus kernel thread to run). The interlock mechanism is also much ligher weight, having moved from mutexes and CVs to simple msleeps. Fast interrupts require some care to get right, so I hope I've gotten it all right. The move is dictated by what you can and cannot do in a fast interrupt handler.
Before making these changes, my atheros card would often reset for no reason. After these changes, I've not had it reset until I started using a kernel without the changes. I'm not sure why this would make such a big difference, and I hate mysteries. They indicate that there's something I don't understand, which I also hate. I'd be interested to see if I still see this when the fully integrated code is committed and looped back (I have several trees, and I most frequently run an unmodified kernel from svn, but sometimes also run one of these trees). There's a small chance that one of my other local changes could be the cause, but given what they are it seems doubtful. Still, a good datapoint if it is.
In addition, these fixes add a retry option for the BadVcc errors that we'd see sometimes. These are annoying on some machines, and often times the best way to get around them was to reload the driver. They don't happen at all on TI based chipsets that I've seen (at least more recent ones). Instead, they were confined to the Ricoh chipsets. Since I switched my laptop a couple of years ago, I haven't seen them. These changes post-date the change, but have been tested lightly on another Ricoh laptop that I have. They've been heavily tested on the TI laptop. They are based only on the description of the problem in the NetBSD PR, since the implementations are so different for the different BSDs in this area.
Finally, I did some comment tweaking and shuffling. I also managed a style change or two. These should have absolutely no effect on the running code, but hopefully help the reader of the code understand it better. Past experience has shown that these types of commits are most likely to provoke comment, even though the other two parts of my commits are actually quite a bit more important.
Oh, why the flurry of commits? I was low on disk space, so I thought I'd go clean up. 11MB free just isn't enough. So I was looking around and discovered I still had a CVS tree and was going to blow it away. I did a final update just to see what changes I had. I'm glad I did, since I found these, and a few others. I still have more local changes there than I realized. Sometimes I guess it is good to run out of disk space and go on a cleaning spree? It also makes for smaller backups when you don't have top copy 5GB of /usr/obj and kernel build trees...
Before making these changes, my atheros card would often reset for no reason. After these changes, I've not had it reset until I started using a kernel without the changes. I'm not sure why this would make such a big difference, and I hate mysteries. They indicate that there's something I don't understand, which I also hate. I'd be interested to see if I still see this when the fully integrated code is committed and looped back (I have several trees, and I most frequently run an unmodified kernel from svn, but sometimes also run one of these trees). There's a small chance that one of my other local changes could be the cause, but given what they are it seems doubtful. Still, a good datapoint if it is.
In addition, these fixes add a retry option for the BadVcc errors that we'd see sometimes. These are annoying on some machines, and often times the best way to get around them was to reload the driver. They don't happen at all on TI based chipsets that I've seen (at least more recent ones). Instead, they were confined to the Ricoh chipsets. Since I switched my laptop a couple of years ago, I haven't seen them. These changes post-date the change, but have been tested lightly on another Ricoh laptop that I have. They've been heavily tested on the TI laptop. They are based only on the description of the problem in the NetBSD PR, since the implementations are so different for the different BSDs in this area.
Finally, I did some comment tweaking and shuffling. I also managed a style change or two. These should have absolutely no effect on the running code, but hopefully help the reader of the code understand it better. Past experience has shown that these types of commits are most likely to provoke comment, even though the other two parts of my commits are actually quite a bit more important.
Oh, why the flurry of commits? I was low on disk space, so I thought I'd go clean up. 11MB free just isn't enough. So I was looking around and discovered I still had a CVS tree and was going to blow it away. I did a final update just to see what changes I had. I'm glad I did, since I found these, and a few others. I still have more local changes there than I realized. Sometimes I guess it is good to run out of disk space and go on a cleaning spree? It also makes for smaller backups when you don't have top copy 5GB of /usr/obj and kernel build trees...
Moving towards board files
I've spent a little bit of time implementing the start of board files for the arm port. The initial push has been for the at91 subport only, and many improvements could be made to this. I've written up my initial thoughts on this on the FreeBSD wiki FreeBSD Arm Boards. It could use much improvement, I'm sure.
One idea that hasn't been reflected there yet, was shown to me by Sam Laffler who suggested using linker sets to allow boards to 'probe', 'init' and other standardized functions. This is an interesting idea and I plan on working on adding it to the above links when Sam has results to share.
I'd also like to expand the above wiki page to be a 'best practices' guide for all architectures where there's great diversity of boards/cpus/etc (eg, not the homogeneous env that x86 provides).
I'm also soliciting comments on the above boards in addition to the above. Send them to me, or post them here.
One idea that hasn't been reflected there yet, was shown to me by Sam Laffler who suggested using linker sets to allow boards to 'probe', 'init' and other standardized functions. This is an interesting idea and I plan on working on adding it to the above links when Sam has results to share.
I'd also like to expand the above wiki page to be a 'best practices' guide for all architectures where there's great diversity of boards/cpus/etc (eg, not the homogeneous env that x86 provides).
I'm also soliciting comments on the above boards in addition to the above. Send them to me, or post them here.
20081202
Cassio Fiva's screen dead
I was very fortunate enough to get a Casio Fiva MCP-205 given to me in 2000. I've used this laptop for years. I built Mozilla on it once, and melted the frame around the LCD! This resulted in a new warning in the Mozilla build instructions. Since Casio is a Japanese company, and I got this as the result of my contacts in Japan at the time, my news of melting the Fiva spread like wild fire there. Recently, when I was in Tokyo for AsiaBSDCon people were asking me about it.
I've been using this laptop to do background builds, as a mobile terminal, firewire debugging platform, etc since I got it. Recently, i had put the laptop on the shelf. I'd not used it in the past 6 months or so for a variety of reasons. Last night I thought I'd give it a spin again, since I need a nice mobile platform. Sadly, while it was in storage the screen was cracked. I cannot get any text on the screen at all. I don't have the VGA cable so I could keep this laptop around as a server, since there's no console access. I cannot find an LCD to replace it, but I imagine that it would be expensive. More expensive than a modern netbook, which would be better for the FreeBSD project anyway...
It is sad to see this laptop give up the ghost. Every time I used it, I was reminded of the good times in Japan. I'll hang onto the laptop for a little while on the off chance I can turn up a replacement LCD, but I fear it is dead.
I've been using this laptop to do background builds, as a mobile terminal, firewire debugging platform, etc since I got it. Recently, i had put the laptop on the shelf. I'd not used it in the past 6 months or so for a variety of reasons. Last night I thought I'd give it a spin again, since I need a nice mobile platform. Sadly, while it was in storage the screen was cracked. I cannot get any text on the screen at all. I don't have the VGA cable so I could keep this laptop around as a server, since there's no console access. I cannot find an LCD to replace it, but I imagine that it would be expensive. More expensive than a modern netbook, which would be better for the FreeBSD project anyway...
It is sad to see this laptop give up the ghost. Every time I used it, I was reminded of the good times in Japan. I'll hang onto the laptop for a little while on the off chance I can turn up a replacement LCD, but I fear it is dead.
20081114
MeetBSD
I'm in California this weekend for MeetBSD, celebrating FreeBSD's 15th birthday!
Come on out and join the fun.
Come on out and join the fun.
20081013
Marvell ARM support in svn
Rafal Jaworowski just committed support for a number of Marvell Processors. There are a number of commits going into the tree. He's just completed the first of these:
Introduce low-level support for new Marvell core CPUs: 88FR131, 88FR571.
From an earlier email message, we know that Rafal is working on support for Marvell 88F5182, 88F5281, 88F6281, and MV78100 SoCs.
The following peripherals will likely be supported:
This is a fairly mature port that is going into the tree. It works with NFS or USB mounted root filesystems. The port is self hosted. Kernel and world builds succeed on the box. The box also boots to multiuser mode. Rafal has created a web page with all this information on it on the FreeBSD wiki at http://www.wiki.freebsd.org/FreeBSDMarvell
This is way cool news! Good Job Rafal.
Note: Much of this information was taken from a posting Rafal made to arm@freebsd.org.
Introduce low-level support for new Marvell core CPUs: 88FR131, 88FR571.
From an earlier email message, we know that Rafal is working on support for Marvell 88F5182, 88F5281, 88F6281, and MV78100 SoCs.
The following peripherals will likely be supported:
- EHCI USB 2.0
- Ethernet
- GPIO
- Interrupt controller
- L1, L2 cache
- Timers, watchdog, RTC
- TWSI (I2C)
- UART
This is a fairly mature port that is going into the tree. It works with NFS or USB mounted root filesystems. The port is self hosted. Kernel and world builds succeed on the box. The box also boots to multiuser mode. Rafal has created a web page with all this information on it on the FreeBSD wiki at http://www.wiki.freebsd.org/FreeBSDMarvell
This is way cool news! Good Job Rafal.
Note: Much of this information was taken from a posting Rafal made to arm@freebsd.org.
20081004
gxemul update
Oleksandr Tymoshenko posted a patch to gxemul that allows FreeBSD/mips to boot on it.
I've committed it to the gxemul port. So now if you have gxemul 0.4.6.5_1 or later, you can run FreeBSD/mips, the MALTA kernel. I'll post a howto and a pointer to a image in a few days.
I've committed it to the gxemul port. So now if you have gxemul 0.4.6.5_1 or later, you can run FreeBSD/mips, the MALTA kernel. I'll post a howto and a pointer to a image in a few days.
20080930
SD/MMC work
Recently, I've pushed many bug fixes from Alexander Motin to the SD/MMC stack. He's submitted a driver for the SD Assocaition's standard SD Host Controller, and fixed many of these minor issues as part of doing that. I've tested these improvements on my AT91RM9200 system that boots off an SD card.
There should be more support for MMC cards, as well as SDHC cards forthcoming. In addition, once I get a chance to review the sdhc driver, it too may be ready to head into the tree. I know that if I had such a working driver, I'd be able to work more on SDHC and MMC card support. The current AT91RM9200 box I have makes it difficult...
Stay tuned for more updates.
There should be more support for MMC cards, as well as SDHC cards forthcoming. In addition, once I get a chance to review the sdhc driver, it too may be ready to head into the tree. I know that if I had such a working driver, I'd be able to work more on SDHC and MMC card support. The current AT91RM9200 box I have makes it difficult...
Stay tuned for more updates.
20080919
FreeBSD/mips updated
Here's an update in status to the FreeBSD/mips tree. David O'Brien has been working through issues one at a time to get things building, primarily getting gcc support merged in. After learning from David that more patches were needed than were in my blog, I spent some time collapsing changes from p4 into the main tree. I've updated my patches, and confirmed they work.
First, you can find the patches from my FreeBSD drop box. These patches are 42k right now. This is from my tree that I pulled at revision 183198, taken at 3:30pm MDT September 19th, 2008, for the nit-pickers out there. At this level, I'm able to apply the patch, do a buildworld and all the kernels except SENTRY5 build. To build things:
I've just done the build testing at this point. Stay tuned in the coming days for how to setup a qemu or gxemul image and how to run this in emulated. I hope to get instructions for how to deal with real hardware a little bit after that. Right now the ADM5120 kernels are a little too big for the hardware that I have and it will take some time to sort out.
Hopefully we'll have these last 42k of patches into the tree in the coming weeks. I'll keep everybody posted. There are some additional fixes in p4 as well on top of this which I'm still sorting out, but those should be going in as well.
First, you can find the patches from my FreeBSD drop box. These patches are 42k right now. This is from my tree that I pulled at revision 183198, taken at 3:30pm MDT September 19th, 2008, for the nit-pickers out there. At this level, I'm able to apply the patch, do a buildworld and all the kernels except SENTRY5 build. To build things:
% svn update
% fetch http://people.freebsd.org/~imp/MipsSvn.diff
% patch -p0 < MipsSvn.diff
% setenv TARGET mips
% setenv MAKEOBJDIRPREFIX /tmp/$LOGNAME/obj
% make buildworld
% make buildkernel KERNCONF={ADM5120,IDT,MALTA,QEMU}
I've just done the build testing at this point. Stay tuned in the coming days for how to setup a qemu or gxemul image and how to run this in emulated. I hope to get instructions for how to deal with real hardware a little bit after that. Right now the ADM5120 kernels are a little too big for the hardware that I have and it will take some time to sort out.
Hopefully we'll have these last 42k of patches into the tree in the coming weeks. I'll keep everybody posted. There are some additional fixes in p4 as well on top of this which I'm still sorting out, but those should be going in as well.
20080903
FreeBSD embedded (mips, powerpc, arm) update
The last week or so has show a spike up in FreeBSD embedded platform work. Fixes for mips and powerpc have gone into the tree. Support for a new ARM platform is getting ready to be committed. FreeBSD/mips is almost self-hosting in the svn tree (it has been in the p4 tree for some time). FreeBSD/powerpc and FreeBSD/arm continue to mature.
Thanks to a flurry of activity over the weekend by David O'Brien, the number of patches needed for FreeBSD/mips has been reduced to a set for libpam and for binutils. David cleaned up the diffs for gcc and pushed them into the tree in a manner that allows for easier upstream committing.
In addition, David has cleaned up a number of dangling nits in the build. This is the result of a slight mismatch between p4 and the code in FreeBSD's svn tree. Oleksandr Tymoshenko has looped back most of these changes into p4, and is working on resolving the conflicts that were generated. Once this is sorted out, Oleksandr or myself will generate a new set of diffs and go for the final push into the tree.
I'm looking forward to having a good base for FreeBSD/mips in the tree. I've been busy with a number of other projects and haven't given it the time that I really want to give.
On the PowerPC side of the ledger, Marcell Moolenaar and Rafal Jaworowski have been polishing uboot boot loader support in the FreeBSD/powerpc subversion tree. In addition, some bug fixes to and code polishing of the low level Book E PowerPC support have been committed. Many of these improvements were obtained from Semihalf consulting.
On deck to be committed soon is support for Marvell's Orion NAS chips. This code has been in perforce for a while now and is nearly ready for the FreeBSD tree. I'll keep everybody posted when that happens. I hope to have my DLINK DIR-615 Rev A1 working by then with this code, but time has been tight and there's already too many different projects afoot in my life.
Thanks to a flurry of activity over the weekend by David O'Brien, the number of patches needed for FreeBSD/mips has been reduced to a set for libpam and for binutils. David cleaned up the diffs for gcc and pushed them into the tree in a manner that allows for easier upstream committing.
In addition, David has cleaned up a number of dangling nits in the build. This is the result of a slight mismatch between p4 and the code in FreeBSD's svn tree. Oleksandr Tymoshenko has looped back most of these changes into p4, and is working on resolving the conflicts that were generated. Once this is sorted out, Oleksandr or myself will generate a new set of diffs and go for the final push into the tree.
I'm looking forward to having a good base for FreeBSD/mips in the tree. I've been busy with a number of other projects and haven't given it the time that I really want to give.
On the PowerPC side of the ledger, Marcell Moolenaar and Rafal Jaworowski have been polishing uboot boot loader support in the FreeBSD/powerpc subversion tree. In addition, some bug fixes to and code polishing of the low level Book E PowerPC support have been committed. Many of these improvements were obtained from Semihalf consulting.
On deck to be committed soon is support for Marvell's Orion NAS chips. This code has been in perforce for a while now and is nearly ready for the FreeBSD tree. I'll keep everybody posted when that happens. I hope to have my DLINK DIR-615 Rev A1 working by then with this code, but time has been tight and there's already too many different projects afoot in my life.
20080829
Sandbox pictures
I've had several requests for pictures of my son playing in the sandbox. I'll go one better and show pictures of my son and I playing in the sandbox. My wife took them just after I filled it with sand.
Now, all I have to do is make a lid for the box to keep the local cats and racoons out.
Now, all I have to do is make a lid for the box to keep the local cats and racoons out.
20080828
Sandbox
I debated writing about this. After all, it isn't about hacking code. Instead, it is about hacking together a sandbox. It is about making stupid design choices and then over engineering "solutions" to those problems. It is a cautionary tale about doing the design right from the start and sometimes "free" lumber costs a lot in time and effort.
So, I wanted to make a 4'x4' (just a little over 1m x 1m) sandbox for my 2 year old. He loves sand in the parks and I wanted him to have a place to play in the back yard. My wife suggested we just get one of those turtles, but I wouldn't hear of it. After all, I had a bunch of 2x4's in the garage. Why pay good money for a plastic turtle when I could just build a simple box out of the 2x4's.
I wanted a 4" depth of sand, so I figured I'd have to stack the 2x4's. Rather than just buy a couple of 2x8's and bolt them together, I had to use 2x4's. Of course, I had planned on stacking them, but what I hadn't planned well was how to do it. I wound up with small 2x2's as wooden cleats. So I get the box put together. It was fairly straight forward to do this. I connected the two halves of the box with short 2x2's. I proudly showed it to my wife who immediately said "those sharp edges sticking out look dangerous." She was talking about the 2x2's. Once I saw it from her point of view, I realized she was right.
Now, rather than spend $8.00 on 2 2x6's or 2x8's for the box, I spent $9.86 on 12 6" ceramic coated screws to hold the box together. I then drilled holes and recessed the heads (why? I don't know, just seemed like a good idea even though they were on the bottom). I drove the screws in and removed the 2x2 cleats. The box looked great! And I even managed to add the trip onto another trip to a near by store, so I didn't blow a ton of time and gas getting them. That was luck, pure and simple, since usually for things like this I'm making another trip...
I then went to put it where we'd agreed and realized I had no bottom. I had to do something about a bottom. I thought I'd just use some of the yard fabric I had left over from all my landscaping chores. Turns out that I left all that at my old house. So instead I took and old tarp with a tear in it and cut a 4'x4' section and laid it on the ground and put the sandbox on top of it. I then filled it with the play sand I'd been lugging around in my car for a week while I finished the box. Time will tell if I secured things in place well enough or not. I was planning on going to the store to get a bunch of rebar to drive into the ground to keep the box from moving, but I realized just how crazy this was getting and I just made a couple of wooden wedges to hold the thing in place. We'll see how that works out, but they are likely good enough, and were scrap anyway...
In the end, I spent 4 hours building this box. While a turtle would have saved me a bunch of time, and would likely have cost about the same as what I spent on wood, nails and screws (all but the last one had already been purchased, but I did pay for them). I'd have been done in 30 minutes. Of course, I wouldn't have gotten to use the power tools, and I really like the idea of building things for my son. I put the sand in tomorrow and we'll see how well he likes the box.
So, am I crazy? Did I go overboard on trying to save a nickle only to cost myself a ton of time? Maybe. Did I have fun putting it together? You bet! Was it worth it? Yes...
So, I wanted to make a 4'x4' (just a little over 1m x 1m) sandbox for my 2 year old. He loves sand in the parks and I wanted him to have a place to play in the back yard. My wife suggested we just get one of those turtles, but I wouldn't hear of it. After all, I had a bunch of 2x4's in the garage. Why pay good money for a plastic turtle when I could just build a simple box out of the 2x4's.
I wanted a 4" depth of sand, so I figured I'd have to stack the 2x4's. Rather than just buy a couple of 2x8's and bolt them together, I had to use 2x4's. Of course, I had planned on stacking them, but what I hadn't planned well was how to do it. I wound up with small 2x2's as wooden cleats. So I get the box put together. It was fairly straight forward to do this. I connected the two halves of the box with short 2x2's. I proudly showed it to my wife who immediately said "those sharp edges sticking out look dangerous." She was talking about the 2x2's. Once I saw it from her point of view, I realized she was right.
Now, rather than spend $8.00 on 2 2x6's or 2x8's for the box, I spent $9.86 on 12 6" ceramic coated screws to hold the box together. I then drilled holes and recessed the heads (why? I don't know, just seemed like a good idea even though they were on the bottom). I drove the screws in and removed the 2x2 cleats. The box looked great! And I even managed to add the trip onto another trip to a near by store, so I didn't blow a ton of time and gas getting them. That was luck, pure and simple, since usually for things like this I'm making another trip...
I then went to put it where we'd agreed and realized I had no bottom. I had to do something about a bottom. I thought I'd just use some of the yard fabric I had left over from all my landscaping chores. Turns out that I left all that at my old house. So instead I took and old tarp with a tear in it and cut a 4'x4' section and laid it on the ground and put the sandbox on top of it. I then filled it with the play sand I'd been lugging around in my car for a week while I finished the box. Time will tell if I secured things in place well enough or not. I was planning on going to the store to get a bunch of rebar to drive into the ground to keep the box from moving, but I realized just how crazy this was getting and I just made a couple of wooden wedges to hold the thing in place. We'll see how that works out, but they are likely good enough, and were scrap anyway...
In the end, I spent 4 hours building this box. While a turtle would have saved me a bunch of time, and would likely have cost about the same as what I spent on wood, nails and screws (all but the last one had already been purchased, but I did pay for them). I'd have been done in 30 minutes. Of course, I wouldn't have gotten to use the power tools, and I really like the idea of building things for my son. I put the sand in tomorrow and we'll see how well he likes the box.
So, am I crazy? Did I go overboard on trying to save a nickle only to cost myself a ton of time? Maybe. Did I have fun putting it together? You bet! Was it worth it? Yes...
20080827
Low hanging fruit
Tonight was low hanging fruit night. I went through all the PRs that had "pccard" or "cardbus" and committed the easiest of the fixes. When I did this with USB last year there were maybe 50 of them I committed over the course of a few weeks. For PC Card and CardBus, there were maybe 5 or 6 that I was able to commit. And a similar number of stale ones. Unlike USB, there's only a few PC Card and CardBus bugs in the PR database, at least that are flagged as such.
I find this surprising, since any CardBus card that uses I/O ports hasn't worked in a while. And CardBus card whose CIS is stored in "Expansion ROM" won't work. There's a bunch of problems with some of the newer "ed" cards as well for PHY handling. At least I've recently solved some of the power issues, or I'd be feeling pretty low about the state of affairs. Fortunately, most people want a CardBus slot for a wireless card these days, and atheros chipsets are memory mapped.
The ExpressCard stuff is stalled at the moment while I ponder a difficult problem with resource allocation. There's likely a simple solution to this problem that I'm not seeing, but it likely requires thinking a little outside the box to make it totally effective.
I find this surprising, since any CardBus card that uses I/O ports hasn't worked in a while. And CardBus card whose CIS is stored in "Expansion ROM" won't work. There's a bunch of problems with some of the newer "ed" cards as well for PHY handling. At least I've recently solved some of the power issues, or I'd be feeling pretty low about the state of affairs. Fortunately, most people want a CardBus slot for a wireless card these days, and atheros chipsets are memory mapped.
The ExpressCard stuff is stalled at the moment while I ponder a difficult problem with resource allocation. There's likely a simple solution to this problem that I'm not seeing, but it likely requires thinking a little outside the box to make it totally effective.
Subscribe to:
Posts (Atom)