Re: [beagleboard] Re: BIG problem with BBB and logging into ANY username

[jonnymo]

I was able to use PuTTY on Windows 10 to login to the BBB via serial
without root password after editing the /etc/passwd file.  Typically the
root account is set in the sshd_config to not allow remote ssh connections
to a Linux system.  You have to set this to allow for root login with or
without a password.
https://linuxconfig.org/enable-ssh-root-login-on-debian-linux-server

Jon

On Thu, Apr 1, 2021 at 8:50 AM amf  wrote:

> I'm going out on the limb here, but putty seem to have an issue with
> logins without a password. I'm sure some one can provide more input on this.
>
> On Wednesday, March 31, 2021 at 12:59:59 PM UTC-5 propg...@gmail.com
> wrote:
>
>>
>> debian@beaglebone:/mnt/media/etc$ su root
>> Password:
>> su: Authentication failure
>> debian@beaglebone:/mnt/media/etc$ su root
>> Password:
>> su: Authentication failure
>> debian@beaglebone:/mnt/media/etc$ sudo nano shadow
>>   GNU nano 2.7.4 File: shadow
>>
>> root::18717:0:9:7:::
>> daemon:*:18112:0:9:7:::
>> bin:*:18112:0:9:7:::
>> sys:*:18112:0:9:7:::
>> sync:*:18112:0:9:7:::
>> games:*:18112:0:9:7:::
>> man:*:18112:0:9:7:::
>> lp:*:18112:0:9:7:::
>> mail:*:18112:0:9:7:::
>> news:*:18112:0:9:7:::
>> uucp:*:18112:0:9:7:::
>> proxy:*:18112:0:9:7:::
>> www-data:*:18112:0:9:7:::
>> backup:*:18112:0:9:7:::
>> list:*:18112:0:9:7:::
>> irc:*:18112:0:9:7:::
>> gnats:*:18112:0:9:7:::
>> nobody:*:18112:0:9:7:::
>> systemd-timesync:*:18112:0:9:7:::
>> systemd-network:*:18112:0:9:7:::
>> systemd-resolve:*:18112:0:9:7:::
>> systemd-bus-proxy:*:18112:0:9:7:::
>> _apt:*:18112:0:9:7:::
>> dnsmasq:*:18112:0:9:7:::
>> messagebus:*:18112:0:9:7:::
>> avahi:*:18112:0:9:7:::
>> sshd:*:18112:0:9:7:::
>> usbmux:*:18112:0:9:7:::
>> lightdm:*:18112:0:9:7:::
>> debian:rcdjoac1gVi9g:18112:0:9:7:::
>> bob::18717:0:9:7:::
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>[ Read 31 lines ]
>> ^G Get Help ^O Write Out^W Where Is ^K Cut Text ^J
>> Justify  ^C Cur Pos  ^Y Prev PageM-\ First Line
>> ^X Exit ^R Read File^\ Replace  ^U Uncut Text   ^T To
>> Spell ^_ Go To Line   ^V Next PageM-/ Last Line
>>
>> On Wed, Mar 31, 2021 at 10:23 AM Bob Hammond  wrote:
>>
>>> Well, I thought it worked great but it doesn't.
>>>
>>> I applied all these commands to the BBB in question and specifically to
>>> the root password entry but I am still unable to get into it.
>>> When I attempt to log in with root, and enter a null password, I still
>>> get "access denied".  Same with all other usernames and passwords.
>>>
>>> Could it be a file permissions problem?
>>>
>>> On Wed, Mar 31, 2021 at 9:10 AM Bob Hammond  wrote:
>>>
 amf,

 THIS works great!  Thanks so much for the help.

 On Tue, Mar 30, 2021 at 8:52 AM amf  wrote:

> If you just want to reset the password on the new imaged BBB (this
> does not explain why you had issue in the first place, but does allow you
> to access the system)
> clear the encrypted password as follows, (if you need detailed steps
> let me know)
> create a sdcard with a new image (one you download) and boot the BBB
> with it.
> then mount the emmc device
> edit /etc/shadow file in the mounted emmc device (requires sudo)
> find the user name you want to remove the password on
> for example, my user name is 'amf'
> amf:$6$jlBY96dq$V7tFs2xEv.a3kXArkyTEcEbGDX43d6UpzMcy/aplV8khxUFJKPMg0ugGBfWVZMpJRpaMXAATEAb5inu7/G.Iz1:16406:0:9:7:::
>
> delete the stuff between the first two '::'
> pi::16406:0:9:7:::
> save the shadow file
> power off the BBB
> remove sdcard, and power on the BBB
> log in with the user name that the encrypted password was deleted on,
> no login password is required, then set new password for the user.
>
> Hope this helps.
> amf
> On Tuesday, March 30, 2021 at 9:02:25 AM UTC-5 propg...@gmail.com
> wrote:
>
>> I am now attempting to get into GRUB during boot.  I never see a GRUB
>> menu show up by pressing/holding ESC or left shift.  What I do see is 
>> that
>> I can interrupt boot by pressing the spacebar.  I then get a command 
>> prompt
>> in ??.  And I have no idea what to do after that.
>>
>> On Monday, March 29, 2021 at 6:27:52 AM UTC-7 Bob Hammond wrote:
>>
>>> Thanks Andrea.  Once I get in, I will check the logs.  The sshd is
>>> likely up as you state.  The BBB is protected by a firewall on my 
>>> router as
>>> well as iptables.  And no, I didn't have enforced sshd to accept only 
>>> user
>>> connection.
>>>
>>> All very good ideas!
>>>
>>>
>>> On Sunday, March 28, 2021 at 6:05:22 AM UTC-7 andrea@gmail.com
>>> wrote:
>>>
 I found this for the serial 

Re: [beagleboard] Re: BIG problem with BBB and logging into ANY username

[amf]

I'm going out on the limb here, but putty seem to have an issue with logins 
without a password. I'm sure some one can provide more input on this.

On Wednesday, March 31, 2021 at 12:59:59 PM UTC-5 propg...@gmail.com wrote:

>
> debian@beaglebone:/mnt/media/etc$ su root
> Password:
> su: Authentication failure
> debian@beaglebone:/mnt/media/etc$ su root
> Password:
> su: Authentication failure
> debian@beaglebone:/mnt/media/etc$ sudo nano shadow
>   GNU nano 2.7.4 File: shadow
>
> root::18717:0:9:7:::
> daemon:*:18112:0:9:7:::
> bin:*:18112:0:9:7:::
> sys:*:18112:0:9:7:::
> sync:*:18112:0:9:7:::
> games:*:18112:0:9:7:::
> man:*:18112:0:9:7:::
> lp:*:18112:0:9:7:::
> mail:*:18112:0:9:7:::
> news:*:18112:0:9:7:::
> uucp:*:18112:0:9:7:::
> proxy:*:18112:0:9:7:::
> www-data:*:18112:0:9:7:::
> backup:*:18112:0:9:7:::
> list:*:18112:0:9:7:::
> irc:*:18112:0:9:7:::
> gnats:*:18112:0:9:7:::
> nobody:*:18112:0:9:7:::
> systemd-timesync:*:18112:0:9:7:::
> systemd-network:*:18112:0:9:7:::
> systemd-resolve:*:18112:0:9:7:::
> systemd-bus-proxy:*:18112:0:9:7:::
> _apt:*:18112:0:9:7:::
> dnsmasq:*:18112:0:9:7:::
> messagebus:*:18112:0:9:7:::
> avahi:*:18112:0:9:7:::
> sshd:*:18112:0:9:7:::
> usbmux:*:18112:0:9:7:::
> lightdm:*:18112:0:9:7:::
> debian:rcdjoac1gVi9g:18112:0:9:7:::
> bob::18717:0:9:7:::
>
>
>
>
>
>
>
>
>
>
>[ Read 31 lines ]
> ^G Get Help ^O Write Out^W Where Is ^K Cut Text ^J Justify 
>  ^C Cur Pos  ^Y Prev PageM-\ First Line
> ^X Exit ^R Read File^\ Replace  ^U Uncut Text   ^T To 
> Spell ^_ Go To Line   ^V Next PageM-/ Last Line
>
> On Wed, Mar 31, 2021 at 10:23 AM Bob Hammond  wrote:
>
>> Well, I thought it worked great but it doesn't.
>>
>> I applied all these commands to the BBB in question and specifically to 
>> the root password entry but I am still unable to get into it.
>> When I attempt to log in with root, and enter a null password, I still 
>> get "access denied".  Same with all other usernames and passwords.
>>
>> Could it be a file permissions problem?
>>
>> On Wed, Mar 31, 2021 at 9:10 AM Bob Hammond  wrote:
>>
>>> amf,
>>>
>>> THIS works great!  Thanks so much for the help.
>>>
>>> On Tue, Mar 30, 2021 at 8:52 AM amf  wrote:
>>>
 If you just want to reset the password on the new imaged BBB (this does 
 not explain why you had issue in the first place, but does allow you to 
 access the system)
 clear the encrypted password as follows, (if you need detailed steps 
 let me know)
 create a sdcard with a new image (one you download) and boot the BBB 
 with it.
 then mount the emmc device 
 edit /etc/shadow file in the mounted emmc device (requires sudo)
 find the user name you want to remove the password on 
 for example, my user name is 'amf'
 amf:$6$jlBY96dq$V7tFs2xEv.a3kXArkyTEcEbGDX43d6UpzMcy/aplV8khxUFJKPMg0ugGBfWVZMpJRpaMXAATEAb5inu7/G.Iz1:16406:0:9:7:::
  

 delete the stuff between the first two '::' 
 pi::16406:0:9:7:::
 save the shadow file
 power off the BBB
 remove sdcard, and power on the BBB
 log in with the user name that the encrypted password was deleted on, 
 no login password is required, then set new password for the user.

 Hope this helps.
 amf
 On Tuesday, March 30, 2021 at 9:02:25 AM UTC-5 propg...@gmail.com 
 wrote:

> I am now attempting to get into GRUB during boot.  I never see a GRUB 
> menu show up by pressing/holding ESC or left shift.  What I do see is 
> that 
> I can interrupt boot by pressing the spacebar.  I then get a command 
> prompt 
> in ??.  And I have no idea what to do after that.
>
> On Monday, March 29, 2021 at 6:27:52 AM UTC-7 Bob Hammond wrote:
>
>> Thanks Andrea.  Once I get in, I will check the logs.  The sshd is 
>> likely up as you state.  The BBB is protected by a firewall on my router 
>> as 
>> well as iptables.  And no, I didn't have enforced sshd to accept only 
>> user 
>> connection.
>>
>> All very good ideas!
>>
>>
>> On Sunday, March 28, 2021 at 6:05:22 AM UTC-7 andrea@gmail.com 
>> wrote:
>>
>>> I found this for the serial connection.
>>>
>>>
>>> https://www.dummies.com/computers/beaglebone/how-to-connect-the-beaglebone-black-via-serial-over-usb/
>>>
>>> Some ideas :
>>> Once in as root, I would 
>>> - change the root password :
>>> # passwd
>>> - The user password:
>>> # passwd username
>>> Check the logs focus in the time you had attempted the remote login 
>>> - find why it was not allowed to login.
>>> Check the sshd service is enabled  (however should be up) 
>>> Have you hardened your 

[beagleboard] Re: GPIO from PRU via OCP on a Beaglebone Black - Timing Issues

[Remy Porter]

I've been playing with building my own kernel, which I *did* get 
cross-compilation working, even with the bindeb-pkg target, which is cool. 
The weird sideeffect of trying and disabling various bits and modules is 
that… the PRU cycle counter stops working. I have no idea how or why that 
happens, but if I use my own kernel, ensure that all the appropriate 
modules are loaded, bupkiss. I suspect I have the same problem with the FPP 
kernel (I threw that on, tried running my software, saw it didn't work, and 
just went to work making my own, but didn't dig into the root cause, just 
chalking it up as an incompatibility).

So yeah, playing with the cpufrequtils is probably going to be the next 
thing to try. Thanks again!

On Friday, March 26, 2021 at 10:04:52 AM UTC-4 d...@kulp.com wrote:

> One more thing you can try with the TI kernel if your kernel build has 
> issues:
>
> The biggest problem is the CPU going in and out of idle states.   Thus, 
> you can install the cpufrequtils and linux-cpupower packages and then at 
> boot run:
>
> cpufreq-set -g performance
> cpupower idle-set -d 1
>
> (and maybe cpupower idle-set -d 0 )
>
> The first will lock the cpu freq at 1Ghz.   The second will disable the 
> very costly idle states in the processor.   I believe the M3 processor in 
> the L4_WAKEUP is in charge of the power management stuff which includes the 
> CPU idle settings.   Flipping the CPU out of idle seems to take a long time 
> and blocks the bus while it waits.   Disabling that state helped a lot.
> Alternatively, you can install the "bone" kernel which doesn't have the 
> idle driver (or at least didn't early last year, not sure anymore).  
>  Anyway, those had a huge impact, but still wasn't 100% which is why we 
> decided to compile our own kernel completely disabling everything on the 
> L4-WAKEUP.
>
>
> Dan
>
>
> On Thursday, March 25, 2021 at 3:01:56 PM UTC-4 Remy Porter wrote:
>
>> > Personal plug:  I'd be happy to sell capes that don't use gpio0.  
>> https://kulplights.com
>> Heh, we've already got all the boards for this project. Maybe we'll 
>> revisit that design in future projects, though. 
>>
>> Your software is definitely doing a *lot* more than ours, and certainly 
>> much more than we need- we just listen for RGB data on a UDP socket. We, 
>> uh… don't really treat them like lights, and instead as very large pixels 
>> in a screen. All the mapping/direction/orientation stuff is handled in the 
>> render stack, which we build custom for pretty much every project. Last one 
>> was a Unity App that was part of a kiosk connected to a gigantic 
>> chandelier. Our current project is *kinda* like an architectural scale 
>> video wall with a C++/OpenCV app driving the pixels.
>>
>> I might give the FPP image a shot though, if building my own custom 
>> kernel doesn't help. Your guidance on that was *super* helpful, though 
>> your FPP kernel did *not* get along with our software (LEDs just didn't 
>> work- in lieu of diagnosing that, I just opted to compile my own, which is 
>> going on… right now).  Thanks a bunch!
>>
>> On Tuesday, March 23, 2021 at 4:17:37 PM UTC-4 d...@kulp.com wrote:
>>
>>> The debs for the kernel are at:
>>> https://github.com/FalconChristmas/fpp-linux-kernel/tree/master/debs
>>> do you should be able to update to our kernel fairly easy.If you 
>>> need to start building your own kernel, I'd suggest grabbing a Beaglebone 
>>> AI and building on that.   It's WAY faster for kernel building.  :).You 
>>> can cross-compile from a debian x86_64, but I was never able to get that to 
>>> actually produce proper .deb files that could be installed cleanly on the 
>>> BBB so I pretty much just use the AI for kernel builds.  (It's actually the 
>>> ONLY thing I use my AI for.)
>>>
>>> FPP provides a complete UI frontend for configuring the pixel strings 
>>> and such and we do allow the various 4 channel types. It does a lot of 
>>> other things as well.   That said, most of these things are done on the ARM 
>>> side and not the PRU.  Part of trying to figure out the latency issue was 
>>> seeing what make sense to do on the arm side and what works best on the PRU 
>>> side.If you actually wanted to try FPP and see if FPP's optimized PRU 
>>> code and kernel combination would work, you could use the FPP 4.6.1 image 
>>> on an SD card (see the release assets at github).   You would just need to 
>>> create a small json file in /opt/fpp/capes/bbb/strings to describe the 
>>> pinout of your cape (use any of them in that directory as a starting point) 
>>> and it should then "just work".  You would need to configure e1.31/artnet 
>>> input universes on the Channel Input tab, put FPP in "bridge" mode, and 
>>> then it should work like a normal light controller and accept pixel data.  
>>>  (Or use DDP protocol which doesn't require configuring the input)
>>>
>>> Personal plug:  I'd be happy to sell capes that don't use gpio0.  
>>> https://kulplights.com 

Re: [beagleboard] Re: eCAP reading a PWM signal, someone has made this functionality works?

[TJF]

Drew Fustini schrieb am Mittwoch, 31. März 2021 um 22:29:35 UTC+2:

> To clarify for anyone finding this thread in the future. 
>
> eQEP (encoder input) driver is in mainline Linux kernel thanks to David 
> Lechner: 
> https://elixir.bootlin.com/linux/latest/source/drivers/counter/ti-eqep.c 
>
> eCAP (pulse input) driver is available as patch posted by Darren 
> Schachter that is known to work: 
> https://lore.kernel.org/linux-iio/2020081815361...@cornell.edu/ 
>  
>

... and - to be complete - that proven eCAP + eQEP features - well 
documented (including example code) and with similar programming interfaces 
(not changing in new kernels) - are available in libpruio since years at
https://github.com/DTJF/libpruio 

-- 
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/8363327c-b775-4f61-a704-caeaf5126eedn%40googlegroups.com.