Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pi Zero Build not working #29

Closed
pkongara opened this issue Mar 20, 2020 · 16 comments · Fixed by #30
Closed

Pi Zero Build not working #29

pkongara opened this issue Mar 20, 2020 · 16 comments · Fixed by #30
Labels
bug Something isn't working

Comments

@pkongara
Copy link

I have followed the build and deploy instructions of nymea for Pi Zero. But I am having trouble using Berry Lan on a Pi Zero.


I have done this using a fresh buster install on a Pi Zero

sudo apt install qt5-default qtbase5-dev qtbase5-dev-tools libqt5bluetooth5 qtconnectivity5-dev git

sudo apt install debhelper dh-systemd

git clone
libnymea-networkmanager
and nymea-gpio
and nymea-networkmanager

First I have built and installed libnymea-networkmanager

dpkg-buildpackage -us -uc -tc
sudo apt install ./libnymea-networkmanager_0.2.3_armhf.deb
sudo apt install ./libnymea-networkmanager-dev_0.2.3_armhf.deb

Then I have done the same for libnymea-gpio

And finally, I have built and installed
nymea-networkmanager_0.5.1_armhf.deb

I have also done -
sudo systemctl disable dhcpcd


After all that ... when I fire up Berry Lan, first time, I see the advertisement from Pi Zero, but moving on to the second screen, it keeps spinning without showing any networks. I restart Berry Lan, after that I don't even see the advertisement. I restart Pi Zero, any number of times ... no advertisement.

The same SD card when booting a Pi 3 works perfect with BerryLan.

This is reproducible on multiple Pi Zero and multiple Pi 3 cards.

Am I missing anything in the process?

I know about
nymea/berrylan#10
https://forum.nymea.io/t/berrylan-on-pi-zero-w/120
#25

But those instructions I thought only applies to when you are not building yourself.
BTW: I have sone similar build that worked fine on Pi Zero and Pi 3 for Stretch. I am having issues because I want to upgrade to Buster and to the latest nymea code.

Help appreciated!

@pkongara
Copy link
Author

BTW: nymea network manager is running file on Pi Zero. But the functionality as described above is the issue.

@mzanetti
Copy link
Member

mzanetti commented Mar 20, 2020

Hey,

So just as side note on the beginning. Our buster repo now also has builds compatible to the Pi0. You can add this repository:

deb http://repository.nymea.io buster rpi

and then you should be able to apt-get install working builds.

Anyhow, as you apparently managed to build already, that likely won't solve your problem.

My suggestion would be to use

sudo journalctl -u nymea-networkmanager

and watch the logs it prints... Perhaps it helps clarifying what's going on... Post the log here if you think there is a bug somewhere.

@pkongara
Copy link
Author

Thank you for trying to help !

I have taken the logs when the same SD card (nymea build with Pi Zero) working well on Pi3 and not working so well on Pi Zero. I have attached both logs. There is not much information in the logs other than the fact that the bluetoothserver seems not started on Pi Zero. Does that give any clues?

Logs.zip

@mzanetti
Copy link
Member

Indeed... There is a bug...

Seems to have been introduced in the latest update.

On slow systems, the networkmanager exposes its interface too slow. Because of that a workaround has been added in libnymea-networkmanager which gives it a bit more time to start up. However, turns out, this now introduces a race condition because now the Bluetooth part is checking too early...

mzanetti added a commit that referenced this issue Mar 20, 2020
Rework the setup sequence to not rely on timers anymore but instead
always react to wifi state changes only.

Fixes #29
mzanetti added a commit that referenced this issue Mar 20, 2020
Rework the setup sequence to not rely on timers anymore but instead
always react to wifi state changes only.

Fixes #29
@mzanetti
Copy link
Member

The attached branch should hopefully fix this, however, note that it is not fully tested yet. I'll report back when I've done some more testing. Feel free to help with testing. It's building it in the experimental repository atm...

deb http://ci-repo.nymea.io/experimental-silo buster rpi

mzanetti added a commit that referenced this issue Mar 21, 2020
Rework the setup sequence to not rely on timers anymore but instead
always react to wifi state changes only.

Fixes #29
@pkongara
Copy link
Author

Oh, that makes tons of sense! I have not reported but I too thought there may be a race condition. I have tried this about 20 times on Pi Zero, and it worked once!

I will try the fix and report if it working for me. Thank you very much!

@mzanetti
Copy link
Member

mzanetti commented Mar 21, 2020

Ok, I have tested the experimental builds including this fix (nymea-networkmanager 0.5.2 and libnymea-networkmanager 0.3.0) as well as the experimental berrylan image with those package versions (https://downloads.nymea.io/images/berrylan/experimental/berrylan-image-raspbian-buster-2020-03-21.zip) on a RPi3 and a RPi0 and it seems to work fine for me.

I'd appreciate if you could let me know if it works for you too now.

@pkongara
Copy link
Author

Just finished testing both with RPi3 and RPi0 multiple times. And it is working for me too.

Thank you very much!

Just one clarification. This is perhaps a newbie question. I am building my own because I need one minor change in the network manager to write something to the SD. When I build on Pi3, I know the package doesn't run on Pi0 (perhaps pi zero arch is not forward compatible?). When I build on Pi0, it does run well on Pi3 (arch is backward compatible?) as well. Not withstanding my own experience, Is it considered safe to use the packages built on Pi0 on Pi3 as well?

@mzanetti
Copy link
Member

Thank you for confirming the fix, for your own builds you will want to use the branches "fix-wifi-bt-race" for both repositories for now. My branches will be merged to master when the next nymea release is made (I'd estimate 2 - 3 weeks from now, no promise tho).

I'm building those packages on a Pi4, they run just fine on all the Raspberries, from Pi0 to Pi4... You're right that one can't just cross-compile to armhf easily, as those packages won't run on the Pi0 and Pi1. But when building on the Pi3/4 directly it works fine for me... I think there was a change in upstream Raspbian. IIRC this wasn't working with stretch yet but works with buster now. I didn't dig deeper why that's the case tho...

@mzanetti mzanetti added the bug Something isn't working label Mar 21, 2020
@mzanetti
Copy link
Member

Well, actually I did dig a bit deeper but I must admit I did not get through it 100%... Here's what I figured out:

Pi0 and Pi1 are some weird architecture, something between armv6 and armv7, while Pi2, 3 and 4 are proper armv7 machines... One can build packages working for all of them using the compiler flag -march=arm6 (or similar, don't recall) and afaik, since buster they fixed the default gcc config on the RPi image to do so...

Cross-compiling for -march=arm6 isn't easily possible because gcc-cross (amd64 to arm) has some stuff for that not implemented, it'll just crash with some "not implemented" message.
I think Rasbperry Pi themselves used a patched gcc toolchain from Linaro with an old gcc (v4) to be able to cross compile up until stretch.

I haven't managed to figure out a way to cross compile with buster now, which is why I resorted to build on a Pi4 natively. Not sure how they're doing it themselves, but as they apparently fixed the compiler in the image at least, I'd hope the situation will improve over time.

@mzanetti
Copy link
Member

May I ask what changes you need? Perhaps we could use that too?

@pkongara
Copy link
Author

Oh, I see. Thank you for the explanation.

About the changes, they are quite simple -

  • Change the advertised name
  • And while supplying wifi credentials, our client sends the ownership information (who logged in) to RPI as a way for the user to manage the RPI from the cloud. So the changes to the server is to read those additional params that client sends and write them to the card.

I will be glad to share if those are interesting, but I am assuming they are not generic enough to be broadly useful.

We appreciate these tools. We will definitely give credits as required when we release.

@pkongara
Copy link
Author

Sorry, the advertised name perhaps is not compiled in. But the second change for sure.

@igorpecovnik
Copy link

Pi0 and Pi1 are some weird architecture

Ali Pi have weird proprietary Videocore architecture which runs ARM cores, version this and that: https://wiki.debian.org/RaspberryPi first generation is just a bit more weird due to armv6.

@pkongara
Copy link
Author

Thanks for addressing the issue.

@mzanetti
Copy link
Member

FWIW, the fix is not yet released to stable (it's in the testing repository atm). Normally github would close bugs automatically when the fix is merged to master. Anyhow, just watch the linked pull request. Once that's merged the packages including the fix will also be released to stable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants