TonyMac32
-
Posts
2409 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by TonyMac32
-
-
2 hours ago, bedahtpro said:
20W apple charger:
5V at 3A
65W Nexode Ugreen Charger:
65W Max
USB-C1/C2：5V/3A 9V/3A 12V/3A 15V/3A 20V/3.25A 65W Max
PPS：3.3-11V/4.5A
USB-A： 5V/3A 9V/2A 12V/1.5A 10V/2.25A 22.5W Max30W Lencent International Travel Charger:
Single USB : 5V 2.4A
Type C Port: 5V 3A (MAX)
Total Output: 5V 3.5A (MAX)
You don't have any "dumb" power supplies?
Any USB-type -C style charger will limit to 450 or 900 mA without a "smart" device attached to it, irrespective of it's rating. (it requires a matched supply/cable/endpoint configuration to get 5V 1.5 or 3 A)
*Most* QC- compatible (USB A output) will also limit the current unless they detect the correct QC-style resistances on the endpoint.
You wouldn't happen to have a USB power meter on hand to see if these supplies are throttling the USB-A based on the fact the device has no "smart" charging built into it? I just measured mine and with keyboard, HDMI and network attached I broke 600 mA peak. If the supply had throttled to 450 mA it would have crashed right after loading the kernel. Otherwise I think you need to talk to LC and see if they can debug the issue you're having.
-
I flashed my image to USB stick using balena Etcher, so I skipped half the steps (extracting/etc). Since I'm an EE and I'm running out of ideas, can you humor me with the exact specs of your power supply.
-
hmm. Mine is a 1.0A, although I don't think there's any real difference (I don't have a switch for selecting boot mode). Do you have an eMMC installed?
-
ok, so next step, you say you wrote to an SD card, since there's no SD slot on this board, are you attaching it through an SD --> USB adapter?
-
🫣 Let me take a look.
[EDIT]
So far I don't see an issue, I booted an image with no errors on my La Frite (1 GB). My guess is, you have old firmware on the board itself. The Armbian download page fir la frite includes instructions on how to update the spiflash with Libre Computers most recent binary. -
8 hours ago, Igor said:
"slow-hdmi" is reserved for armhf
Eh, it's a logic that can't be properly managed. The XU4 and Tinkerboard (both armhf) have GPU's that run circles around RK3328, S905(X), H5, etc. I'd say leave it alone, after all the experience should be up to the user anyway. Because then you also need to start talking about RAM, and it just gets out of control.
-
5 hours ago, Igor said:
its an old horse.
And it's running the wrong race if you're trying to get fancy with desktop environments.
The current 6.6 also works just fine, no HDMI issues with Cinnamon.
-
Sorry I didn't notice this post earlier, notifications get buried fast 👀.
I haven't tested cinnamon on anything with a Mali450, TBH that GPU just isn't up to doing anything useful since it's target audience was 720p devices. That's not to say it *can't*, I just didn't expect anyone *would*. All of my tests have been with xfce and have been fine. Let me do a quick Cinnamon build (is this a download option now?) Rich, or @criageek, needed to provide an armbianmonitor -u or at least a dmesg.
[UPDATE]: Built/tested a new 6.12 edge image with cinnamon, worked out of the box with no issues. -
sorry I didn't see this, and you had to buy some berry trash instead 😐
-
unfortunately, in my experience, Samsung *in particular* does not play nice with SBC's
-
14 hours ago, ebin-dev said:
You should be very careful with Armbian updates until Armbian on Helios64 is maintained by someone.
Fully Agree. I might have a replacement for the Helios64 on the way, if/when it arrives I'll be able to do some tests on the Helios64 as it won't be my active machine, but as you see above I haven't updated in a *long* time.
-
10 hours ago, desperex said:
Did anyone try to port collabora's patch for rock5b?
Not so far, I stuck the tree for this board in mainline and it will be available with 6.6. I haven't messed with the USB3 yet, the collabora kernel is my secondary interest for this board, and, since I don't really get anything out of it, the board isn't my first priority either outside of personal interest.
I'll look at lowering the eMMC frequency, but some actual testing for errors will be needed to make sure 150 MHz is truly "good" and not just "tolerably bad" for the driver
-
On 8/16/2023 at 6:47 PM, Patrick Pesch said:
param_spidev_spi_bus=0
param_spidev_spi_cs=0
param_spidev_max_freq=1000000is entirely dependant on the device tree overlays handling fixups, or is that RPi style syntax?
In any case I already found an issue with the overlays for this family (spi-spidev overlay as written is in fact only applicable to rk3399 https://github.com/armbian/build/issues/5778) , I'll add one for rk3328 spidev, it will not work the way you have above though since fixups are super hacky.
-
Libre Computer Renegade
- Boot, all USB, Gb NIC, desktop
Missing audio
-
-
Le Potato
-boot, hdmi audio, USB, NIC
Tritium H2/3 and H5
- Boot, NIC, USB
-
Raspbian has it's own things going on, and is using the Libre Computer kernel, tuned for their boards. I will need to take a look and see what has disturbed the Le Potato image in our distro, it's not immediately obvious but these boards share kernels with a lot of devices and sometimes we step on each others toes.
-
Hello switch,
While the RK3328 does have the hardware, the crypto patches have not made it into the mainline kernel yet: https://patchwork.kernel.org/project/linux-rockchip/list/?series=680902
As a result the hardware crypto won't be available. That patchset infers it is identical to the crypto module in the RK3288, so as long as the RK3399 parts of that deries don't tie it up, it should be applied soon.
-
hello @cyborg_fox, please try to download the image now, I believe the issue has been corrected, there was an issue with a u-boot update. New image was created as of the 7th.
-
I've had trouble supporting this board, a lot of "s" variant boards in particular do not like to boot using mainline ATF. The only reason there are mainline images is because I created a device tree/got a supply driver/etc. The DP over type C should work provided the device tree is updated, you can find examples on several other RK3399 boards we support.
-
Right, confusing is, they were correct for quite some time, so my curiosity is: What changed? Perhaps someone updated for one of the newer boards without checking for collateral damage.
-
uuuuuuuuugh
-
Are you trying to power the board via the GPIO? I don't think there is a GPIO to shut off the 5V pins from within the board itself.
-
40 minutes ago, NicoD said:
First off, the VIM3 has all its cores clocked to 1.5Ghz by default.
https://github.com/armbian/build/blob/master/config/sources/families/include/meson64_common.inc#L20
This is the default for Meson64. No one added the actual top speeds for the Vims apparently
https://github.com/armbian/build/blob/master/config/sources/families/meson-g12a.conf#L5
is the override for the Meson G12A. G12B needs something similar in here: https://github.com/armbian/build/blob/master/config/sources/families/meson-g12b.conf
xorg.conf.d drop-in needed for Sweet Potato Xorg to start up
in Libre Sweet Potato
Posted
LMAO at marking tagging me "Solution"
In any case, I completely forgot about This complete catastrophe.
I'll make an entry for Sweet Potato, but probably more like it is to simple check for family = meson-gxl, OR *gasp* put it in the individual board configs to avoid bloating the build systems common entities.
Family configs are the stuff nightmares are made of. - https://github.com/armbian/build/pull/7668