BBBW first boot - no WiFi/BT

[ags]

I've had a BBBW for 1+ years. Just booted, and can't get WiFi working.

using connmanctl:

connmanctl>  enable wifi

Error wifi: Method "SetProperty" with signature "sv" on interface "net.connman.Technology" doesn't exist

Researched and saw convo about "corrupt EEPROM"; tried using "dtb=am335x-boneblack-wireless.dtb" in /boot/uEnv.txt - no help

downloaded newer image (4.14.108-ti-r113) to SDcard and booted. Still no wlan0

BT and WL LEDs are not illuminated

ifconfig -a does not show wlan0

/opt/scripts/tools/version.sh output:

debian@beaglebone:/opt/scripts/tools$ sudo ./version.sh

git:/opt/scripts/:[109f74fb87e6034ae1a8971a244064a8d5e090a5]

]eprom:[A335BNLTBBWG2331?O

model:[TI_AM335x_BeagleBone_Black]

dogtag:[BeagleBoard.org Debian Image 2019-08-03]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-gbb4af0f50f]:[location: dd MBR]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2016.11-rc3-00002-g73df7f]:[location: dd MBR]

kernel:[4.14.108-ti-r113]

nodejs:[v6.17.0]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]

pkg:[bb-cape-overlays]:[4.4.20190801.0-0rcnee0~stretch+20190801]

pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]

pkg:[kmod]:[23-2rcnee1~stretch+20171005]

pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~stretch+20190327]

pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev gpio pwm eqep remoteproc admin spi tisdk weston-launch xenomai cloud9ide]

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]

dmesg | grep remote

[    1.221200] remoteproc remoteproc0: wkup_m3 is available

[    1.441065] remoteproc remoteproc0: powering up wkup_m3

[    1.441181] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168

[    1.445381] remoteproc remoteproc0: remote processor wkup_m3 is now up

[    9.891469] remoteproc remoteproc1: 4a334000.pru is available

[    9.896369] remoteproc remoteproc2: 4a338000.pru is available

dmesg | grep pru

[    9.863842] pruss 4a300000.pruss: creating PRU cores and other child platform devices

[    9.891469] remoteproc remoteproc1: 4a334000.pru is available

[    9.891589] pru-rproc 4a334000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully

[    9.896369] remoteproc remoteproc2: 4a338000.pru is available

[    9.896486] pru-rproc 4a338000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully

dmesg | grep pinctrl-single

[    0.930034] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568

dmesg | grep gpio-of-helper

[    0.942098] gpio-of-helper ocp:cape-universal: ready

lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

END

I'm really stuck.

[ags]

More: I tried overriding the dtb in uEnv.txt to force wireless operation without reflashing eeprom - this was reported to work in some cases.

How can I tell from the version.sh output if my eeprom is corrupt or incorrect for a BBB Wireless?

[Robert Nelson]

On Mon, Dec 16, 2019 at 2:26 PM ags <alfred.g...@gmail.com> wrote:
>
> More: I tried overriding the dtb in uEnv.txt to force wireless operation without reflashing eeprom - this was reported to work in some cases.
> How can I tell from the version.sh output if my eeprom is corrupt or incorrect for a BBB Wireless?

>eprom:[A335BNLTBBWG2331?O]
>model:[TI_AM335x_BeagleBone_Black]

Oh, it's corrupt.. It's coming up as a normal BeagleBone Black..

It should be:

eeprom:[A335BNLTBWA51919BBWG0600]
model:[TI_AM335x_BeagleBone_Black_Wireless]

So when you compare yours with mine, notice how I have the "BWA51919"
between A335BNLT and BBWG****, well that's the "Wireless" identifier..

So taking a wire, Ground TP1, (TP1 is between barrel plug and the J1 interface)

Then as root run this "one" line command:
*****
dd if=/opt/scripts/device/bone/bbgw-eeprom.dump
of=/sys/devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050/eeprom
*****
^ Yes this is one line, that gmail/etc will wordwrap into two lines..

Then reboot..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[ags]

My next question was going to be "what should the EEPROM ID be... or what form should it take"?

This (non-functioning) BBBW was purchased in Dec 2018 (just now putting it into service). I have another BBBW purchased in Feb 2017 that worked out-of-box (almost... it had a different issue with the "out-of-box configuration" that you also helped me with) and it shows:

eeprom:[A335BNLTBWA51650BBWG0378]

model:[TI_AM335x_BeagleBone_Black_Wireless]

So does a "correct" BBB Wireless EEPROM ID follow the A335BNLT BWA51*** BBWG0***] format, with the first wildcard digits some form of version of the wireless chip and the second wildcard digits the board or SoC rev? (spaces mine to separate the different fields)

Finally, was my expectation/understanding incorrect that using /boot/uEnv.txt to override the EEPROM setting and force loading the wireless dtb would also work, without changing the EEPROM? (My thinking was to try that first, then if it worked it would validate the idea the the EEPROM was bad and then reflash the EEPROM).

Thanks for your help, Robert.

On Monday, December 16, 2019 at 1:07:04 PM UTC-8, RobertCNelson wrote:

[Robert Nelson]

On Mon, Dec 16, 2019 at 3:58 PM ags <alfred.g...@gmail.com> wrote:
>
> My next question was going to be "what should the EEPROM ID be... or what form should it take"?

An even better, answer, look on side of the board, there is a bar code
with the coded: BWA5***** that's what the device tester was supposed
to write to the eeprom. ;)

> This (non-functioning) BBBW was purchased in Dec 2018 (just now putting it into service). I have another BBBW purchased in Feb 2017 that worked out-of-box (almost... it had a different issue with the "out-of-box configuration" that you also helped me with) and it shows:
>
> eeprom:[A335BNLTBWA51650BBWG0378]
>
> model:[TI_AM335x_BeagleBone_Black_Wireless]
>
>
> So does a "correct" BBB Wireless EEPROM ID follow the A335BNLT BWA51*** BBWG0***] format, with the first wildcard digits some form of version of the wireless chip and the second wildcard digits the board or SoC rev? (spaces mine to separate the different fields)

The first Wild card, is the year in 2 digits and the week in 2 digits.
The last wildcard is incremental units of that week..

BWA5 = BeagleBone Black Wireless

BBWG = BeagleBone Black Wireless, Manufactured by GHI

>
> Finally, was my expectation/understanding incorrect that using /boot/uEnv.txt to override the EEPROM setting and force loading the wireless dtb would also work, without changing the EEPROM? (My thinking was to try that first, then if it worked it would validate the idea the the EEPROM was bad and then reflash the EEPROM).

Well, you did have this old version of u-boot installed to the eMMC:

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2016.11-rc3-00002-g73df7f]:[location: dd MBR]

So the overide probably just didn't work..

[Dennis Lee Bieber]

{Blast -- my original response went to the dead submittal route, a belated
resend}

On Sun, 15 Dec 2019 23:00:05 -0800 (PST), in
gmane.comp.hardware.beagleboard.user ags

<alfred.g.schmidt-Re...@public.gmane.org> wrote:

>
>bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
>2019.04-00002-gbb4af0f50f]:[location: dd MBR]
>
>bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
>2016.11-rc3-00002-g73df7f]:[location: dd MBR]
>

That's getting rather old... When was the last time you reflashed the
entire eMMC? Does the board behave differently if you hold the boot-select
button down while applying power? (I believe the eMMC u-boot is used even
if it later transfers to the SD card for actual OS unless the boot-select
was held; then it uses the SD card u-boot for everything)

I don't have the wireless, but...

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:

eeprom:[A335BNLT000C0615BBBK0412]

model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2019-08-03]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2019.04-00002-gbb4af0f50f]:[location: dd MBR]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot

2019.04-00002-gbb4af0f50f]:[location: dd MBR]

kernel:[4.14.108-ti-r113]

... I tend to flash the eMMC whenever a new "standard" release shows up on
http://beagleboard.org/latest-images (given how fat the LXQT image is, I
think I've started using the IoT image for eMMC and reserve the LXQT image
for SD cards).
--
Dennis L Bieber

[ags]

For future reference by others, I think instead of

"if=/opt/scripts/device/bone/bbgw-eeprom.dump"

it should have been stated as:

 

"if=/opt/scripts/device/bone/bbbw-eeprom.dump"

 

