<Partmedia>
Hi there, I have a BeagleBone black which will boot fine from the eMMC, but has some trouble booting off a SD card I wrote. I `dd if=img of=/sd/card` on a host, plugged into the BeagleBone, pressed the user boot button, and powered up the board. I get this serial output and get dropped into a u-boot prompt: http://dpaste.com//3TREVNEHZ
<zmatt>
did dd actually finish successfully? :P
<Partmedia>
I *think* so, I've tried dd several times, two different systems (with different MMC drivers), the correct number of bits went over the wire...
<zmatt>
is the sd card maybe just broken?
<Partmedia>
This is a 16 GiB micro SDHC, that it's SDHC probably isn't the problem?
<zmatt>
(or worn out)
<zmatt>
it has no problem reading the card, it has a problem mounting the root filesystem
russ has joined #beagle
<zmatt>
regardless, all cards large enough to hold current IoT images are necessarily SDHC, so no that is obviously not a problem :P
<zmatt>
it may be informative to verify the card contents after writing it... which you could do manually with dd and e.g. md5sum though it's easier to use a flash tool that automatically performs verification like Balena Etcher
<zmatt>
I have a μSD card here where some parts of the card are random number generators
<zmatt>
(presumably due to wear-out)
<zmatt>
also, is this a custom u-boot? the output seems odd
<zmatt>
or maybe it's just older than I'm used to
<zmatt>
actually that's a really old u-boot... you're trying to boot some ancient image?
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #beagle
vagrantc has quit [Quit: leaving]
<Partmedia>
zmatt, FreeBSD 12.1, and didn't realize that this was the u-boot on the SD card. Is this u-boot chain loaded by a u-boot flashed somewhere, or does the boot ROM directly load u-boot from SD?
<zmatt>
ah no actually bootrom prefers loading bootloader from eMMC over the one on SD card, and that may very well be the problem if you're trying to boot some weird image
<zmatt>
try powering on with the S2 button (the one closest to the card slot) held down, you can let go once the power led turns on
<zmatt>
that will bypass the bootloader on eMMC and use the one on SD card instead
<zmatt>
bootrom can indeed directly load u-boot from SD card, that's not really significantly different from loading it from eMMC
<zmatt>
but the default device order in which bootrom looks for the program to load (which will be u-boot SPL which then initializes ddr3 ram and loads the full u-boot) is { eMMC, μSD, uart-xmodem, usb-rndis }
<zmatt>
powering on with the S2 button held down changes that to { spi-flash, μSD, usb-rndis, uart-xmodem }
<zmatt>
(until next time the board is power-cycled)
<zmatt>
(another way to force the bootloader on SD card to be used is by simply wiping eMMC, or at least wiping the bootloader on eMMC)
lucas_ has joined #beagle
lucascastro has quit [Ping timeout: 240 seconds]
Guest40269 has quit [Quit: Client closed]
<mranostaj>
rcn-ee: so ./setup_sdcard.sh is pulling a u-boot that does have the S01 check.. does that take a bit to get populated?
<mranostaj>
*doesn't
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
Guest40269 has joined #beagle
ikarso has joined #beagle
<Partmedia>
zmatt, thanks for the discussion, I think I got hit with the usual issue, which was that "hold down S2 and then press reset" is different from "hold down S2, apply power"
<set_>
I bring that up b/c of different loopholes mImA use to 'adjust' things on specific chips to peripherals. It is an ongoing thing. I was unaware of it.
<set_>
It is sort of neat. It is like one person builds while the next person decouples the ideas.
<set_>
For instance, a machine can build specific tooling while the person, mImA, utilizes on his/her own builds the correct way to flaw the machine that builds. Scary stuff.
<set_>
w/out multiple(s) of groups geared towards the sole idea of cryptology and security, people utilize the machine in incorrect ways w/out even knowing it. It is like a blindside.
<set_>
Anyway, just reading as usual to no avail.
<zmatt>
Partmedia: correct, it's only sampled at power-on
florian has joined #beagle
otisolsen70 has joined #beagle
Shadyman has quit [Remote host closed the connection]
set_ has quit [Ping timeout: 240 seconds]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
giort has joined #beagle
linkliu59 has quit [Ping timeout: 250 seconds]
linkliu59 has joined #beagle
<Daulity>
is there anyway to swap rx and tx on rs485 (specifically uart2) because we have an issue where the differencial signal is inverted
<Daulity>
i hadn't changed the device tree only to change the direction pin which gpio to use.
<Daulity>
what we did do was update the kernel
<Daulity>
or maybe the data is inverted ?
<Daulity>
the hardware has not got rx/tx swapped or inverted
giort has quit [Ping timeout: 250 seconds]
<zmatt>
Daulity: rx and tx can be swapped yes, there's a DT property for that
<zmatt>
but that doesn't match your problem description "issue where the differencial signal is inverted"
<zmatt>
oh you mean the driver-enable signal is inverted?
<zmatt>
the polarity of the driver-enable signal is configured by userspace
giort has joined #beagle
<zmatt>
it is active-low by default
<zmatt>
4.x kernels don't support a gpio for driver-enable though (when using the 8250-omap driver, which is the default, rather than the now-deprecated omap-serial driver), it has to be the rts pin for the uart
<zmatt>
i.e. P8.38 for uart 2
<Daulity>
zmatt: yea sorry the signals are inverted
<Daulity>
no the RX and TX are inverted :)
<zmatt>
"the signals" .. which signals?
<Daulity>
(they aren't) but is it possible to invert them ?
<zmatt>
you mean the polarity of the rx and tx signals themselves? no, that just means you swapped the wires of the rs485 bus, there's nothing software (kernel or userspace) can do to influence this
<Daulity>
zmatt: yea thought so
<zmatt>
in particular, this cannot be influenced by kernel version
<zmatt>
(since, at a hardware level, there is no way for software to influence this)
<Daulity>
zmatt: no it's hardware has to be :) our rs485 transciever output is cross connected + is connected to - and vise versa
<zmatt>
the only fix for that is swap the + and - wires
<Daulity>
but i was looking for options to correct this maybe in software but it's not possible
<zmatt>
short of something desperate like using gpio and a software-uart implemented on PRU
<rcn-ee>
mranostaj, does your setup_sdcard.sh call have the "--distro-bootloader" flag? i've been moving from random u-boot builds, to git/deb builds for u-boot?
buzzmarshall has quit [Quit: Konversation terminated!]
xet7 has joined #beagle
LetoThe2nd has quit [Quit: Connection closed for inactivity]
Guest40269 has quit [Quit: Client closed]
Guest48 has joined #beagle
Guest48 has quit [Client Quit]
tiger_xyz has joined #beagle
buzzmarshall has joined #beagle
<tiger_xyz>
Hi GoodAfternoon, I am sure bluez5.50 meets Bluetooth 5. Specification. Is it implemented like 9.1 BROADCAST MODE AND OBSERVATION PROCEDURE in the Bluetooth 5.0 specification, etc. ?
<zmatt>
bluez apparently has an irc channel on oftc, you could try asking there
<tiger_xyz>
I am not sure.. Can anyone answer it?
<tiger_xyz>
ok, thanks
Angel_Sosa has joined #beagle
<Angel_Sosa>
I am hoping someone can help with this, the issue I have been working is a moving target. There is one piece of the message that stays content and seems to point to other pieces of software this is the link in pastebin https://pastebin.com/gFU0rp5z
<zmatt>
Angel_Sosa: I already explained what this means
<zmatt>
the traceback can be ignored completely since it's actually reporting an error caused by another processor on the system
<zmatt>
(so the error is unrelated to what's shown in the traceback)
<zmatt>
(the fact that the omap_l3_noc driver prints a traceback in this case is a bug in that driver in my opinion)
<zmatt>
I also explained how to fix it, just flash a non-TiDL image
<zmatt>
(I don't think it causes problems regardless, it's basically just spam)
<Angel_Sosa>
zmatt - I know you explained earlier to me and I sanitized the image / installation. I re - posted because I trimmed the install quite a bit and opted to remove all of the TIDL components. Which also revealed a couple hidden unsynced packages and go those fixed along the way. And it helped of course in many respects. That's why I took the chance to re-post the trace back in case there is another outcome. I believe what yo
<Angel_Sosa>
your saying
<zmatt>
well evidently the TIDL firmware is still being loaded
<Angel_Sosa>
Thanks
tiger_xyz has quit [Quit: Client closed]
<mranostaj>
rcn-ee: ah yes the distro bootloader command seems to work
lucas__ has quit [Ping timeout: 248 seconds]
lucascastro has joined #beagle
otisolsen70 has quit [Quit: Leaving]
ikarso has quit [Quit: Connection closed for inactivity]
Ankit47 has joined #beagle
vd has quit [Quit: Client closed]
<Ankit47>
any experts on network booting BBB
<zmatt>
that's not a trivial process, though last time I experimented with it I've come as far as being able to load u-boot and then (manually via the u-boot cmdline) load the kernel+dtb, which then ended on the lack of rootfs... so basically all that would be needed to complete that would be to ensure u-boot has the proper boot script and deal with nfs root
<zmatt>
(the nfs root part is not bbb-specific so it should be easier to find expertise on that)
<vagrantc>
i believe upstream u-boot supports PXE boot by default on the BBB, but you have to configure your DHCP server to pass appropriate values
<vagrantc>
so shouldn't require a custom comandline or anything
<zmatt>
yeah when I experimented with this it was a good while back
<vagrantc>
though i know the BBB images include a patched u-boot, so ...
<vagrantc>
Ankit47: ltsp.org does that sort of thing ... it may take some tweaking to adapt to the BBB
<vagrantc>
Ankit47: notably writing a compatible boot menu configuration
<zmatt>
vagrantc: have they somehow managed to fit support for netboot into SPL at the same time as other boot methods?
<zmatt>
since that was the main reason I had to custom-build u-boot for netbooting
<vagrantc>
zmatt: i recall there was some support for netbooting in SPL, but i'm most familiar with the netbooting from full-blown u-boot
<zmatt>
I probably should have sent those patches upstream... I don't think I ever did
<zmatt>
Ankit47: so did you have an actual question or were you just doing a poll?
ikarso has joined #beagle
argonautx has quit [Quit: Leaving]
lucascastro has quit [Ping timeout: 250 seconds]
ogra has quit [Ping timeout: 276 seconds]
djinni has quit [Quit: Leaving]
ogra has joined #beagle
djinni has joined #beagle
Ankit47 has quit [Quit: Client closed]
lucascastro has joined #beagle
rcn-ee has quit [Remote host closed the connection]
the_person48 has joined #beagle
<the_person48>
hello, I have a beaglebone black running debian 10.0. I was test installing some libraries and ran out of space, so I would like to revert the installation back to a fresh install. I am trying to figure out how to do this, but am a little confused by the documentation here: https://elinux.org/BeagleBoardDebian#Debian_10_.28buster.29
<the_person48>
I think the process is: 1) get debian image 2) write this to a microSD card 3) boot from the SD card 4) enable eMMC flashing and transfer from SD card to eMMC
<the_person48>
but I'm having trouble finding an actual debian image link on this page, does anyone know where to find one?
<zmatt>
the_person48: the easier steps are: 1. get a debian _flasher_ image 2. write this to microSD card (using Balena Etcher is recommended) 3. boot from the SD card and wait until flashing is complete
<zmatt>
so the image you want is probably "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher"
<zmatt>
or, if you want a minimal system (to maximize free disk space) and are okay with installing whatever packages you need yourself, you could grab a console image, though annoyingly there's no pre-made flasher images for that on that page, just normal sd card images
<the_person48>
gotcha
<the_person48>
I think that we should have enough space, I was just installing some stuff that was questionably necessary before
<the_person48>
but if I still run into space limitations on reinstall then I'll go that route
<the_person48>
would I find those in the same place?
<zmatt>
but turning a normal image into a flasher isn't hard either: just boot from the card and uncomment the relevant line in /boot/uEnv.txt (I think it's the last line, it's something like cmdline=init=...something involving flasher)
<zmatt>
yeah the console image is below it on that page, "AM3358 Debian 10.3 2020-04-06 1GB SD console"
<the_person48>
I'd rather use the latest stable one
<the_person48>
which it sounds like is 10.3?
<zmatt>
I mean, 10.3 is just the debian release... if you install updates you'll automatically get 10.10
<the_person48>
gotcha
<zmatt>
but using the latest stable image is generally a good idea yeah
<zmatt>
even though they have known issues too
<zmatt>
I'm not sure why there hasn't been a stable release in such a long time
<the_person48>
for sure
<the_person48>
so despite known issues, it sounds like 10.3 is the latest stable image?
<the_person48>
or "stable" at least
<zmatt>
"10.3" is not a useful identifier, if you want to refer to an image, use the image date
<the_person48>
2020-04-06, the one you initially suggested
<zmatt>
the latest stable images are the 2020-04-06 buster images yes
<zmatt>
I'm just saying, don't refer to it as "10.3" since that's the least relevant part of the image identifier
<the_person48>
for sure, noted
Shadyman has joined #beagle
the_person48 has quit [Quit: Client closed]
<set_>
Hey! Did anyone read the paper on the SGX from intel and the ARM TrustZone chips?
<zmatt>
breaking intel sgx is a popular hobby I think
<zmatt>
I'll admit, "plundervolt" is a cute name for a vulnerability
<set_>
Ha.
<set_>
Yep.
<set_>
It is still interesting work on how they devise reverse engineering to create flaws in mfg. and science.
<set_>
I guess you are right. From the onset of mfg. of chips, there must have been those of 'us' who have wanted to destroy or alter the chip mfg. product.
<set_>
"To the greater good!"
<zmatt>
fault injection attacks are certainly interesting... like, it's obvious that you can use things like undervolting or overclocking to inject faults, but it's less obvious that you'd be able to inject faults carefully enough to break security instead of just causing a complete crash
<set_>
Right. I did not know, from before reading the article portions, that you could create flaws in the security features.
<set_>
undervoltage == security issues? Hmm.
<set_>
It is like one has to do it at the correct time w/ documentation on it. So, you can review and research exactly when the fault took place.
<zmatt>
you generally don't have that kind of insight, you have to infer what's happening
<set_>
Right. Guess work on the heap, stack, and data.
<set_>
I have been reading up more on the heap (different types) and stack recently which lead me to the issue of plundervolt. Ha.
<set_>
Awful bugs and man-in-the-middle attackers.
<set_>
In c++, from what I understand * a little *, you can alter the heap and manipulate it to handle specific data in and out of it.
<set_>
Then...once things are altered and if altered in a specific manner, memory allocation tasks become evident.
<set_>
Who, what nullptr?
<set_>
I get so excited about learning. Anyway, a storm is hitting us again this year. Saturday night! Yay! So, I should get ready. Blah.
vagrantc has quit [Quit: leaving]
ikarso has quit [Quit: Connection closed for inactivity]