Re: [beagleboard] Clock running slow when gpio0[11] pulled high

[chao.ruth via BeagleBoard]

On Thu, 1/5/17, Justin Pearson  wrote:

 Subject: Re: [beagleboard] Clock running slow when gpio0[11] pulled high
 To: beagleboard@googlegroups.com
 Date: Thursday, January 5, 2017, 1:19 AM
 
 Thanks
 Gerald! Did I reference the correct version (CircuitCo's
 GitHub)?
 -Justin
 On Wed, Jan 4, 2017 at 3:15
 PM, Gerald Coley 
 wrote:
 That brings tears to my eyes seeing someone
 quoting the manual.
 Yes,
 don't screw up the SYS_BOOT pins.
 
 Gerald
 
 On Wed, Jan 4, 2017 at 5:12 PM,
 Justin Pearson 
 wrote:
 Expanding
 Chad's comment, in the Beaglebone Black System Reference
 Manual (Rev B, Jan 20, 2014)
 https://github.com/CircuitCo/B
 eagleBone-Black/blob/390c46a03
 e039661aeca6eab22e6c383d8d537f
 8/BBB_SRM.pdf
 "Figure 39. Processor Boot
 Configuration" in "Section 6.8 Default Boot
 Options" says that the top two bits of the SYSBOOT
 register, SYSBOOT[15:14], seem to select which oscillator is
 used (19.2MHz, 24MHz, 25MHz, 26MHz). 
 "Figure 38. Processor Boot
 Configuration Design" shows that SYS_BOOT14 and 15 are
 physically lcd_data14 and 15.
 "Table 12. Expansion Header P8
 Pinout" shows that lcd_data14 and 15 are GPIO0[10] and
 GPIO0[11] in MODE0.
 Section "8.1.1 LCD Pins"
 contains the warning:
 "These pins are also the
 SYSBOOT pins. DO NOT drive them before the SYS_RESETN signal
 goes high. If you do, the board may not boot because you
 would be changing the boot order of the
 processor."
 In
 Fig 39, I see that SYSBOOT[15:14] == 01b results in 24 MHz,
 whereas 11b results in 26MHz, whose 8% difference may
 account for your ~5 sec offset per minute. (If 24MHz is the
 default, I'm not sure.)
 Best,Justin
 
 
 On Wednesday, January 4, 2017 at 5:12:24 AM
 UTC-8, cmbaker3 wrote:
   
 
   
   
 Johan,
 
   That pin is used during the boot operation.
 
   Check in the SRM for the default boot options.
 
   
 
   On 1/4/2017 5:39 AM, Johan Ribenfors wrote:
 
 
 
   We've recently found a
 strange problem.  Repeatable
 across all eleven boards we've tried so far.
 
 
 
 When pin 32 on P8 (gpoi0[11]) is pulled high
 via a resistor
   on boot, the clock on the BBB runs ~7000 seconds
 slow a day.
   (~5 seconds a minute)
 
 
 
 If the pin is pulled low or left floating on
 boot, the
   clock keeps time.
 
 
 
 The device tree overlay was set to 0x37 for
 this pin - fast
   slew, output, pullup, mode 7, but changing this
 has no effect.
 
 
 
 We were using Debian 7.9 with various programs
 installed, a
   few device tree overlays applied and a custom cape
 when we
   noticed this, but it's still the case using
 the Debian 8.6
   image with no modifications, no dto and no
 cape.
 
 
 
 We haven't been able to find anything
 online and don't
   really know where to start looking.
 
 
 
 Any ideas?
   
   -- 
 
   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...@googlegroups.co m.
 
   To view this discussion on the web visit https://groups.google.com/d/ms
 gid/beagleboard/e0647cb0-ac27-
 44ed-a11b-a6f71b7ef077%40googl egroups.com.
 
   For more options, visit https://groups.google.com/d/op
 tout.
 
 
 
 
 
 
 
 -- 
 
   Chad Baker
   Memphis, TN
   
 
 
 
 
 
 -- 
 
 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+unsubscribe@google
 groups.com.
 
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/beagleboard/79bac7d6-3011-
 44b5-95ac-61c43cb8525c%40googl egroups.com.
 
 For more options, visit https://groups.google.com/d/op
 tout.
 
 
 
 
 -- 
 Gerald
  
 ger...@beagleboard.org
 http://beagleboard.org/gcol...@emprodesign.com
 
 
 
 
 
 -- 
 
 For more options, visit http://beagleboard.org/discuss
 
 --- 
 
 You received this message because you are subscribed to a
 topic in the Google Groups "BeagleBoard" group.
 
 To unsubscribe from this topic, visit https://groups.google.com/d/
 topic/beagleboard/mFBxTSWl7Ro/ unsubscribe.
 
 To unsubscribe from this group and all its topics, send an
 email to beagleboard+unsubscribe@
 googlegroups.com.
 
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/beagleboard/CAHK_S%2Bc0% 3DS__LXv5wbF_%
 2B9xP9chLWxErTbCvcxOyejQv8pASZ w%40mail.gmail.com.
 
 For more 

Re: [beagleboard] Re: Do not power BBB/BBG via USB?

[chao.ruth via BeagleBoard]

On Tue, 1/3/17, Micka  wrote:

 Subject: Re: [beagleboard] Re: Do not power BBB/BBG via USB?
 To: beagleboard@googlegroups.com
 Date: Tuesday, January 3, 2017, 12:04 PM
 
 For my use
 case it's perfect:
 the
 board is powered by a cape. we disabled power from USB,
 because the cape is not made to be powered by the
 beagle.
 and yes you
 are right, the PPATH is hard reset to 1.
 Le mar. 3
 janv. 2017 à 10:53, Heinz Hummel 
 a écrit :
 Hello Micka,
 is this permanent? Means does
 the PMIC know even after a power cycle to not to use USB
 power any more? As far as I understood the description of
 USB_EN in the PPATH register, this is reset to default
 values after power was turned off...
 Thanks :-)
 
 2017-01-03 10:48 GMT+01:00 Micka
 :
 The proper way is to
 modify the driver tps65217.c :
 diff --git
 a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.cindex ca19130..a7ae900
 100644---
 a/drivers/mfd/tps65217.c+++
 b/drivers/mfd/tps65217.c@@ -253,6 +253,7 @@ static
 int tps65217_probe(struct i2c_client *client,  bool status_off =
 false; int irq = -1, irq_gpio
 = -1;  int ret;+   bool usb_off =
 false;     node =
 client->dev.of_node;   if (node) {@@ -265,7 +266,8 @@ static
 int tps65217_probe(struct i2c_client *client,  chip_id = (unsigned
 long)match->data;  status_off =
 of_property_read_bool(node,    
"ti,pmic-shutdown-controller");-+   usb_off =
 of_property_read_bool(node,+                
                      
  "ti,pmic-usb-off");   /* at first try to
 get irq via OF method */   irq =
 irq_of_parse_and_map(node, 0); if (irq <= 0)
 {@@ -346,6 +348,16 @@
 static int tps65217_probe(struct i2c_client
 *client,   dev_warn(tps->dev,
 "unable to set the status OFF\n"); } + if(usb_off){+   ret =
 tps65217_set_bits(tps, TPS65217_REG_PPATH,+                
                TPS65217_PPATH_USB_PW_ENABLE,
 0,+                
                TPS65217_PROTECT_NONE);+              
  if (ret)+                
        dev_warn(tps->dev, "unable to set the USB
 power OFF\n");+else+   dev_info(tps->dev,
 "set the USB power OFF\n");+   }+  dev_info(tps->dev,
 "TPS65217 ID %#x version 1.%d\n",  (version &
 TPS65217_CHIPID_CHIP_MASK) >> 4,   version &
 TPS65217_CHIPID_REV_MASK);
 
 
 It worked for me. ( the source is
 not committed yet because I didn't clean the code
 )
 
 Le lun. 2 janv. 2017
 à 08:29, Heinz Hummel 
 a écrit :
 Great - thanks! So there
 is no way to do that programmatically via PMIC?
 2016-12-29 8:59 GMT+01:00 Alex
 Hayman :
 If you cut that trace on a
 BBB, then the BBB won't power itself up via USB.
 
 On Friday, December 23, 2016 at
 4:25:08 AM UTC-5, Heinz Hummel wrote:Hello,
 I have a BBB which is currently
 powered via USB and external power supply (and a similar BBG
 which is powered via USB and via external supply feed into
 VDD from connected cape).
 Now when a user wants to do a full
 power cycle, all possible power sources have to be
 disconnected which can be somewhat complicated.
 So my question: is there a
 possibility to disable power supply via USB? E.g. a
 soldering jumper which has to be opened? Or in case not - is
 there a possibility to permanently program the PMIC to not
 to power the board from USB?
 Thanks!
 
 
 
 
 -- 
 
 For more options, visit http://beagleboard.org/discuss
 
 --- 
 
 You received this message because you are subscribed to a
 topic in the Google Groups "BeagleBoard" group.
 
 To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/dR_GhlwG0eM/unsubscribe.
 
 To unsubscribe from this group and all its topics, send an
 email to beagleboard+unsubscr...@googlegroups.com.
 
 To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5d9e2fb6-14be-4223-9375-2882df001000%40googlegroups.com.
 
 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 beagleboard+unsubscr...@googlegroups.com.
 
 To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHptrU72B91wEm10m1A1GhP0w8Zug-snhgJiKd1z9aCgeg504w%40mail.gmail.com.
 
 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 a
 topic in the Google Groups "BeagleBoard" group.
 
 To unsubscribe from this topic, visit 

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[chao.ruth via BeagleBoard]

On Thu, 12/29/16, William Hermans  wrote:

 Subject: Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE 
HUNGRY) ;)
 To: beagleboard@googlegroups.com, "Robert Nelson" 
 Date: Thursday, December 29, 2016, 1:27 AM
 
 Anyway, this is
 pretty slick. How long do you figure it'll take before
 this functionality come into the default uboot ?
 
 On Wed, Dec 28, 2016
 at 9:36 AM, William Hermans 
 wrote:
 Robert,
 
 Have you created a script that removes all the
 unnecessary kernel modules loaded superfluously at boot ? I
 mean there are a lot of them, and I'd say that 99% of
 them in most cases will just be wasting a lot of memory . .
 .
 
 On Wed, Dec 28, 2016
 at 9:34 AM, William Hermans 
 wrote:
 Ok so from a fresh emmc flashing( slightly
 modified rootfs on the flasher image)
 
 debian@beaglebone:~$ rm /uEnv.txt
 rm: cannot remove '/uEnv.txt': No such file or
 directory
 
 debian@beaglebone:~$ sudo apt-get update
 debian@beaglebone:~$ sudo apt-get install git
 
 debian@beaglebone:~$ cd
 /opt/scripts/tools/developers/
 debian@beaglebone:/opt/scripts /tools/developers$ git
 pull
 debian@beaglebone:/opt/scripts /tools/developers$
 sudo ./update_bootloader.sh --use-beta-bootloader
 debian@beaglebone:/opt/scripts /tools/developers$
 sudo reboot
 
 U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21
 -0600), Build: jenkins-github_Bootloader-Buil der-493
 
 debian@beaglebone:~$ sudo nano /boot/uEnv.txt
     ##BeagleBone Black: HDMI (Audio/Video) disabled:
     dtb=am335x-boneblack-emmc-over lay.dtb
     dtb_overlay=/lib/firmware/BB-W 1-P8.26-00A0.dtbo
 
     cmdline=coherent_pool=1M quiet
 
 debian@beaglebone:~$ sudo reboot
 debian@beaglebone:~$ cat
 /sys/bus/w1/devices/28-064 7ddf6/w1_slave
 0b 01 4b 46 7f ff 05 10 a8 : crc=a8 YES
 0b 01 4b 46 7f ff 05 10 a8 t=16687
 
 
 One minor thing of concern - "evm" :
 
 Are you 100%
 sure, on selecting [am335x_evm] (y/n)? y
 log: dd if=/tmp/tmp.HPy1G6iV9J/dl/MLO-
 am335x_evm-v2017.01-rc2-r4 of=/dev/mmcblk0 seek=1 bs=128k
 0+1 records in
 0+1 records out
 68504 bytes (69 kB) copied, 0.00287351 s, 23.8 MB/s
 log: dd if=/tmp/tmp.HPy1G6iV9J/dl/u-bo
 ot-am335x_evm-v2017.01-rc2-r4. img of=/dev/mmcblk0 seek=1
 bs=384k
 
 
 On Wed, Dec 28, 2016
 at 8:52 AM, William Hermans 
 wrote:
 Well, I'm not sure why I should be testing
 then. I do not have an LCD cape, and probably never will.
 But I figured I could test my custom cape at boot *AFTER* I
 get something like 1-wire to load at boot. e.g. the is
 infinitely easier to test, and something I could also test
 in hardware right away.
 
 On Wed, Dec 28, 2016
 at 8:27 AM, Robert Nelson 
 wrote:
 On
 Wed, Dec 28, 2016 at 9:25 AM, William Hermans 
 wrote:
 
 > On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson 
 
 > wrote:
 
 >>
 
 >> On Wed, Dec 28, 2016 at 9:10 AM, William Hermans
 
 
 >> wrote:
 
 >> > So what you're telling me that testing for
 different boards is
 
 >> > irrelevant ?
 
 >>
 
 >> That is correct.  This feature has been enabled in
 our version of
 
 >> u-boot since last October or so...  So we know
 those boards work.
 
 >>
 
 >> Just finally figured out the missing piece to
 actually load an overlay
 
 >> on top of the main dtb..
 
 >
 
 >
 
 > sweet. Do tell ;)
 
 
 
 "fdt resize"
 
 
 
 Regards,
 
 
 
 --
 
 Robert Nelson
 
 https://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 beagleboard+unsubscribe@google
 groups.com.
 
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/beagleboard/CAOCHtYgemJazx
 %3Dg2qndYNmGF%2BPs%2BK%3DAE47_
 Z6Vv6H03kYJO%3D6A%40mail.gmail .com.
 
 For
 more options, visit https://groups.google.com/d/op
 tout.
 
 
 
 
 
 
 
 
 
 
 
 
 -- 
 
 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.
 
 To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpa-OLfZLFc1nshG541EBqfCtGX%3DT7J5DgHY1-pnmY4Bw%40mail.gmail.com.
 
 For more options, visit https://groups.google.com/d/optout.
 sistenta unui popor insa nu se discuta se afirma

-- 
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.
To view