since I have a BeagleBone Black Wireless (but it is manufactured by GHI as you said). I first updated using the first file, and my device type was shows as BeagleBone Green Wireless. The WiFi would not work (using connmanctl for setup). I then flashed using the second file, and my device displayed as BeagleBone Black Wireless, and I was then successful in setting up WiFi connectivity.

On Monday, December 16, 2019 at 2:27:17 PM UTC-8, RobertCNelson wrote:

[ags]

The device was purchased in Dec 2018, and just now put into service; it is a year (at least) out of date.

I was holding the boot-select button, and it did act as expected, selecting between booting from the eMMC (not pushed) and the SD card (pushed) at power-up/start.

It seems that the forced directive in uEnv.txt was ignored, though, so I presume that uboot did not read the uEnv.txt from the SD card even if booting from it.

On Monday, December 16, 2019 at 6:43:22 PM UTC-8, Dennis Bieber wrote:

{Blast -- my original response went to the dead submittal route, a belated
resend}

On Sun, 15 Dec 2019 23:00:05 -0800 (PST), in

gmane.comp.hardware.beagleboard.user ags wrote:

[Dennis Lee Bieber]

On Mon, 16 Dec 2019 23:54:41 -0800 (PST), in
gmane.comp.hardware.beagleboard.user ags

<alfred.g.schmidt-Re...@public.gmane.org> wrote:


>The device was purchased in Dec 2018, and just now put into service; it is
>a year (at least) out of date.

Based on the u-boot version -- much further out of date <G>

>I was holding the boot-select button, and it did act as expected, selecting
>between booting from the eMMC (not pushed) and the SD card (pushed) at
>power-up/start.
>It seems that the forced directive in uEnv.txt was ignored, though, so I
>presume that uboot did not read the uEnv.txt from the SD card even if
>booting from it.
>

My point was that, for some time now, my BBBs have not needed the
boot-select. They transition from eMMC to complete the boot using the SD
card, so long as a bootable SD card is in place.

The boot-select seems only required now to force the use of the SD card
u-boot image.

Granted -- none of this appears to have an effect on your WiFi
matter... 'tis just an observation on booting behavior based upon my
collection...
--
Dennis L Bieber

[ags]

Thanks for that info. Now that I have a "modern" uboot installed, I'll pay attention to how it works without holding the boot button.

On Tuesday, December 17, 2019 at 8:54:52 AM UTC-8, Dennis Bieber wrote:

On Mon, 16 Dec 2019 23:54:41 -0800 (PST), in
gmane.comp.hardware.beagleboard.user ags

[Dennis Lee Bieber]

On Tue, 17 Dec 2019 10:34:56 -0800 (PST), in
gmane.comp.hardware.beagleboard.user ags

<alfred.g.schmidt-Re...@public.gmane.org> wrote:

>Thanks for that info. Now that I have a "modern" uboot installed, I'll pay
>attention to how it works without holding the boot button.
>

Here's hoping I don't have strange boards <G>

I'm pretty sure the last time I had to use the boot-select was when
trying to upgrade a board from the old "linux/cape-manager Device Tree
Overlays" to the newer u-boot overlays. For that, I needed the select as
the eMMC u-boot wasn't trying to load overlays, but then tried to start an
SD card Linux that expected the overlays to be already loaded.

Other than that, as stated, my experience has been that the eMMC u-boot
will start, and then transition to an image on the SD card (I'll confess
that I don't know if the DT overlays are drawn from eMMC or SD card).
--
Dennis L Bieber

[fitzzone]

Thank you for posting this.  I've had a BBBW that's had the same issue since it shipped two years ago and have been adding dtb=am335x-boneblack-wireless.dtb to uEnv.txt after upgrades to get WiFi working.  Never bothered to dig in until yesterday and found this thread.  Easy fix.

On Monday, December 16, 2019 at 1:07:04 PM UTC-8, RobertCNelson wrote:

[seca90...@gmail.com]

Purchased a 2nd hand BeagleBone Black Wireless and wireless wasn't recognized.  Was familiar with the version.sh script as I have a BeagleBone Green and a BeagleBone Green Wireless.  Noticed that version.sh reported the Black Wireless as a BeagleBone Black and a Google search resulted in this thread.  I now have a functioning BeagleBone Black Wireless!!!!

Thank you

On Monday, December 16, 2019 at 4:07:04 PM UTC-5, RobertCNelson wrote: