teenytinycactus
-
Posts
15 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by teenytinycactus
-
-
-
You can also use the release built by CI from https://github.com/armbian/os/releases/tag/23.11.0-trunk.15
Although I have installed Armbian_23.11.0-trunk.15_Rock-5b_lunar_collabora_6.5.0-rc1_minimal and it, like all the current releases except legacy, do not boot/show a display. Is this likely a uboot issue or is there an issue occurring within the image build process?
I think the last image I could find that wasn't legacy that could boot was Armbian_23.8.0-trunk.309_Rock-5b_lunar_midstream_6.2.0-rc1_minimal, albeit the pci-e wasn't working correctly as the intel wifi chip errored.
-
I am trying to get a RPi camera (imx219) working on a RockPI 4C. I have been piecing together DTS files from various places trying to make sense of it, and I noticed that the rkisp kernel module isn't compiled on the Rockchip64 kernels. Is there a reason for this or am I missing something?
Looking at the kernel menuconfig, only one of its dependencies isn't compiled: `V4L_PLATFORM_DRIVERS=n`.
-
I finally got around to fixing my board. Works well now! Shocking solder job though :o.
On 7/25/2019 at 12:19 AM, 5kft said:OK, I'm glad you figured it out! I'd be happy to document this all somewhere consistent (right now the instructions are buried in various posts in these forums, done as it evolved), but I'm not sure where that somewhere should be...
How about here? https://linux-sunxi.org/Xunlong_Orange_Pi_Zero_Plus_2 I notice there are still no mentions on the wiki of the missing MOSFET.
-
18 hours ago, km1kze said:
You can also see a J1 marking on the original mosfet from the orange pi zero H2+
https://www.toysforscience.com/wp-content/uploads/2017/08/1482138186-1.jpg
Ah interesting! Thanks for pointing that out. That's a bit reassuring.
10 hours ago, 5kft said:Decoding SMD part codes can be an interesting exercise
Unfortunately my AliExpress order for these parts had an issue and was never delivered. I ended up ordering a set of BSN20s from Digi-Key in the U.S. (https://www.digikey.com/products/en?keywords=BSN20-7DICT-ND).
Of course I can't promise that any of the following is applicable in general, but at least for my parts it seems to work...:
My parts have the codes "N20" and "E9" on them. Doing a quick Google search for the package type (SOT-23) and the label on the part (N20) - i.e., "SOT-23 N20" - turns up this page: http://www.s-manuals.com/smd/n2. Looking in the table one can see two BSN20s listed, with the associated data sheets. From the data sheet the "E9" is a date code, so it looks like my parts were made in September 2017 (which seems reasonable).
If you search for "SOT-23 J1" you'll see this page: http://www.s-manuals.com/smd/j1. Looking in the table you'll see lots of SOT-23 J1 devices. Assuming that your part is in fact actually an N-Channel MOSFET, there are two entries for BSS138s...so that might be the part you have. You may want to download the datasheet (http://www.s-manuals.com/pdf/datasheet/b/s/bss138_taitron.pdf) and compare the part specs with a standard BSN20 datasheet (e.g., mine is https://www.diodes.com/assets/Datasheets/ds31898.pdf) to determine if it might work okay...?
Hi 5kft,
I did stumble across this site and datasheet when trying to find info about the component. Comparing the two datasheets it seems that the BSS138 has somewhat higher source-drain on resistances and a slightly higher threshold min. rating (0.1 V difference). I might try it and see what happens, just hope my solder isn't too thick for SOT23 soldering.
Thanks guys.
-
1 minute ago, km1kze said:
Don't remember what was written on them, but if you bought from my link, they're good
I do trust you, I am perhaps a bit concerned I was sent the wrong model.
-
Can anyone please confirm the markings on the transistors they received from aliexpress? I bought from a link in this thread and it has "J1 6" on it. Is that.... suitable? I'll probably hold off soldering it.
-
On 5/7/2018 at 11:58 PM, fabbronet said:
Hi @teenytinycactus, I lowered maximum frequency down to 816MHz and I didn't experienced any random crash from that moment. I think that lowering frequency did the trick but in the same "moment" I found some crashes of mongodb server that's installed on my system. I think that mongo was not the problem but that's it. At this time I'm fighting with log2ram that fills up to 100% messing up everything on reboot because most services see that as a write protection for their own log files, actually I don't know if tweak the logrotate or the log2ram maximum storage dimension....any advice?
Sorry I don't really know much at all about those issues.
-
Hi @fabbronet, I think you will find your issue is related to this:
Have you tried setting the CPU frequency to 800MHz and then try to crash it?
-
This is really quite interesting. I have the same board and issues. I had been running at 900MHz to avoid the crashes, until someone skilled came along and worked out why it wasn't operating properly. Pretty curious as to why Xunlong broke their boards this way, I guess a replacement is out of the question? ?
-
11 minutes ago, bortolino said:
If RAM is fine it could be a microSD problem. Have you tried to change it?
Have you got sporadic kernel panics?
I am not sure if they are panics, but the device does hang fairly often when under stress (it has hung just now doing the memtest). I am currently using the serial interface provided via the microUSB (yes I understand this isn't a good idea and the problem might be PSU issues and/or voltage drop, I have ordered new parts and cables to rectify this.). If I connect via the UART0 serial, will I see the kernel panic output?
I haven't tried another microSD as this is a brand new one from a brick and mortar store. It also worked flawlessly on the RPI Zero W.
Also thanks for your help.
-
7 hours ago, bortolino said:
sudo memtester 400 10
Could you try to run the hash script I posted earlier? On the faulty board I had inconsistent results.
I ran also for 400 MB, and loop 1 was fine. I will leave memtester running for a few hours and see what happens.
I did run the hash script for about 20 iterations - all the md5s were the same.
-
5 hours ago, bortolino said:
I moved the SD to a new board, and problems disappeared!
According to memtester I had a (very) faulty ram brick.
I am doing a memtest now and mine seems to be okay. Could you please advise on the arguments you used for memtester?
-
I got this error when I did update&upgrade on the same board, EXCEPT it only occurred for the kernel. I also got compression errors when I was pulling down the ROS2 git repositories. Are you using WiFi?
Mainline kernel
in Rockchip
Posted
After finally getting a new Rock5B I tried with the collabora release (rolling), and it looks like the intel AX200 I have in the PCIe M2.E slot has issues loading firmware.
Looking forward to complete mainline support for this board as it's quite feature packed.