Re: [beagleboard] Re: [beagleboard-gsoc] Re: Here is the BeagleBone Debian (beta + fixes) image you want to test (2014-03-19)
Since I saw GPU support on the newer 3.8/3.12 kernels will there be a version that has PVR support? Thanks ~Chris -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: [beagleboard-gsoc] Re: Here is the BeagleBone Debian (beta + fixes) image you want to test (2014-03-19)
*Debian X11/LDE display problem ?* hello, I was having trouble to debug a problem related with the bootup process and the LDE GUI display. I am just a beginner so I'm not really sure what or why, but in the end it worked for me. *Configuration / Notes:* *BBB: Rev A5C *Power source: Using barrel connector +/- USB connector *Monitor: Samsung S22B300 Sync-master *Debian Build: root@beaglebone:# uname -a => Linux beaglebone 3.8.13-bone41 #1 SMP Tue Mar 4 22:51:47 UTC 2014 armv7l GNU/Linux *uEnv: cat /proc/cmdline => console=ttyO0,115200n8 video=HDMI-A-1:1024x768 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd *Good HDMI cable, validated with stock Angstrom & Ubuntu image; GUI works fine with these images *Debian configuration tested on separate TV monitor works fine - boots to GUI *VNC to Debian display GUI - no problem *Observation / Issue* *Boot process looks normal, Linux Penguin displays; proceeds to display *"The IP Address for eth0 " displays login prompt; auto login continues, screen goes blank and then after about 5 seconds the screen goes into power save mode. *Selecting tty2, the screen exists from power save mode and shows login prompt *Returning to tty7 the screen is blank and then returns to power save mode *echo 0 > /sys/class/graphics/fb0/blank has no impact (as root) *Pulled the EDID info following http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI and tried different resolutions with no change in the observations noted above. Finally, after many tests, google-ing, re-flashing, trying to understand the systemd/init.d/start process (still confused about how the boot process works) , I found some hints here; http://archlinuxarm.org/forum/viewtopic.php?f=28&t=5780 In the end, I (*waning => I am a beginner so use this at your own risk*) sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup sudo apt-get install xserver-xorg-video-fbdev sudo reboot and I have the LDE desktop !!! I'm noticing some errors in /var/logs/Xorg.0.log related to FBDEV(0): FBIOPUTCMAP: Invalid argument ,but I'll leave that for another day. cheers On 22 March 2014 13:38, wrote: > On 20/03/14 15:56, Robert Nelson wrote: > > > bootup (wicd seems to take a good 5-15 seconds to get a valid ip > > address over dhcp, conman is slightly faster). > > > > You can see the ethernet driver taking it's sweet time over dmesg: > > > > [ 29.139188] net eth0: initializing cpsw version 1.12 (0) > > [ 29.142439] net eth0: phy found : id is : 0x7c0f1 > > [ 29.142650] libphy: PHY 4a101000.mdio:01 not found > > [ 29.147705] net eth0: phy 4a101000.mdio:01 not found on slave 1 > > [ 29.164068] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 32.222827] libphy: 4a101000.mdio:00 - Link is Up - 100/Full > > [ 32.222962] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > [ 34.697540] net eth0: initializing cpsw version 1.12 (0) > > [ 34.699719] net eth0: phy found : id is : 0x7c0f1 > > [ 34.699817] libphy: PHY 4a101000.mdio:01 not found > > [ 34.705082] net eth0: phy 4a101000.mdio:01 not found on slave 1 > > [ 34.715656] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 35.108521] net eth0: initializing cpsw version 1.12 (0) > > [ 35.110713] net eth0: phy found : id is : 0x7c0f1 > > [ 35.110812] libphy: PHY 4a101000.mdio:01 not found > > [ 35.116039] net eth0: phy 4a101000.mdio:01 not found on slave 1 > > [ 35.126630] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 37.102955] libphy: 4a101000.mdio:00 - Link is Up - 100/Full > > [ 37.103082] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > > > However, if we enable it in [/etc/network/interfaces], the serial > > login prompt will not show up till after eth0 gets a valid ip or the 2 > > minute dhcp time out. So boot times fall from the 12-15 seconds to > > 30ish. > > Something is wrong there, it appears that something is bringing the > link up/down three times. > I think three seconds to get link is a bit long, but I see the same. It's > doing it three times that's costing all the extra time. > > Any possibility of dodgy cable or hardware somewhere ? > > Regardless, DHCP shouldn't block serial console, it should immediately > daemonize and let startup move on. If it doesn't then that's a bug. > > FWIW I see a single cycle of what's in your dmesg like this: > > [5.480948] net eth0: initializing cpsw version 1.12 (0) > [5.557625] net eth0: phy found : id is : 0x7c0f1 > [5.557707] libphy: PHY 4a101000.mdio:01 not found > [5.557716] net eth0: phy 4a101000.mdio:01 not found on slave 1 > [5.564342] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [8.637383] libphy: 4a101000.mdio:00 - Link is Up - 100/Full > [8.637428] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > In context it looks like > > 13:47:40.543 kernel: [4.948036] NET: Registered protocol family 10 > 13:
Re: [beagleboard] Re: [beagleboard-gsoc] Re: Here is the BeagleBone Debian (beta + fixes) image you want to test (2014-03-19)
On 20/03/14 15:56, Robert Nelson wrote: > bootup (wicd seems to take a good 5-15 seconds to get a valid ip > address over dhcp, conman is slightly faster). > > You can see the ethernet driver taking it's sweet time over dmesg: > > [ 29.139188] net eth0: initializing cpsw version 1.12 (0) > [ 29.142439] net eth0: phy found : id is : 0x7c0f1 > [ 29.142650] libphy: PHY 4a101000.mdio:01 not found > [ 29.147705] net eth0: phy 4a101000.mdio:01 not found on slave 1 > [ 29.164068] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 32.222827] libphy: 4a101000.mdio:00 - Link is Up - 100/Full > [ 32.222962] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > [ 34.697540] net eth0: initializing cpsw version 1.12 (0) > [ 34.699719] net eth0: phy found : id is : 0x7c0f1 > [ 34.699817] libphy: PHY 4a101000.mdio:01 not found > [ 34.705082] net eth0: phy 4a101000.mdio:01 not found on slave 1 > [ 34.715656] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 35.108521] net eth0: initializing cpsw version 1.12 (0) > [ 35.110713] net eth0: phy found : id is : 0x7c0f1 > [ 35.110812] libphy: PHY 4a101000.mdio:01 not found > [ 35.116039] net eth0: phy 4a101000.mdio:01 not found on slave 1 > [ 35.126630] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 37.102955] libphy: 4a101000.mdio:00 - Link is Up - 100/Full > [ 37.103082] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > However, if we enable it in [/etc/network/interfaces], the serial > login prompt will not show up till after eth0 gets a valid ip or the 2 > minute dhcp time out. So boot times fall from the 12-15 seconds to > 30ish. Something is wrong there, it appears that something is bringing the link up/down three times. I think three seconds to get link is a bit long, but I see the same. It's doing it three times that's costing all the extra time. Any possibility of dodgy cable or hardware somewhere ? Regardless, DHCP shouldn't block serial console, it should immediately daemonize and let startup move on. If it doesn't then that's a bug. FWIW I see a single cycle of what's in your dmesg like this: [5.480948] net eth0: initializing cpsw version 1.12 (0) [5.557625] net eth0: phy found : id is : 0x7c0f1 [5.557707] libphy: PHY 4a101000.mdio:01 not found [5.557716] net eth0: phy 4a101000.mdio:01 not found on slave 1 [5.564342] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [8.637383] libphy: 4a101000.mdio:00 - Link is Up - 100/Full [8.637428] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready In context it looks like 13:47:40.543 kernel: [4.948036] NET: Registered protocol family 10 13:47:40.543 kernel: [5.024912] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) 13:47:40+00: dhcpcd[131]: version 6.1.0 starting 13:47:40.557 kernel: [5.480948] net eth0: initializing cpsw version 1.12 (0) 13:47:40+00: dhcpcd[131]: forked to background, child pid 135 13:47:40.638 kernel: [5.557625] net eth0: phy found : id is : 0x7c0f1 13:47:40.638 kernel: [5.564342] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready 13:47:40+00: dhcpcd[135]: eth0: waiting for carrier 13:47:40+00: dhcpcd[135]: eth0: carrier acquired 13:47:40+00: dhcpcd[135]: eth0: carrier lost 13:47:40+00: dhcpcd[135]: eth0: waiting for carrier 13:47:40+00: ntpd[143]: ntpd 4.2.6p5@1.2349-o Fri Jan 3 16:05:29 UTC 2014 (1) 13:47:40+00: ntpd[156]: proto: precision = 1.000 usec 13:47:40+00: ntpd[156]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 13:47:40+00: ntpd[156]: Listen normally on 2 lo 127.0.0.1 UDP 123 13:47:40+00: ntpd[156]: peers refreshed 13:47:40+00: ntpd[156]: Listening on routing socket on fd #20 for interface updates 13:47:41+00: sshd[157]: Server listening on 0.0.0.0 port 22. 13:47:41+00: sshd[157]: Server listening on :: port 22. 13:47:43+00: dhcpcd[135]: eth0: carrier acquired 13:47:43.717 kernel: [8.637383] libphy: 4a101000.mdio:00 - Link is Up - 100/Full 13:47:43.717 kernel: [8.637428] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready 13:47:43+00: dhcpcd[135]: eth0: rebinding lease of 172.20.0.21 13:47:43+00: dhcpcd[135]: eth0: leased 172.20.0.21 for 86400 seconds 13:47:43+00: dhcpcd[135]: eth0: adding host route to 172.20.0.21 via 127.0.0.1 13:47:43+00: dhcpcd[135]: eth0: adding route to 172.20.0.0/16 13:47:43+00: dhcpcd[135]: eth0: adding default route via 172.20.255.1 13:47:44+00: ntpd[156]: Listen normally on 4 eth0 172.20.0.21 UDP 123 13:47:44+00: ntpd[156]: peers refreshed and dhcp gets a lease pretty much immediately the link comes up So if it's not a cable or hardware problem causing your link to flap three times then it's a software problem, but that could be in the distro network scripts, wicd or the kernel. Kernel driver seems stable for a while now, so I'd think one of the other two is more likely. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups