<set_>
I am saving up for another one. I have this fun sized, 18" of movement slide w/ screw that will be dancing soon enough!
renrelkha_ has joined #beagle
renrelkha has quit [Ping timeout: 240 seconds]
<set_>
I know it is just by way of USB and not RSxxx but it works. I am happy again!
M-blaise has joined #beagle
argonautx has joined #beagle
akaWolf has quit [Ping timeout: 248 seconds]
akaWolf has joined #beagle
Guest14 has joined #beagle
<Guest14>
hi all,
<Guest14>
I need an help for mount an OS into beaglebone Black. i download the image AM3358 Debian 10.3 2020-04-06 1GB SD console. then i extract using 7-zip software. after that using win32 Disk Imager i flash the img into microSD card.
<Guest14>
then MicroSD inserted into beaglebone black. by contineous holding down the S2(boot up switch)switch i power up the board using 5V adapter.
<set_>
Use balena.etcher instead of 7-zip and win Disk.
<Guest14>
NOthing happening after that. that is OS not flashing into eMMC. what could be the reason. any one pls help me am fresher in this.
<set_>
Oh! Maybe you have a SD Card image and not a eMMC image?
<Guest14>
Debian console images via microSD card (without flashing the eMMC). this one i downloaded
<set_>
Let me go and see!
<set_>
Right.
<set_>
So, that one, does not flash the eMMC. It is for SD Card use.
<set_>
But!
<set_>
I think there is a /boot/uEnv.txt file w/ a line to uncomment that will help.
<set_>
Let me boot mine and see if I can track down this line in the /boot/uEnv.txt file.
<Guest14>
even i can't see the flashing is happening like back and front sequecial movement of led blink
<set_>
Oh.
<set_>
How are you powering the BBB?
<Guest14>
5V 1A adapter
<set_>
Do you have the USB attached?
<Guest14>
usb from pc to BBB?
<set_>
Yes sir.
<Guest14>
yes. i tried not. seems like same
<Guest14>
so i brought adapter
<set_>
I say use the USB to install the image. On my side, it never has failed me.
<Guest14>
ok
<Guest14>
i will try
<set_>
So, hold the S2 button too.
<set_>
When you are booting or powering on the device, make sure you are holding the S2 button the backend of the board.
<set_>
Then, when all LEDs are lit, let go. Hmm.
buzzmarshall has joined #beagle
<Guest14>
ok
<set_>
Try that please and return service if possible.
<set_>
It is like a really neat puzzle, i.e. these boards. Just when you think you have learned about them, BAM, something new!
<set_>
For instance, I just noticed on one of my boards, BBB family of boards, there are four holes in the board.
<set_>
It may take a long time to figure it out but I have time.
<set_>
Guest14: I am sorry. I have to go. Something has come up. I am sure if you listen to this site, https://beagleboard.org/getting-started, and use the /boot/uEnv.txt file to update to the eMMC instead of using the SD Card, it will work.
<set_>
Later Gator!
<zmatt>
Guest14: you said you downloaded the non-flasher image, so why are you surprised it doesn't flash?
<zmatt>
there are flasher and non-flasher images available, the former will automatically erase and reflash eMMC, and latter will simply boot from SD card
<zmatt>
(it's also not too hard to convert a non-flasher image into a flasher image)
set_ has quit [Ping timeout: 245 seconds]
<zmatt>
Guest14: note btw that the "console" image is a fairly minimal image intended for experienced linux users who are comfortable with installing whatever packages they need themselves, for new users the "IoT" image is recommended, with includes a bunch of stuff by default
Guest14 has quit [Quit: Client closed]
Guest14 has joined #beagle
dlan has quit [Remote host closed the connection]
dlan has joined #beagle
Guest14 has quit [Quit: Client closed]
rob_w has quit [Quit: Leaving]
vagrantc has joined #beagle
argonautx has quit [Quit: Leaving]
Stanto has joined #beagle
florian has quit [Quit: Ex-Chat]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
mattb0ne has joined #beagle
charlie5 has quit [Read error: Connection reset by peer]
charlie5 has joined #beagle
m-atoms has joined #beagle
Guest46 has joined #beagle
mattb0ne has quit [Ping timeout: 252 seconds]
<Guest46>
hi, I am running ubuntu 18.04 on a beaglebone black rev C, and am trying to figure out how to control the GPIO pins. I found this article on controlling leds via filesystem I/O to the correct folders, and confirmed that it works for the LEDs: http://derekmolloy.ie/beaglebone-controlling-the-on-board-leds-using-c/
mattb0ne has joined #beagle
<Guest46>
Then I used the same process to control some of the GPIOs. I found this documentation saying how to figure out which software gpio name corresponds to which physical pin (pages 4 and 5): https://elinux.org/images/3/33/GPIO_Programming_on_the_Beaglebone.pdf The chart says essentially that GPIOX_Y-->gpioZ in software, where Z=X*32+Y. I was able to
<Guest46>
use this process to succesfully control several GPIO pins. For example, P8.13=GPIO0_23-->gpio23 in software. I measured its output with a multimeter, did echo out > direction for /sys/class/gpio/gpio23, and echo 1 > value.
<Guest46>
But for some reason, this process doesn't work for every GPIO. For example, P8.3=GPIO1_6, so it should be controlled via sys/class/gpio/gpio38, but the same process isn't doing anything to P8.3 for some reason. I even tried writing out > direction and 1 > value to every single available gpio folder in /sys/class/gpio, but none of them affected the
<Guest46>
voltage output of this pin.
<Guest46>
am I doing something wrong? It's weird to me that this process works for some pins but not others
<zmatt>
(it is untested on Ubuntu, which is not an officially supported distro on the beaglebone)
<Guest46>
interesting, so the onboard processor uses some of the GPIO pins?
<Guest46>
eMMC=onboard memory right?
<zmatt>
btw the PDF you linked is for the original BeagleBone (now called BeagleBone White), not the BBB, though the pins are largely the same
<Guest46>
gotcha, good to know
<zmatt>
eMMC is the on-board flash memory yes
<Guest46>
ok, so does that mean that P8.03 and ones similarly "in use" by the eMMC are not changeable by the user?
<zmatt>
and yes, some pins that were freely usable on the expansion headers of the original BeagleBone are used by on-board functionality on the BeagleBone Black
<Guest46>
ok, interesting
<Guest46>
and is there a way around that by reconfiguring the boot config or something that like?
<zmatt>
well you could boot from SD card and disable eMMC in /boot/uEnv.txt which sorta frees up those pins but with a whole bunch of caveats (since the eMMC is still connected to those pins, and is probed during boot)
<Guest46>
or if it's tied up by the eMMC is it just game over for using that pin?
<zmatt>
(the other on-board functionality of the BBB that occupies expansion header pins, such as video, can simply be disabled in /boot/uEnv.txt which frees up those pins)
<Guest46>
ok, so possibly can use them if booting from an SD card, but can't control them during boot?
<Guest46>
but if booting from eMMC then those pins are inaccessible to the user?
<zmatt>
when booting from eMMC those pins are indeed inaccessible, ditto when booting from SD card if you haven't explicitly disabled eMMC via /boot/uEnv.txt
<Guest46>
gotcha
<Guest46>
ok, I guess we'll either have to boot from SD card and disable eMMC, or find other pins to use then
<Guest46>
thanks!
<zmatt>
but if you choose to do that and reuse those pins, keep in mind:
<Guest46>
why does the eMMC use output pins btw?
<Guest46>
it can't assume they're connected to anything externally right?
<Guest46>
so I'm trying to imagine what it would use them for
<zmatt>
1. there will still be activity on those pins during boot (though this *could* be avoided by customizing u-boot and altering the boot order via sysboot pins)
<Guest46>
ok, that's good to know
<zmatt>
2. you should avoid repurposing both the eMMC clk and eMMC cmd lines at the same time, since if both of these toggle then you're effectively trying to send commands to the eMMC and if by random chance you end up sending a valid command, the eMMC will try to respond (by driving its response onto the cmd line)
<Guest46>
yeah so basically it sounds like it'll be easier if at all possible to just avoid using those eMMC pins
<zmatt>
3. the eMMC lines have external pull-up resistors hence you should not attempt to configure internal pull-down
<zmatt>
yes
<zmatt>
absolutely
<zmatt>
I'd use them only as absolute last resort if you've completely run out of alternative options
<Guest46>
which look like P8.03-.06, and P8.20-25, from your chart?
<Guest46>
ok, that's good to know
<zmatt>
the ones marked in eye-stabbing purple
<zmatt>
magenta I guess
<Guest46>
haha, I like "eye stabbing purple"
<Guest46>
sounds like a band name
<zmatt>
see remarks at the bottom of the P8 sheet I linked to
<Guest46>
ahh
<zmatt>
and I'm not sure what you mean by "why does the eMMC use output pins btw? it can't assume they're connected to anything externally right?"
<Guest46>
I guess I'm just trying to figure out what the eMMC uses the pins for
<Guest46>
since I don't think the GPIO pins are connected to anything unless the user plugs something into the headers right?
<zmatt>
they're literally the signals between cpu and eMMC
<Guest46>
huh
<Guest46>
maybe I'm not understanding how it's wired then
<Guest46>
but that's ok, it's enough to know we can't use them
<zmatt>
if you have one sec I'll sketch it
<Guest46>
sure!
<Guest46>
and ok, just to make sure I have the list of off-limits pins:
<Guest46>
P8.03-.06, P8.20-25, P9.09&P9.10
<Guest46>
?
<Guest46>
I see there's a few others not to mess with during boot, but are these the only ones that are permanently off-limits to the user?
<zmatt>
P9.09-10 are not gpios at all, they're special-purpose pins
<zmatt>
so they're not "off-limits" as such, but they only have specific usage... e.g. some capes that make the BBB's reset and power buttons difficult or impossible to access may add their own buttons that pull those two pins to ground (which is exactly what the BBB's on-board reset and power buttons do)
<zmatt>
as the notes at the bottom say, P8.31-46 have on-board pull resistors on the BBB (specifically 100 kΩ), either up (H*) or down (L*)... these pins are sampled by the processor at power-on-reset (iirc around 20ms after the power led turns on) and are used to determine bootrom configuration until next power-on
<Guest46>
ok, so they can't be used as regular GPIO pins
<Guest46>
but they can be used as reset and power buttons?
<Guest46>
and ok, that sketch makes sense to me
<zmatt>
P8.09-10 are simply not gpios, they don't have gpio numbers
<Guest46>
thanks for drawing that!
<Guest46>
do you mean P9.09-10?
<zmatt>
of course I only drew 4 of the 10 eMMC signals since I was lazy, but you get the point
<zmatt>
P9.09-10 yeah sorry
<Guest46>
yeah I understand now
<Guest46>
and ok, that makes sense about P9.09 and 10
<Guest46>
is this google excel sheet you linked specifically for the beaglebone rev C?
<Guest46>
it looks like it has all the information on which pins we can use for what; I want to give it to my coworker
<zmatt>
originally the intent was that the eMMC could be fully disabled (held in reset) to allow all eMMC pins to be reused (for backwards compatibility with the BeagleBone White), but that only worked with the Micron eMMC chips originally used, not with the Kingston eMMC chips currently used. (unfortunately the eMMC spec is a bit ambiguous about how the eMMC reset pin should behave, and Micron and Kingston ...
<Guest46>
cause I think he was basing some designs off outdated documentation
<zmatt>
...interpreted the spec differently)
<Guest46>
ah, unfortunated
LetoThe2nd has joined #beagle
<zmatt>
there's no pinout differences between any of the BeagleBone Black revisions
<zmatt>
well, generally it's preferred to boot from eMMC anyway
<Guest46>
ok
<Guest46>
how come?
<zmatt>
reading data from eMMC is about twice as fast as the maximum performance you can get from μSD on the BBB, so that will affect boot time and overall performance
<Guest46>
ah, I see
<Guest46>
any other reason? or just the speed?
<Guest46>
we are more concerned with reliability than speed
<zmatt>
reliability of consumer SD cards is questionable
<Guest46>
so faster and more reliable to boot from eMMC then?
<zmatt>
also, despite the "click" when you insert an sd card, it's not actually locking, so that's something to consider if your device may be subject to sudden forces or vibration (e.g. during transport)
<Guest46>
huh, that's interesting
<Guest46>
I assumed it did lock because of the click
<Guest46>
but yeah, vibration happens definitely
<zmatt>
the click is just the ejection mechanism (similar to a pens that click to extend and again to retract)
<Guest46>
interesting
<Guest46>
yep, you're right
<Guest46>
I can pull it out even after clicking in
<zmatt>
yep, we've noticed that BBBs sometimes actually ship with the SD card slot clicked-in, implying that the card was removed like that after factory flashing
mattb0ne has quit [Ping timeout: 268 seconds]
<Guest46>
very interesting
<Guest46>
thanks for the help!
<zmatt>
as for eMMC reliability, it's been unproblematic for us thus far... we do reconfigure the eMMC into the "SLC mode" with "reliable writes enabled" just to be paranoid... SLC mode sacrifices 50% disk space but should greatly increase longevity and reliability
<Guest46>
what does SLC stand for?
<Guest46>
and where can I find more info on it?
<Guest46>
might be interested in using that as well
<zmatt>
reliable writes should increase resilience to sudden power loss, presumably at expense of performance though I've never tested the setting in isolation and SLC mode greatly improves write performance so the combined effect on performance is still net positive
<zmatt>
(both settings are part of the eMMC's irreversible one-time-programmable configuration, which doesn't exactly invite experimentation)
<zmatt>
SLC = single-level cell, meaning one bit of data is stored per flash memory cell (floating-gate transistor)
<zmatt>
as opposed to MLC (which is what the BBB's eMMC is by default) which stores 2 bits per cell
<zmatt>
consumer SD cards typically 3 bits per cell
<Guest46>
gotcha
<zmatt>
storing multiple bits per cell is really tricky since it means the memory cell isn't fully charged or discharged, but carefully charged to some intermediate level
<Guest46>
so if we've already purchased beaglebones, then they're already immutably SLC or MLC?
<Guest46>
we can't change it after the fact?
<zmatt>
no, they're shipped in unconfigured state
<Guest46>
oh ok
<Guest46>
but if I put ubuntu 18.04 on one, did that already make the choice?
<zmatt>
in that state they're MLC with reliable writes disabled, but you can still reconfigure this (once, which also erases the eMMC)
<zmatt>
nope
<Guest46>
ah
<Guest46>
ok so they start MLC, but you can change once if you want
<zmatt>
yep
<Guest46>
where could I find instructions as to how to do that?
<zmatt>
to avoid making mistakes with irreversible commands
<Guest46>
cool, thanks
<Guest46>
yeah that makes total sense
<zmatt>
and of course to maximize eMMC lifetime it helps to avoid unnecessary writes to eMMC
<zmatt>
e.g. get rid of rsyslogd
mattb0ne has joined #beagle
<zmatt>
the first time we destroyed an eMMC it was due to a little bug that caused a process to write iirc 16 GB of data per hour
mattb0ne has quit [Ping timeout: 252 seconds]
<zmatt>
oh yeah I was talking about the boot config pins earlier... so, you can safely use those pins are gpios (if you disable video in /boot/uEnv.txt), just be mindful to avoid accidently pulling the bright-yellow-marked ones up or down (whatever direction is opposite to the default pull) unless you're actually *intending* to change the bootrom configuration (which is not common)
<zmatt>
*pulling them up/down (opposite of default) during the power-up sequence I mean
mattb0ne has joined #beagle
<zmatt>
they can be safely driven high or low e.g. once reset is released
<zmatt>
using them as outputs is generally safe, though if you add too much load to them you may need to reinforce the 100 kΩ on-board pulls by stronger external ones
<zmatt>
(we've run into that problem when we attached an external LVDS framer to a beaglebone, whose pins had an input impedance that was reasonably high but still low enough to override the weak 100 kΩ on-board pull-ups, resulting in boot failure)
Guest46 has quit [Quit: Client closed]
vagrantc has quit [Quit: leaving]
vagrantc has joined #beagle
set_ has joined #beagle
<zmatt>
... ok bye
<zmatt>
:P
CCFL_Man has quit [Read error: Connection reset by peer]
ikarso has quit [Quit: Connection closed for inactivity]