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.
Any hints on what can be done?
thanks,
Try a different TF card to eliminate hardware.
<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>
Thanks, but didn’t work - the same card works fine with Raspbian as I mentioned. I did not change anything apart from the OS image.
I gave up on the Chirpstack OS and built it up myself over Rasperry pi OS
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.
So far I only tried the “base” (lite) image v3.5.1 (2021-09-20) for the Raspberry Pi 4 (which normally should work on the CM4 module as it is basically an RPi4 missing the mainboard for IO).
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?)
I did a fresh install a couple of days ago of ChirpStack on a PiB+ and it works fine. I followed the installation instructions.
RPi B+ is armv6l. Make sure you have the right architecture download.
As kskenyon already wrote, you need to get the correct image for each version of the RaspberryPi. For the RPi3 line you need to use the images in this directory.
https://artifacts.chirpstack.io/downloads/chirpstack-gateway-os/raspberrypi/raspberrypi3/
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.
I was able to reproduce with a Rpi 4 (not CM). I’ve attached the bootloader log, just in case it’s instructive.
PM_RSTS: 0x00001000
RPi: BOOTLOADER release VERSION:c2f8c388 DATE: Apr 29 2021 TIME: 17:11:29 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1619712685 0x033bfebe 0x00b03114 0x000c4be2
PM_RSTS: 0x00001000
part 00000000 reset_info 00000000
uSD voltage 3.3V
Initialising SDRAM 'Samsung' 16Gb x1 total-size: 16 Gbit 3200
PCI reset
PCI reset
VLI: HUB2: 0xfff00000 0x24e6 MCU: 0xfff20000 0x15218
XHCI-STOP
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
xHC ports 5 slots 32 intrs 4
Boot mode: SD (01) order f4
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD HOST: 250000000 CTL0: 0x00000f00 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
OCR c0ff8000 [2]
CID: 001b534d3030303030101d475709010b
CSD: 400e00325b590000ee7f7f800a404000
SD: bus-width: 4 spec: 2 SCR: 0x02b58002 0x00000000
SD HOST: 250000000 CTL0: 0x00000f04 BUS: 50000000 Hz actual: 41666666 HZ div: 6 (3) status: 0x1fff0000 delay: 2
MBR: 0x00002000, 81920 type: 0x0c
MBR: 0x00016000, 2097152 type: 0x83
MBR: 0x00216000, 2097152 type: 0x83
MBR: 0x00416000, 2097152 type: 0x83
Trying partition: 0
lba: 8192 oem: 'mkfs.fat' volume: ' V ^ '
rsc 4 fat-sectors 80 c-count 20431 c-size 4 r-dir 1 r-sec 32
PM_RSTS: 0x00001000
Trying partition: 0
lba: 8192 oem: 'mkfs.fat' volume: ' V ^ '
rsc 4 fat-sectors 80 c-count 20431 c-size 4 r-dir 1 r-sec 32
Read config.txt bytes 36369 hnd 0x000000fe
Read start4.elf bytes 2231744 hnd 0x0000080d
Read fixup4.dat bytes 5444 hnd 0x00000114
Firmware: a48d332c35ee1c1c1ab433228e23317f62dcc5fb Apr 21 2021 15:47:51
0x00b03114 0x00000000 0x000003ff
MEM GPU: 76 ARM: 948 TOTAL: 1024
Starting start4.elf @ 0xfec00200 partition 0
PCI reset
+
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.
Hi mjohanning99,
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.
I think here is the problem and solution why the image doesn’t boot on our [newer] Raspberry Pi 4 devices.
The Broadcom chip used on the Raspberry Pi 4 got an update know as “C0” stepping last year which is not supported by the old u-boot, etc. if the build is “too old”:
255080 – U-Boot build for Raspberry Pi 4 (arm64) does not boot from MicroSD card slot (freebsd.org)
This is the reason why the ChirpStack Gateway OS image is not working on lots of [newer] Raspberry Pi 4 boards.
My device is reporting this (“c0” stepping)…the actual Raspberry Pi 4 4GB I have here and also my Raspberry Pi CM4 module:
/home/pi# od -An -tx1 /proc/device-tree/emmc2bus/dma-ranges
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
fc 00 00 00
The older Broadcom SOC stepping “B0” reports:
00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
40 00 00 00
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.