Comments (22)
@BaochengSu, @AsuraZeng, have you seen this before?
@mwanders98, there is no difference in using the original release (with an older 4.19 kernel) and the current one in master?
Next I would have asked you to try the upstream queue - but this unfortunately requires an update of the firmware which is not recommended without a programmer at hand to restore in case of problems.
from meta-iot2050.
No, haven't seen such issue before.
We will try to reproduce it.
@mwanders98, could you please share us the /opt/configurator.sh or its equivalent so that we can reproduce it from our side?
from meta-iot2050.
I put the /opt/configurator.sh
and the /etc/systemd/system/configurator.service
into a gist.
I just tested this scripts with a fresh copy of IOT2050_Example_Image_V1.0.2.img.
I put both files on the system and did a systemctl daemon reload
and systemctl enable configurator.service
.
So then I have different configurations, whether the USB stick is inserted or not and whether the DHCP port is connected or not.
After each configuration change I reboot the device and test if the static configured ethernet port is "pingable" with the configured ip and I test dhcp too, if its connected.
The resulting behaviour is pretty confusing in my opinion. Sometimes it takes an eternity till the ports are accessible. Sometimes nothing works at all.
If you want to test it yourself, I would suggest you to open two terminals with a ping to the wan and lan ip's and to play a bit with the different configurations and to reboot each time.
Tomorrow, I will try this setup again with the newest image built by Github Actions from the main branch.
from meta-iot2050.
Do your issues always correlate with that "xmit timeout" errors on the kernel console?
from meta-iot2050.
Yes. I can see them in the syslog always.
from meta-iot2050.
@mwanders98 I saw from the scripts that the networking.service is managing the network, has the NetworkManager.service been disabled? Otherwise these two would conflict with each other.
The default network config tool for headless Debian buster is ifupdown, i.e. the networking.service belongs to. For our IOT2050 example image, to simplify the wireless network configuration, we use the Network Manager as the default configuration tool.
So if you are not using any wireless network technologies, or even don't mind the complexities of the wireless configuration, feel free to just disable the NetworkManager service.
from meta-iot2050.
Sorry for my late response. I deactivated the NetworkManager but the error still exists.
I tested this on the newest Debian image from Github Actions.
Do you have an alternative idea how I can configure the network configuration dynamically at boot time? For example I could run the script before any network related systemd services are starting up. My question here is which systemd target would be correct? The network-pre.target does not exist, if I remember correctly.
from meta-iot2050.
If you install ifupdown, you can configure networking the classic way. And even if NetworkManager is enabled, it will stay away from interfaces described that way.
But are you sure you could address/work around this issue at all via scripts? The timeout error of the kernel rather points to the driver or even lower, not the way how and by whom networking is configured.
from meta-iot2050.
The configuration itself works fine via /etc/network/interfaces.
No, I am not sure at all, just a naive idea from my side for a temporary workaround. I will try the ubuntu branch tomorrow or do you have another idea how to fix this?
You mentioned a firmware update, which firmware should I update to? And how to do it? I've seen an iot2050-firmware-update script..
from meta-iot2050.
Ubuntu will mean same kernel, possibly just a different NetworkManager version, but same (default) way of configuration.
We have no new firmware image to share that you can safely install. You can build own images from source, and those may work, but if they don't, you need a programmer to reflash a working image.
from meta-iot2050.
I downloaded the newest images from Github Actions artifacts, but it seems that they are shipping with kernel 4.19 not 5.x, is this correct?
So it looks like I didn't ever had a "new" image.
Therefore I tried to build the images myself but I ran into following issues:
| I: Extracting fdisk...
........
| I: Extracting liblzma5...
| I: Extracting zlib1g...
| I: Running command: chroot /work/build/tmp/work/iot2050-debian-arm64/isar-bootstrap-target/1.0-r0/rootfs /debootstrap/debootstrap --second-stage
| W: Failure trying to run: mount -t proc proc /proc
| W: See //debootstrap/debootstrap.log for details
| W: Failure trying to run: /sbin/ldconfig
| W: See //debootstrap/debootstrap.log for details
| WARNING: exit code 1 from a shell command.
| ERROR: Execution of '/work/build/tmp/work/iot2050-debian-arm64/isar-bootstrap-target/1.0-r0/temp/run.do_bootstrap.71' failed with exit code 1:
| I: Running command: debootstrap --arch arm64 --foreign --verbose --variant=minbase --include=locales,gnupg --components=main,contrib,non-free buster /work/build/tmp/work/iot2050-debian-arm64/isar-bootstrap-target/1.0-r0/rootfs http://deb.debian.org/debian
| I: Retrieving InRelease
| I: Checking Release signature
| I: Valid Release signature (key id 6D33866EDD8FFA41C0143AEDDCC9EFBF77E11517)
| I: Retrieving Packages
......
| I: Validating Packages
| I: Resolving dependencies of required packages...
| I: Resolving dependencies of base packages...
| I: Checking component main on http://deb.debian.org/debian...
| I: Retrieving libacl1 2.2.53-4
| I: Validating libacl1 2.2.53-4
........
| I: Extracting liblzma5...
| I: Extracting zlib1g...
| I: Running command: chroot /work/build/tmp/work/iot2050-debian-arm64/isar-bootstrap-target/1.0-r0/rootfs /debootstrap/debootstrap --second-stage
| W: Failure trying to run: mount -t proc proc /proc
| W: See //debootstrap/debootstrap.log for details
| W: Failure trying to run: /sbin/ldconfig
| W: See //debootstrap/debootstrap.log for details
| WARNING: exit code 1 from a shell command.
|
ERROR: Task (/work/isar/meta/recipes-core/isar-bootstrap/isar-bootstrap-target.bb:do_bootstrap) failed with exit code '1'
NOTE: Tasks Summary: Attempted 154 tasks of which 80 didn't need to be rerun and 1 failed.
I tried the different build commands mentioned in the README, but neither works.
My build host is a Ubuntu vmware vm which is completely empty but was upgraded from 18.04 to 20.04.2 today.
Linux build 5.4.0-70-generic #78-Ubuntu SMP Fri Mar 19 13:29:52 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
What could fix this build error?
from meta-iot2050.
When sharing build issues, please make sure to also share the exact command line used to start the build.
Regarding 5.x kernels (upstream): You can build that already by appending :kas/opt/upstream.yml
to the main yaml. However, it takes a newer firmware as well, and installing that my leave your device broken (see https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/README.md).
from meta-iot2050.
Hi, I'm also have the same issue with IOT2050 Basic.
If I connect the ethernet cable after the equipment boots. The ethernet port (configure as dhcp) don't get IP address.
Log:
root@iot2050-debian:~# tail -f /var/log/syslog
Feb 14 10:20:03 iot2050-debian ntpd[456]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Feb 14 10:20:04 iot2050-debian ntpd[456]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Feb 14 10:20:06 iot2050-debian ntpd[456]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Feb 14 10:20:07 iot2050-debian ntpd[456]: error resolving pool 2.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Feb 14 10:20:18 iot2050-debian kernel: [ 506.069328] icssg-prueth pruss0_eth eth1: Link is Up - 100Mbps/Full - flow control off
Feb 14 10:20:18 iot2050-debian kernel: [ 506.077327] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Feb 14 10:20:18 iot2050-debian NetworkManager[227]: [1550139618.4864] device (eth1): carrier: link connected
Feb 14 10:20:18 iot2050-debian kernel: [ 506.184856] icssg-prueth pruss0_eth eth1: cmd 8102000a: completion timeout
Feb 14 10:20:21 iot2050-debian ntpd[456]: Listen normally on 18 eth1 [fe80::8ef3:19ff:fe0a:e827%2]:123
Feb 14 10:20:21 iot2050-debian ntpd[456]: new interface(s) found: waking up resolver
from meta-iot2050.
But that works if the cable was plugged before booting?
Did you try with the latest image from CI here? Or with the released one? Any differences in behavior?
from meta-iot2050.
It works well if the cable is plugged before booting.
The image was build from the github commit from the date 2021-03-05.
I did not try with other image.
Update:
To mitigate this problem on the iot2050 that are already install. We change from dhcp to static ip address.
from meta-iot2050.
Problem still applies to V01.01.01 release?
from meta-iot2050.
Sorry for the late reply.
I download the V01.01.01 release from the siemens forum and I got the same issue.
from meta-iot2050.
I also have the same issue even with the recent release. Is there any resolution to this issue ?
from meta-iot2050.
@Vishal8523 Do you have the dmesg | grep pru
log?
from meta-iot2050.
from meta-iot2050.
I've integrated the newer TI firmware that may fix this but not yet tested the outcome. Any feedback highly welcome!
from meta-iot2050.
According to our tests, the issue is resolved with the latest master version. Please reopen if that should not be the case.
from meta-iot2050.
Related Issues (20)
- Image not booting on newer IOTs with firmware >=F06? HOT 16
- Last image and IOT PG1 HOT 5
- IOT2050 WITH NODE RED VERSION 3 AND NODE JS VERSION - PROBLEM WITH READING GPIO PINS HOT 3
- Mongoose webserver not working HOT 1
- SWUpdate automate complete_update.sh HOT 6
- Secure boot for Basic PG2 HOT 2
- High Memory Usage on Docker DotNet core container.
- Consider replacing install-on-emmc with installer stick
- Including .NET Core in the image. HOT 6
- Debian 12 / ttyX30 HOT 6
- IOT2050 - Node-red to Adafruit (MQQT not connecting) HOT 5
- Next release for IOT2050 HOT 2
- Kernel Panic when doing anything Network related
- Build failed because debian packages not fetchable HOT 1
- IOT & Modem sometimes not working well HOT 3
- secure-boot image not booting in iot2050 PG2 Advanced. HOT 6
- Updating V1.03 image to NodeJS 18
- Layers from manifest don't match image configuration
- Network not responding HOT 5
- Unable to read MMAPed memory location for GPIO HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from meta-iot2050.