Wifi not working when booting from SD

[trix]

[sOLVED! - Wish I could edit title to reflect this but ah well]


I'm trying to get a dev environment set up but I'm too low on NAND space to do it from there.


So while hanging out in IRC, stuckie linked me to his gcc-preinstalled Angstrom image, which I plopped on an SD card and booted into. Yep, it works, except no wifi. I need wifi. I tried the Toggle Wifi option in System menu, says it's enabling, but no dice, doesn't enable. Dropped into terminal and tried to sudo /etc/init.d/wl1251-init restart, and it fills the screen with .ko modules all giving the same error ("insmod: Unknown symbol in module"). What the hell? Stuckie had a couple suggestions for me, but they didn't help. So, I figured, somehow that image doesn't want to work with my Wifi. The wifi works great from NAND still, never had a problem. So I figured maybe something wifi is using is set up differently on my NAND install then on the SD image.


So, I formatted a 16GB SD card to ext2, copied the NAND over, made an autoboot.txt, and booted into it. So far so good, the OS loads from SD, and it looks exactly like it does booting from NAND, including wallpapers, settings, etc. To ensure I was really in SD space, I went to the terminal and hit df -h and it shows root as having 12.8GB free. Nice. I notice the wifi icon down near the clock has the little x, even though on NAND I have wifi set to enable on boot. Ah well, Menu -> System -> Toggle Wifi. Says it's enabling, then it doesn't enable! Uh oh. Drop into terminal, try to restart the wl1251-init script and.... the same friggin insmod errors!


Well, I'm stumped. All I can think at this point is something about booting from SD as opposed to NAND is messing with the wifi scripts. Not sure what or how, but perhaps someone has more experience with those things and can think of something that might be the culprit? I really want to get started porting awesome stuff to Pandora, so any help would be highly appreciated!


Thanks!


- trix

 

[trix]

Well I've been thinking, and the only thing I can think of that would be different booting from SD rather then NAND in relation to wifi, is that either something is failing before the SD makes itself root because the root changes, or perhaps after the SD's root becomes the OS root something about the wifi device (or it's scripts) is getting overwritten. But, that doesn't explain the particular insmod errors I am seeing when invoking the wl1251-init script manually.


Now, after a little investigation, it seems that error is caused by either having an unknown symbol in the module (duh!) OR by including incorrect parameters. I have no idea what parameters it may be trying to specify, but it occurs to me that if the .ko modules themselves had unknown symbols in them I'd be having this problem on NAND as well. Thus, I think that a parameter that is correct in relation to running off of NAND, becomes invalid or incorrect when booting from SD. But, if that is the case, how are other people booting from SD without this problem? And that, to me, seems to be the biggest WTF, as my Pandora is not really very custom in any way, especially when it comes to kernel, OS, and drivers! I haven't had time to go deep and start messing things up yet!


So, still stumped. Does anyone have any ideas or suggestions I could try?


Thanks!


- trix

 

[trix]

SOLVED! Thanks to aTc in IRC! Turns out, the kernel it was loading was not compatible with the modules for wifi and touchscreen. Getting uImage-omap3-pandora.bin from http://openpandora.org/firmware/images/ and plopping it into /boot/uImage solved it! Sweet!

 

[trix]

I don't know about "in few words"... I cannot seem to make a post that doesn't end up extremely huge. And that's AFTER a few edits to cut down the length. I tend to go on...


Also, DISCLAIMER: I have broken my system about FIFTY goddamn times by screwing around with experimental crap JUST LIKE THIS. Including THIS EXACTLY. Thus, EXPECT TO BREAK YOUR SHIT. Not permanently of course, but having to reflash is DEFINITELY possible. Be sure to read the wiki about reflashing firmware, and have the image and reflashing process HANDY and READY prior to trying anything as made-up-as-I-went-along experimental as this. I am no expert!


Anyway the process I used was somewhat simple, and stolen from the wiki, with a few modification as I seem to have custom problems. I've done it now four times, as my experimentation keeps breaking my SD install, and I run into the same issues every time, even though these issues don't seem to happen to other people. So, MY process is not necessarily YOUR process, but here's what I do:


First, I decide which SD I want to boot from. I move everything it contains that I want to the other SD card (or somewhere else) and make sure it's in the LEFT slot. For the left-right challenged, the slot closes to the headphone hole.


Following that, I make certain the SD card is un-mounted. gparted can do this for you, but I'm a command line monkey so I just hit:

sudo umount /media/mmcblk0p1

sometimes, for no apparent reason, my Pandora mounts the left slot as /media/mmcblk1p1 instead, so if that's the case i change the command accordingly.

Then, I format the SD in ext2. Why not ext3? I dunno. I don't think my SD really needs a journal.

For this I use gparted. I used fdisk the first time, as I prefer the command line, but gparted works well so whatever.

I deleted every partition on the card so I had a clean space, then stuck all that space into a primary ext2 partition. Labelled SDBOOT. For no reason.



Then, I drop to command line and mount the SD. To avoid confusion, I usually mount it manually and make sure it's mounted to /media/SDBOOT so I don't mistakenly mess with the wrong SD.



After that, I basically follow the wiki process to copy my NAND install to SD. With a few modifications. If you check out the wiki link, scroll down to "OR copy your firmware from the NAND to the SD card". Otherwise, the modified instructions follow:

cd /

sudo mkdir /mp

sudo mount --bind / /mp

sudo cp -va /mp/* /media/SDBOOT

sudo umount /mp

sudo rmdir /mp

Now, for other people that seems to do the trick, after this they make the autoboot.txt (which I will cover in just a moment) and it seems to work. Not for me however. If I leave it at that, when I boot up, my touchscreen and wifi do not work. Everything else works, but I need wifi! Turns out that somehow the kernel being copied over is no longer compatible with the modules that I copied over. I have no idea why this is, but there it is. So, to fix it, I do this:

cd /media/SDBOOT/boot

sudo wget http://openpandora.org/firmware/images/uImage-omap3-pandora.bin

sudo mv uImage-omap3-pandora.bin uImage

there. That kernel IS compatible with my (hotfix 5) modules.

Of course, this will not boot yet. It needs autoboot.txt!

cd /media/SDBOOT

sudo nano -c autoboot.txt

This opens an empty text file named autoboot.txt

Inside of this file, i paste:

setenv bootargs debug root=/dev/mmcblk0p1 rw rootdelay=2 console=ttyS0,115200n8 vram=6272K omapfb.vram=0:3000K

ext2load mmc 0 0x80300000 /boot/uImage

bootm 0x80300000

then I hit CTRL+X to tell nano I'm done, then Y when it asks to save the file. autoboot.txt set up and ready. Awesome!



At this point I unmount both SD cards and reboot:

sudo umount /media/SDBOOT

sudo umount /media/mmcblk*

sudo reboot

Once rebooted, if I leave the card in, it boots to my SD! Well, since my SD is a direct copy of the NAND, the boot process, while much slower, looks exactly the same as it did from NAND. So, once at my desktop, i make sure I'm on the SD by opening the terminal and typing:

df -h

Now in my case my SD card is 16GB, so when df shows my root filesystem as having 13.5GB free (I have other stuff on the SD too) I know I am definitely booted into my SD card.

Now this is important, so recognize the bold underlined importance:

DO NOT REMOVE SD CARD WITHOUT TURNING OFF PANDORA FIRST!!



As I've said, I had to do this whole process several times, a couple times due primarily to unthinkingly popping out the SD card while the Pandora was booted into it. This is bad. Nothing so bad it will ruin your card or Pandora, but bad to the point you might have to reformat the card, boot from NAND, and start this whole process over.



This is OPTIONAL, and often DANGEROUS. But I like opkg. So, next, I update it:

sudo opkg update

Now, from playing with opkg and trying to set up a dev environment, I found one other issue with this method. I'm not sure if this issue is just me or general to anyone who would do things this way.

After using opkg to install stuff, many things set themselves up in sort of a broken way. Namely, symlinks. For example, libpng has a habit of doing this every single time on my system. To check the symlinks after I use opkg to install some stuff, I do this:

cd /usr/lib

sudo file * | grep broken

Now, any package in here that has broken symlinks, like libpng whenever I opkg install it, will make itself known via that file command. I'm not sure if sudo is necessary in this case, but as long as you type the command CAREFULLY and double check before hitting enter, it wont hurt.



So, in the case of libpng.so it says something like "broken symbolic link to libpng.so.0.44.0" or something. I am typing all this from memory (my Pandora is not with me at the moment) and it's been a bit so the actual message wont be exact, but something similar.



Using my ultimate intellectual ability, I was able to surmise that this message probably means that libpng.so is supposed to be a symlink to libpng.so.0.44.0. If it's broken, lets find out why!

ls libpng*

Hmm, it shows a bunch of libpng stuff. One of them is libpng.so.0.42.0 -- which is similar but slightly different then what libpng.so is trying to link to. AHA! Lets fix that. First, we remove the broken link.

sudo rm libpng.so

Then, replace it with one that works.

sudo ln -s libpng.so.0.42.0 libpng.so

Okay. That's fixed. But there are other broken symlinks too! or maybe not. Your system may differ.


In fact, the whole libpng part of this half-assed tutorial of mine is JUST AN EXAMPLE! A specific one, yes, but an example. The purpose of it is in case you do have symlink errors in /usr/lib like I do. When I use the above method to make my NAND OS onto SD, I get these symlink errors. More and more of them the more stuff I opkg install. The above symlink-fixing method fixed all these errors for me. I had to recreate like 10 or 15 symlinks this way, but once created they work fine.


I should mention, that I only noticed this problem, when attempting to compile software, and getting an error from ./configure script that "libpng not found". I KNOW I installed it. Trying to install it again opkg would tell me it's already up to date. Eventually after much headache and experimentation, someone brilliant from IRC came along and helped me trace the problem to these symlinks. Now, checking and fixing them, is a standard part of using opkg on my Angstrom SD Card. Use the above as a template for finding and solving most of your issues. Just remove the broken symlink, find what it probably wanted to link to (google or IRC if unsure!), and symlink it properly!


So that's my method. There you go Alerino. Although, it appears I failed your "in few words" criteria by leaps and bounds. Ah well.


To answer your other question (is it faster), well, no. The initial boot up was way slower the first time, now it seems about the same speed from NAND to SD, though I haven't actually timed it. Keep in mind I'm using a Class 10 card. The advantages are the ability to (ab)use opkg, having a dev environment set up natively, and having NAND to fall back on when I inevitably do something stupid and break the system.


-


Oh as an added note, if you change the name of autoboot.txt to boot.txt in my tutorial/walk-through/thingy, you can hold down the right shoulder button while turning it on and get a boot menu, and choose to boot from SD to there. This way, if you do not hold down the shoulder button, it will default to NAND booting still. If that's what you prefer. I use autoboot.txt because I prefer the default to be SD, and have the NAND as backup.


Also, I refuse to proof-read this giant post. If something is incorrect or bugs you, feel free to reply and quote it. I will edit and fix it.


- trix