@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.
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.
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
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.
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.
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.
@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.
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?
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.