[1] http://www.beagleboard.org/~share/validation-GNOME-2.6.32-all-kernel-modules-try2-image-beagleboard-sd-4GiB.img.gz
Koen,
Per off-line discussions, thanks for updating the image to include
I’ve mirrored the latest image at: http://www.beagleboard.org/~share/validation-GNOME-I-lost-count-image-beagleboard-sd-4GiB.img.gz
The follow issues have been noted by people trying it out:
- u-boot reports “Beagle unknown 02”. I can release a patch today to fix this if no one else says they want to do it. (probably need to fix ahead of release, but I could live with the questions)
I submitted a patch to u-boot for this, but haven’t pushed it to Angstrom yet. I’ll try to do that shortly after I finish my checkout.
-
u-boot prints a message about not finding a uEnv.txt. There doesn’t need to be one, but I will recommend to CircuitCo that they put one on the image they ship. Do we want hd720 or 640x480? I’d lean toward hd720 and just hold the USER button down to get 640x480, because that would cause user.txt to be looked for instead of uEnv.txt. My settings at https://groups.google.com/d/msg/beagleboard/0cthQxYZ344/_1KoP0eRgd4J did prevent the screen from blanking for a day, but something happened and now it has started going blank again. (no need to fix ahead of release)
-
Booting the kernel I get an error about libnl.so.1 not found. Can you say why this is? (only need to fix ahead of release if it is symptomatic of a larger problem)
Not sure about that one, I suspect it’s a dlopen() kind of error. Any way to find out which app/lib is giving that error?
It is NetworkManager.
- The 3D demos work, but the texture streaming demo does not.
Running it from the command line produces the error:
root@beagleboard:/# /usr/bin/gles2_bc_webcam-x11
INFO: current input is Camera 1
ERROR: BCIOREQ_BUFFERS failed
done
root@beagleboard:/#
Steve guesses this means the application cannot get buffers from the bufferclass_ti driver. Do you have any ideas here? (probably need to fix ahead of release to show the camera working)
This probably needs some spare VRAM to work
something like:
setenv vram ‘16M’
setenv dvimode ‘hd720 omapfb.vram=0:8M,1:4M,2:4M’
I have in /proc/cmdline: console=ttyS2,115200n8 console=tty0 consoleblank=0 mpurate=auto buddy=none camera=lbcm3m1 vram=16M omapfb.mode=dvi:hd720 omapfb.vram=0:8M,1:4M,2:4M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
The texture streaming demo app still fails as above.
The “consoleblank=0” setting also doesn’t seem to be working for me as when the GUI comes up, the screen goes blank. It worked for a day for me, so I’m confused what that was about (perhaps some events were keeping the monitor awake?) I’m not sure if Gerald needs it, but I’ve tried adjusting the power management settings in GNOME to see if that makes a difference for me.
- I need to change the size of memory to test passed to testmem. (might not need to fix before release)
Based on the xM free memory, I should probably change this from 360M to 330M, or perhaps 320M.
- The editbootscr/edituserscr utilities are now obsolete. The example boot scripts need to be replaced with example environment variable text files. (might not need to fix before release)
All,
Can you please try this image out? This one looks very close to what will ship. I’m interested if anyone misses the Qt or GStreamer labs, any browsers or media players, anything?
Regards,
Jason
Other issues I’ve found:
6) In u-boot, if you set the i2c device to something other than 0, you can get an error in the mmc command:
OMAP3 beagleboard.org # mmc rescan 0
I2C read: I/O error
I2C read: I/O error
I don’t think this is worth fixing prior to any release, but it is something for me to fix.
-
The u-boot MUSB serial emulator isn’t working. (don’t fix, but I might consider pulling in the DFU patch as a stretch goal)
-
testcamera screws up the GNOME session as well as the serial console session. If we are booting into X11, it probably makes sense to switch to gnome-mplayer. If the texture streaming demo was working, I’d just switch testcamera to use it. Since testcamera/mplayer does show that the camera input is working, I’d put this in the category of not required to fix before shipping, but if there is another revision, include gnome-mplayer. I did confirm that “gnome-mplayer tv:///” works.
-
The g_ether instructions are working again, so I’m pretty happy about that, but the kernel still crashes when you power-up with USB connected. Can we ship with g_ether installed by default and request that people replace the kernel if the want not to have g_ether, rather than the other way around?
-
“opkg install kernel-2.6.37” doesn’t work. It seems to be on a different feed. This makes installing the newer kernel for using the BeagleBoardToys Wi-Fi adapter pretty complicated. I did:
echo “src/gz beagleboard-next http://www.angstrom-distribution.org/feeds/next/ipk/eglibc/armv7a/machine/beagleboard” >> /etc/opkg/beagleboard-next-feed.conf
opkg update
opkg install kernel-2.6.37
opkg install kernel-image-2.6.37
opkg install kernel-modules
ln -sf /boot/uImage-2.6.37 /boot/uImage
vim /media/mmcblk0p1/UENV.TXT # update console as appropriate
vim /etc/inittab # update console as appropriate
opkg install iw
vim /etc/network/interfaces # update wlan0 as appropriate
shutdown -r now
I don’t know what to do next as ‘modprobe wl1271_sdio’ or ‘modprobe wl1271_spi’ both give unknown symbol errors and I don’t see another wl1271 .ko file to load. I was able to figure that some modules didn’t get upgraded, but I’m still working through the details.
(I believe Gerald is requiring a documented upgrade process to a kernel that works with the wifi board. Can you document the process?)
-
The MLO and u-boot files in /boot are old. Why? The ownership is also odd with it being set to www-data. (Not critical, but nice to fix.)
-
http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/u-boot/u-boot_git.bb shows ttyO2 should be the default, but that isn’t the version being built. That is quite confusing. I am just noticing we are using 2011.03-maintenance for this. Looking at the logs, it seems you are aligning the key recipes quickly on this. I guess for those looking to pick something up and run with it, being off of that branch is indeed better. (nothing to fix)