On Wed, Sep 3, 2014 at 4:20 PM, Robert Nelson <[email protected]> wrote: > On Wed, Sep 3, 2014 at 1:51 PM, Jason Kridner <[email protected]> > wrote: >> Started some testing of the latest 3.14 build >> (http://builds.beagleboard.org/builders/runtests/builds/27) today. >> >> I found the 8-19 image from >> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian seemed to require >> me to copy a bbb-uEnv.txt file to uEnv.txt on the FAT partition to >> make it boot from the microSD card. Seems to me that should be the >> default. > > It became the default after 8-19.. > >> >> Install with 'dpkg -i XXX.deb' and reboot was pretty easy. >> >> Got an oops on mmcblk0 (microSD) (http://paste.debian.net/119196/): >> [ 5479.495347] mmcqd/0: page allocation failure: order:1, >> mode:0x204020 [ 5479.495395] CPU: 0 PID: 43 Comm: mmcqd/0 Not tainted >> 3.14.17-git302cf583bc3db28305d83071e50c957354e3111a #2 [ 5479.495458] >> [<c0015cf0>] (unwind_backtrace) from [<c00128d0>] >> (show_stack+0x10/0x14) [ 5479.495490] [<c00128d0>] (show_stack) from >> [<c0762bb4>] (dump_stack+0x68/0x84) [ 5479.495526] [<c0762bb4>] >> (dump_stack) from [<c00ea768>] (warn_alloc_failed+0xcc/0x10c) [ >> 5479.495555] [<c00ea768>] (warn_alloc_failed) from [<c00ed7cc>] >> (__alloc_pages_nodemask+0x7bc/0x960) [ 5479.495583] [<c00ed7cc>] >> (__alloc_pages_nodemask) from [<c011f0fc>] >> (cache_alloc_refill+0x358/0x58c) [ 5479.495605] [<c011f0fc>] >> (cache_alloc_refill) from [<c011f5cc>] (__kmalloc+0x104/0x198) [ >> 5479.495642] [<c011f5cc>] (__kmalloc) from [<c045ee14>] >> (edma_prep_slave_sg+0x98/0x2d4) [ 5479.495674] [<c045ee14>] >> (edma_prep_slave_sg) from [<c06099d8>] >> (omap_hsmmc_request+0x3e4/0x4d8) [ 5479.495710] [<c06099d8>] >> (omap_hsmmc_request) from [<c05f3b24>] (mmc_start_request+0x128/0x250) >> [ 5479.495737] [<c05f3b24>] (mmc_start_request) from [<c05f4bc4>] >> (mmc_start_req+0x170/0x32c) [ 5479.495774] [<c05f4bc4>] >> (mmc_start_req) from [<c06021c8>] (mmc_blk_issue_rw_rq+0xc0/0xae8) [ >> 5479.495800] [<c06021c8>] (mmc_blk_issue_rw_rq) from [<c0602e20>] >> (mmc_blk_issue_rq+0x230/0x4d8) [ 5479.495825] [<c0602e20>] >> (mmc_blk_issue_rq) from [<c06041e4>] (mmc_queue_thread+0x9c/0x13c) [ >> 5479.495855] [<c06041e4>] (mmc_queue_thread) from [<c005fb20>] >> (kthread+0xd0/0xf0) [ 5479.495880] [<c005fb20>] (kthread) from >> [<c000eea8>] (ret_from_fork+0x14/0x2c) > > Weird, it comes up clean: > > http://pastebin.com/vDc3VfSx > >> Also, I have an Ethernet cable connected and that came up fine, but >> the usb0 interface doesn't show up: > > This is the "console" right? That doesn't do anything fancy, it just > boots with a very clean image. As that is what those users wanted.. > >> >> root@beaglebone:~# ifconfig >> eth0 Link encap:Ethernet HWaddr 90:59:af:69:c0:42 >> inet addr:192.168.2.138 Bcast:192.168.2.255 Mask:255.255.255.0 >> inet6 addr: fe80::9259:afff:fe69:c042/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:513522 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:109359 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:690469697 (658.4 MiB) TX bytes:15468479 (14.7 MiB) >> Interrupt:56 >> >> lo Link encap:Local Loopback >> inet addr:127.0.0.1 Mask:255.0.0.0 >> inet6 addr: ::1/128 Scope:Host >> UP LOOPBACK RUNNING MTU:65536 Metric:1 >> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:0 >> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) >> >> Hacking with cape-universal using dtb-builder right now. Another ugly >> side-effect I'm seeing is that one of the pins seems to be driven, >> despite me not setting it up as anything. I'm going to try to address >> this in the dtb.
P9_42 is lighting up on microSD card activity at similar times to the USR1 LED. I believe P9_42 is connected to balls C18 and B12 per the SRM and schematic and that those refer to offsets 0x164 and 0x1a0 respectively. /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins: pin 89 (44e10964.0): (MUX UNCLAIMED) (GPIO UNCLAIMED) pin 104 (44e109a0.0): 48060000.mmc (GPIO UNCLAIMED) function pinmux_mmc1_pins_sleep group pinmux_mmc1_pins_sleep /sys/kernel/debug/pinctrl/44e10800.pinmux/pins: pin 89 (44e10964.0) 00000027 pinctrl-single pin 104 (44e109a0.0) 00000027 pinctrl-single I don't know why it is allocated for the MMC and I don't see anywhere it is physically connected, so I'm assuming this is somehow enabled in this mmc function, but I don't know what the driver believes it to be. The device tree assignment doesn't seem to indicate what pin is considered to be what function: pinctrl-single,pins = < 0x0F0 (PIN_INPUT_PULLDOWN | MUX_MODE7) 0x0F4 (PIN_INPUT_PULLDOWN | MUX_MODE7) 0x0F8 (PIN_INPUT_PULLDOWN | MUX_MODE7) 0x0FC (PIN_INPUT_PULLDOWN | MUX_MODE7) 0x100 (PIN_INPUT_PULLDOWN | MUX_MODE7) 0x104 (PIN_INPUT_PULLDOWN | MUX_MODE7) 0x1A0 (PIN_INPUT_PULLDOWN | MUX_MODE7) 0x160 (PIN_INPUT_PULLDOWN | MUX_MODE7) >; Also, can you explain how you envision different peripherals being turned on with the current overlays? I still don't see how to use the configurations you've set and http://elinux.org/Beagleboard:Capes_3.8_to_3.14 doesn't explain it either. > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.com/ > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
