How about a REAL successor for the BBB/BBG?

@jkridner I would certainly be interested in swapping my heatsink if that ever becomes possible.

One other thing I should also have mentioned are the serial console/fan headers.
I know space is very tight on the board, but the tiny connectors are a real pain. I have used many dev boards with similar or smaller connectors before, and things are usually ok if you just plug a cable in and leave it alone. However all to often due to the very small size of the cable and crimp, it is very easy to break a wire.

Given the size it is almost impossible to self crimp theses connectors. A standard 0.1" pin header would be so much better.

This is more of a problem on the two serial headers than the fan header, as they are far more likely to be removed. Plus if the board comes with a heatsink & fan, I assume it will also come with a connector for the header.

It would be nice if at some point in the design, some information was made available for comment by the community.

Curious, what are the problems with powering BBAI-64 using the USB-C connector? I have only used BBAI-64 powered by USB-c and has not experienced any power issues so far. What problems should I expect and when do they happen?

From my understanding and a little Googling for a USB3 type A port, the host must supply at least 900mA to meet USB3 specs. If the host is type C, then it is 1.5A.
The quality/length of the USB cable will also be a factor.

The BBAI64’s USB C is not PD compatible, so that excludes the higher power available there.

There are a lot of cores in the BBAi64 and I think somewhere in the docs it is recommended to use at least a 5V, 3A supply.

I tried powering my board from USB and it wasn’t even booting. That was connected to a type A port on my laptop. It looked like it was stuck in a boot loop reset situation.

I bought a USB C → USB C PD cable rated at 65W and powering the BBAI64 from the USB C port on my laptop did work, but again it was just sitting there doing mostly nothing. This was the minimal non desktop image, so no GPU running consuming power. This cable was visibly much thicker than the USB A → USB C cable i tried to start with.

If the board does not get enough power then this could lead to lockups, reboots or just some random instability. It will depend on how close you are to the limit. There should be some sort of brown out reset in there somewhere. If the board resets while writing to the eMMC then there is going to be the potential for corruption there.

I would always use a proper DC adapter to power any board if there is the option to do so. I would also chose any dev board with a separate DC input over a USB only power board.

The original question was about a compatible successor of the BBB/BBG, not about some specific cooling/powering problems of the BB-AI64. So would you mind opening an own thread for this OT-discussion? This would help to keep the focus on the original question in this thread.

Thank you :slight_smile:

Had an interesting issue here, the lab power supply was folding back at a much lower current than what was indicated on the front panel. We are using NVMe on the boards in testing and they are now doing fine with a stiff wall adapter, if memory is correct they are rated at 5 amps.

Power supply regulation is also important.

I must say i remembered badly a conversation I had some time ago with Robert, what i said was not accutate. The problem is not only with USB powering. (maybe it has been fiexd, it is a few months i am not experimenting). See here

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

Mutant concept to take Capes or Pi Hats, or mikroBUS peripherals

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.