Hello, I tried the chirpstack OS full and base images on the RPi4 (2GB) however it does not boot at all – even with a valid HDMI/ Keyboard connection. Nothing on the screen nor on the console. On the same setup any other raspbian boots like a charm.
<rant>One ding against RPi is that they elected to use TF cards, instead of SD, which I find to be difficult to work with, if one expects predictability & reliability. For one, card readers for TF format are finicky and have short lives, in my experience - I have 6 that I try in turn, even with known-good card! Cheap & great value but a PITA, usually :-)</rant>
This is nonsense. TF is a predecessor standard name, you’d be unlikely to find to find one remotely large enough. That modern pis use a micro form factor SD card rather than a full size one is not practically very relevant, since the internals are often the same and more than a few first generation pis were run with micro cards in passive adapters.
It is true that an SD card is not a very robust solution for a field deployed embedded system - eMMC or well engineering explicitly managed NAND is better than the near unknowable mystery of what goes on inside a consumer SD card. More compact Linux platforms of the sort chosen for purpose built gateway products can often be run by initializing a ramdisk from robust NOR flash, but it just plain takes too much code to make a pi work for that to be practical. The pi compute modules do have a more useful range of storage options.
None of this likely has anything to do with the actual issue of this thread, which is probably related to how the card image was downloaded and written to the card. In particular some writing schemes want to start with a card containing a single FAT partition rather than one that was previously partitioned for use in a pi.
While back in 1999 there was a difference, these days TF & micro SD are used interchangeably for the same hardware. I purchased several of these 128GB TF cards in the last year. But I see your point: article is labeled only with microSD not TF. I shall spank myself with a wet noodle for my sin and not make this mistake again
P.S. I’m so enough that I mowed grass all summer for a 64 kB upgrade card for my Apple //e; maybe Uncle Alzheimer is a callin’?
I have the exact same problem, none of the chirpstack gateway images boots. Tried with two different SD cards (64Gb) and even a USB stick, no go. Ubuntu and Raspbian boots with no problem. Raspberry pi 4B with 4GB, and a waveshare SK1302 LoRaWAN Gateway HAT.
I have the same issue but with an Raspberry Pi Compute Module 4 (CM4) with eMMC and wanted to create a new topic but then I saw this one.
At first I assumed this is related to the CM4 and it’s eMMC storage somehow but now I don’t think this is the case. As I don’t have the “normal” Raspberry Pi 4 I can’t verify this.
The /boot files in the image indicate that is should support the CM4 CPU module.
EDIT-1 (2021-12-22 17:10 CET,+1)
I’ve now tested the following basic images…
Raspberry Pi 4 Image v3.5.1 (2021-09-20) - Does not boot
Raspberry Pi 4 Image v3.5.0 (2021-09-02) - Does not boot
Raspberry Pi 4 Image v3.4.0 (2021-05-10) - Does start booting but ends with Kernel panic (does NOT include *.dtb file for CM4) EDIT-2 (2021-12-22 18:10 CET,+1)
Raspberry Pi 4 Image v3.3.3 (2021-01-06) - Does start booting but ends with Kernel panic (does NOT include *.dtb file for CM4)
EDIT-3 (2021-12-22 18:55 CET,+1) Created a bug report at the github repo:https://github.com/brocaar/chirpstack-gateway-os/issues/81
Feel free to comment on that one especially if you have a “standard” Raspberry Pi 4 as I can only come up with the Compute Module 4 version of it.
Same issue with a Raspberry Pi 3 B+, 16GB SD cards.
Maybe missing required kernel images on boot partition? (“official raspberry Pi OS” contains images for more architectures?)
The issue reported above is related specifically to the RPi 4 line (which includes the Compute Modul 4).
Maybe it’s possible for the thread creator or moderator to change the title so the title reads “ChirpStack OS - Raspberry Pi 4 (and CM4) - Does not boot”.
Many thanks in advance.
So far the Github ticket for the ChirpStack Gateway OS has been ignored (no comments added within the last 12 days).
EDIT: Orne added a reply to the github issue I created (see link a few messages up). I also just bought a RPi 4B with 4 GB RAM myself (for a ridiculous price) to verify the issue with the “officially” supported hardware. An update will follow end of the week when it arrives.
Thank you for the bootloader log.
I actually don’t see any specific issue except for maybe the PCI reset at the end, but maybe that’s normal for the yocto based images.
Just looking at the package tracking details, it seems the ordered RPi 4 with 4 GB RAM will arrive tomorrow so I can check it too (with a standard microsd as well as the “RaspiKey” (eMMC memory module with microsd connectors)).
Right, me either. I diff’d it against a boot where it succeeded (from Raspberry Pi Imager), and it was all pretty minor stuff. I haven’t tried copying start4.elf from a good image to a bad one yet, though. One could also compare the md5 of a good and bad start4.elf.
I got my Raspberry Pi 4 with 4 GB RAM today and flashed the 32 GB microSD card with the ChirpStack Gateway OS Base image and it shows the same issue. I wasn’t surprised that it shows the same behaviour as my Compute Model 4.
The colored square is shown on the connected screen and that’s it. The system seems to crash quite early in the boot process so we not even see some text output on the screen.
So in total we now have 4 people who reported the broken image for the “standard” Raspberry Pi 4.
Plus 1 person (me) who reported it also for the industrial version also known as the “Compute Model 4” (not officially supported by ChirpStack but the overlay files so it should work are on the image…so it will work once the general boot issue is resolved).
I’m looking into the logs when I’m home and can use my Linux system.
Same problem with rpi4b, 16GB micro-sd and ChirpStack Gateway OS Base & Full image (3.5.1).
I try to mount an TTL / USB Cable on the RPI Header to be able to see the boot sequence without success, no messages on the console.
I have the exact same issue, unfortunately. It works on the Pi 3, but the images for the Pi 4 appear to be entirely borked (3.5.1). Anyone found a way to mitigate this? Would be quite helpful.
unfortunately there is not yet a solution.
As I don’t have the time to get deep into the ChirpStack Gateway OS issue I’m now using the self-compiled RAK gateway.
As I have a RAK gateway concentrator USB module here it made sense to try this and it is based on a plain Raspberry Pi OS installation.
The RAK stuff (based on Semtech code and UDP packet forwarder) also has some issues and other side effects for the project I’m working on, but at least I was able to make it work (Gateway ping to ChirpStack server instance works, Packages have been received).
So far I don’t know how “stable” this solution is. Currently it still floods the syslog which is bad (even if you are not using an SDCard which would be dead pretty fast).
Yah, I’m using the RAK Gateway system too. So far it has been stable. I just got another gateway board to use with my Pi3 so I can move forward with the ChripstackOS. It’s likely that I’ll be only using the chirpstack as a template, and using recipes from it.
So the solution to get the ChirpStack Gateway OS working again is rebuilding it again with an updated Yotco (with new u-boot) underneath.
If you have the newer u-boot files (for yocto?) it might be possible just to replace that part.
Only a small update.
The new Gateway OS test builds with the updated Yocto Linux OS look promising.
The newer Raspberry Pi 4/CM4 (with eMMC) that use the updated Broadcom SoC are now booting without any issues.
I suppose the rest (the ChirpStack stack) is also working. I didn’t have the time for a full test yet.