I read your post, what are you running that is crashing the kernel?
We are live testing a server and desktop using the “stock” image. Both are up 24/7 and not having any problems.
unfortunately, i was running absolutely nothing. Just logging in via ssh a couple of time per day to see if all was fine. When I saw it was instable i decided to park the machine a few months and wait a bit. Now i may try to restart it, upgrade everything and give it a second run.
My self I would laydown a fresh image, apt update, then go from that point. Also, keep a list of packages you installed, this will help in finding out what is breaking the system.
If you are running NVMe this is a good way to set it up.
NVMe/emmc boot
i just tried. I can tell you this
- My old release was a IoT, nothing at all installed, kernel 5.19-109-ti-arm64-r49, I run it via serial console, looged in via ssh using the debian user. It lasted 20 minutes and then it hanged. I attach screenshot of the console.
- In upgraded everything, now it is running since a few hours. I will keep it up in the weekend and see what happens. Now the kernel release is 5.19-153-ti-arm64-r86.
1 Like
Its actually 5.10. Have 3 of them on that same r86 release. One is handling a LAMP stack the other is a general purpose server and another is desktop. Pretty sure you will have good results.
1 Like
yes confirmed working:
. typo, my current kernel version is 5.10.153-ti-arm64-r86 as you say
. the machine survived the weekend, powered via USB
1 Like
One thing the community could do is make a Beagle with CM4 footprint and let the user decide which processor
We could even work on a CM4 board with a TH1520
2 Likes
Those use kinda expensive connectors, no?
I seem to remember an RPi module of some form that used two M.2 connectors. Consequently, the compute module was mega cheap (since it only had edge connectors). The other advantage was that M.2 connectors are pretty cheap nowadays.
Unfortunately, I can’t seem to find that RPi module anymore. I wonder if I just imagined it …
Edit: Found it! It was a RISC-V board, not an RPi.
It was the Sipeed Lychee RV:
https://linux-sunxi.org/Sipeed_Lichee_RV
1 Like
Yes they are comparatively expensive. It doesn’t seem to have stopped lot’s of companies from adopting it as a ‘default’ standard.
I think you’re thinking of the older RPI CM3. That was somewhat adopted too, but is much larger and lacks the adoption of the newer CM4
I like the addition of mikroBUS shuttle connector.
What are U1 and U18?
What is the point of having the Ethernet cut-out?
Why not use the BeagleBone mounting screw hole positions?
Won’t having the Pi Header where it is at mess with mechanical compatibility with BeagleBone systems?
Have you considered starting from the EAGLE BeagleBone Black Wireless design?
Have you done much thinking about how BeagleBone header pins map to the CM4 pins?
Honestly, there’s a reason I’ve as-yet stuck to SBC form-factors rather than modules, but, if something has enough traction, I’ll pay attention.
1 Like
@jkridner if/when you do another design, could you give some thought to low power usage. I like to see a small companion mcu to control power to the main processor, something that uses micro amps when sleeping, but can be woken up by some dedicated I/O, with a battery backed real time clock preferably. Something that talks I2C or SPI to the main processor. Would need SWD pads to allow programming of said micro. It could come with some simple software that justs boots and turns on power to the main MCU. Of the hardware could be designed to switch on main power if nothing is programmed into the micro,
I suppose you could add that functionality to a cape as things stand and run the power through the cape, but that would mean stacking capes if you require I/O from the Beaglebone. Just a thought.
1 Like
This was just a very quick concept, I didn’t have the black footprint to hand in EasyEDA. Is it available somewhere?
U1 = USB-C
U18= Qwiic
The Pi header could be a pain, but also gives you access to a lot of nice hats. Users would have to stack headers to ensure it cleared the BB & any capes, using standoffs to make it secure. If since found this RPI cape which does the same job. An open hardware version of that would probably be more sensible than trying to mash the header into this board
I’d not seen the BBB eagle, I’ll have a play with the footprint. In terms of Ethernet, I think we’d want to provide Gigabit on this board?
I’ve been shaving some robotic yaks, I will do a little more work on this concept.
@benedict.hewson I did also kick around a concept for a MicroMod based BeagleBit that might be able to do the wakeup thing.
In the short term I think an RK3588S OSHW CM4 board would be interesting. Essentially a clone of the Radxa CM5. 3588S has good Ubuntu/Debian support & Armbian it would make the board useful and outperform the current Pi offering.
If anyone is interested in helping with this CM4/Beaglebone idea I created a table in the Github readme to map the CM4 pins. Any help with populating that would be welcome. Anyone can create an account there.
The pin table is in this BB CM4 Kicad project which contains
- Schematic with main components
- PCB file with BB and CM4 footprints
Have you thought about doing an AM243x based board ?
Probably the biggest differentiator between the various BB boards and the other SBC’s out there are the PRU units.
Not sure what the demand would be for something that doesn’t(can’t?) run Linux.
It would probably be harder to get up and running for someone not used to programming embedded systems.
There isn’t to much out there between the ST black pill type boards and a GHz Linux based SBC’s, I suppose there is the Teensy at 600Mhz.
1 Like
any successor to BBB would have to have a power rail (both 3.3v and 5v) as the BBB does… one of my disappointments with the BBAI is this lack, making it purely a dev board requiring external power for electronics work. Also, the USB power is barely over 4v (with 5v 3a supply).
earlier mention of usbC pd is interesting for this type of power rail.
Pi’s are much further along for linux work, in lots of ways… that the BBB has PRU’s with their OWN memory is the plus that makes BBB attractive
jumping through hoops to reclaim memory allocated to remote procs is a pain. I’d like a image for the BBAI that comes configured with the 1GB available
gomer
1 Like
What seems like another good idea would be to drop ARM all together and go with an amd64 based board. Something with low power consumption and cool running.
Multiple FAST Ethernet ports,
NVMe slot and second slot for either a wifi board or secondary NVMe drive.
On board dedicated UART controller & SPI.
Connector for optional battery back-up realtime clock.
Multiple USB ports with header access and have 2 of the connectors on the board.
A decent video chip and full size HDMI connector.
Also, solid Debian support.
We don’t have large group of programmers that can spend an excessive amount of time on stuff, ARM is not moving us forward. Just cannot spend weeks trying to get stuff to work then wait and wait and wait for updates.
Running a strong core with very deterministic and intelligent peripheral devices managed by the kernel is a better solution.
1 Like
We need something that makes the BBB a bit better, but doesn’t blow the thermal and power budgets out of the water like the BBAIs both do.
It seems like the AM64x series would probably be a better match for being a successor to the AM3358 (Edit: Misspoke. Originally labelled that AM3359). It doesn’t gain much in speed, but it gains a second processor and it gets a nice chunk of extra co-processors while bumping the PRUs up to 333MHz.
The starter kit (SK-AM64B at $99.00) is a pretty good start by itself; it just needs some support.
I’ve toyed with the thought of making a “compute module” kinda thing out of the AM64x stuff, but the power requirements are a complete PITA like any of the TI SoCs. Couple that with continuing inventory issues (try and find a LM61460 or a TPS65220–LOL) and it’s difficult to justify the time and expense for something that might not gain any traction, anyhow.
1 Like
I realise it’s not only about popularity, but looking at trends it seems things are going well for OrangePi I wonder what they’re doing right