[ARMedslack] Armedslack on the Efika i.MX515 (ARM Cortex-A8 800MHz)

[lee jones]

Well, good news! I'm gradually getting somewhere. Those newer
boot/module/firmware files almost did the trick. I say almost as there just
seems to be one tiny little problem.

Ok first off. I deleted everything I had on the first SD card partition and
replaced it with the ones found from here;
http://ausil.us/smartbook/boot-2.6.31.14.22-efikamx.tar

I also downloaded these;
http://ausil.us/smartbook/modules-2.6.31.14.22-efikamx.tar
http://ausil.us/smartbook/firmware.tar.bz2

I moved the contents of those (decompressed) files into /lib (that's where
they decompress to in the files themselves) so that I now have a
"/lib/firmware" and "/lib/modules/2.6.31.14.22-efikamx" .

Note that my armed /etc/fstab and /etc/inittab are the same as earlier, i.e.

>8. Edit on the second SD partition etc/initab and comment out the line
starting "s0:1234", put a # in front of it to comment it out.
>9. Edit on the second SD partition /etc/fstab and add this;
>/dev/mmcblk0p2   /  ext4 defaults 1 1
>/dev/mmcblk0p1  /boot ext3 defaults 0 0

Tried that, rebooted but no joy. I got a blue screen with an empty circle
which gradually turned to white (some sort of loading graphic instead of the
normal boot messages). Next job then was to kill off the loading graphics.

I noticed that the boot-2.6.31.14.22-efikamx.tar file (all of its contents
copied to the first partiton of the SD card) had a script called "
boot.scr.in" which is used to make the boot.scr loader. This script had the
following line in it;

setenv bootargs root=/dev/sda2 rootwait ro rhgb quiet;

So there was my first problem The SD card in my earlier attempts was always
seen by the kernel as /dev/mmcblk0p1 and /dev/mmcblk0p2; sda2 would be seen
as the internal flash on the efika mx. So guessing it might still be the
same way (couldn't see the kernel boot messages at this stage) I changed the
"sda2" to "mmcblk0p2".

The boot-2.6.31.14-22-efikamax.tar file was missing a few script files like
"kernel-prep" and "script-prep" so I copied these from an older boot file as
per my previous attempts to boot.

Ran sudo ./script-prep boot.scr.in boot.scr (from the efika mx's installed
linux) ; Reboot but still nothing. Same graphic and no messages.

So then I noticed a directory in that boot-2.6.31.14-22-efikamax.tar (all
contents copied to the first partiton of the SD card). In it was a directory
called grub and inside that a file called "splash.xpm.gz". Reasoning that
this might be the graphic file, I deleted it. Reran script-prep again (as
earlier) but still no joy, and still a graphic!

Looked again at the boot.scr.in file . This time I tried adding in
"console=tty1" and also removing "rhgb" and "quiet". So the line now looks
like this;

setenv bootargs console tty=1 root=/dev/mmcblk0p2 rootwait ro;

Reran script-prep and rebooted. Some success! No graphic getting in the way
and console messages at last. Though it still didn't complete boot and got
stuck in a similar fashion to my earlier attempts.

However I noticed one thing though (not sure exactly what it does!). The
kernel messages spat out a message about a problem with something caleld
"selinux" and mentioned setting selinux to zero in the kernel boot
parameters (the message suggested using "selinux=0"). I did not know exactly
what this does, but decided to try it (!), and came up with the following
line for boot.scr.in;

setenv bootargs console=tty1 root=/dev/mmcblk0p2 selinux=0 rootwait ro;

Re-ran script-prep and rebooted again. Much better news this time :) I got
to the point whereby I finally got a login prompt!

However now I have some sort of bizarre keyboard problem. I can get to the
point now where I'm asked for the slackware login;

slackware login:

but now if I type in "root" (without the " s !) and press return the system
echos back the letter r followed by the cursor. So it looks like this;

slackware login: root
r_

Pressing return after this gives me a "Password:" prompt. Pressing return
again moves the cursor down to the next line and it just waits for more
keyboard input; pressing return again results in a short (one or two) second
pause and "Login incorrect".

I know a keymap is being loaded at boot, as I changed /etc/rc.d/rc.keymap to
this;

#!/bin/sh
# Load the keyboard map.  More maps are in /usr/share/kbd/keymaps.
if [ -x /usr/bin/loadkeys ]; then
 echo "Loaded a keymap!"
 /usr/bin/loadkeys us.map
fi

(The efika mx smartbook I'm using has a US keyboard layout, btw). And when
the system boots I can see my message "Loaded a keymap!" along with "Loading
/usr/share/kbd/keymaps/i386/qwerty/us.map.gz" so I know it is loading in
some sort of keymap, though it dosen't seem to be 100% quite working because
of the problems above (maybe there's an arm keymap?).

ljones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.armedslack.org/pipermail/armedslack/attachments/20110829/d6732f40/attachment.html>