04-23-2020, 12:06 PM (This post was last modified: 04-23-2020, 12:15 PM by pgwipeout.)
No joy, it won't get into mainline.
So this is just something the end user has to do if they want to try it.
Also, there is at least two versions of the 2.1 board, since mine is also a 2.1 board and still has the resistors in place.
Edit: If I can get people with all revisions of the board, the 2.0, the 2.1 with the resistors in place, and your variant of the 2.1 with the resistors not installed from the factory, I will push for this to be a rockpro64 specific thing, as long as it works flawlessly on all version of the board.
Edit 2: Never mind, probably not wise.
By the way, does USB C work for you on your board with mainline?
04-23-2020, 01:17 PM (This post was last modified: 04-23-2020, 01:51 PM by kuleszdl.)
Somehow I am getting "Bad Linux ARM64 Image magic!" when loading the dtb file with the 5.6 kernel I compiled. However, the dtb file seems to work with my old 5.5 unstable kernel. With this, Indeed I get the 5 GT/s in lspci as well as a reasonable hdparm speed (860-880 MB/s with my Samsung 970 Evo) which is a clear improvement.
In the end, the end-user will just need to use a different dtb to get this change, right? So it's rather a question of deployment or making multiple DTBs available.
I assume that uboot has no way to determine the correct PCB version of the rockpro64 right? A similar problem exists with the pinephone that also needs different dtbs depending on the hardware revision and is being discussed here:
Edit: I got the 5.6 kernel working (the issue was that I had a zImage but u-boot needed an uncompressed image). I also got to test USB-C and USB 3.0 using a USB 3.1 to NVMe adapter but it does not work (USB-C does not recognize the drive, USB 3 renders "bad/missing sense data and get me just about 30 MB/s".
04-23-2020, 02:27 PM (This post was last modified: 04-23-2020, 03:24 PM by pgwipeout.)
(04-23-2020, 01:17 PM)kuleszdl Wrote: Somehow I am getting "Bad Linux ARM64 Image magic!" when loading the dtb file with the 5.6 kernel I compiled. However, the dtb file seems to work with my old 5.5 unstable kernel. With this, Indeed I get the 5 GT/s in lspci as well as a reasonable hdparm speed (860-880 MB/s with my Samsung 970 Evo) which is a clear improvement.
In the end, the end-user will just need to use a different dtb to get this change, right? So it's rather a question of deployment or making multiple DTBs available.
I assume that uboot has no way to determine the correct PCB version of the rockpro64 right? A similar problem exists with the pinephone that also needs different dtbs depending on the hardware revision and is being discussed here:
Edit: I got the 5.6 kernel working (the issue was that I had a zImage but u-boot needed an uncompressed image). I also got to test USB-C and USB 3.0 using a USB 3.1 to NVMe adapter but it does not work (USB-C does not recognize the drive, USB 3 renders "bad/missing sense data and get me just about 30 MB/s".
Try changing the usbc controller to "host" in the devicetree.
Code:
&usbdrd_dwc3_0 {
dr_mode = "host";
};
I've made a rockpro64 device compatibility page.
Please update it with your successes/failures.
Since I don't want to compile and update my own kernel I thought about only using a self-compiled dtb with the changes. Do you have any experience with using outdated dtb files with newer kernels?
(04-23-2020, 04:52 PM)kuleszdl Wrote: Thanks, I added two of the devices I tested.
Since I don't want to compile and update my own kernel I thought about only using a self-compiled dtb with the changes. Do you have any experience with using outdated dtb files with newer kernels?
Generally the dtbs are pretty stable.
Also compatibility is maintained as much as possible.
I only really change my dtb if I need a specific fix.
(04-22-2020, 08:56 AM)kuleszdl Wrote: My board is v2.1 2018-07-02 and it does NOT have the mentioned capacitors. I am not sure about the jumpers you mentioned but I don't see any wires there. Would it make sense to add them?
My RockPro64 v2.1, with "2018-07-02" (revision date) and "4719" (production week and date) silkscreened on the PCB, came with the 2x2 block of resistors unpopulated, while the 2x2 block of capacitors and resistors is populated. This just confirms that the RockPro64 circuit diagrams available on the Pine64 wiki are outdated.
@tllim and @Luke, could we, please, get the updated circuit diagrams?
(04-22-2020, 08:56 AM)kuleszdl Wrote: My board is v2.1 2018-07-02 and it does NOT have the mentioned capacitors. I am not sure about the jumpers you mentioned but I don't see any wires there. Would it make sense to add them?
My RockPro64 v2.1, with "2018-07-02" (revision date) and "4719" (production week and date) silkscreened on the PCB, came with the 2x2 block of resistors unpopulated, while the 2x2 block of capacitors and resistors is populated. This just confirms that the RockPro64 circuit diagrams available on the Pine64 wiki are outdated.
@tllim and @Luke, could we, please, get the updated circuit diagrams?
RockPro64 v2.1 is the latest one and schematic already posted at wiki site.
(12-17-2020, 10:01 AM)dsimic Wrote: My RockPro64 v2.1, with "2018-07-02" (revision date) and "4719" (production week and date) silkscreened on the PCB, came with the 2x2 block of resistors unpopulated, while the 2x2 block of capacitors and resistors is populated. This just confirms that the RockPro64 circuit diagrams available on the Pine64 wiki are outdated.
@tllim and @Luke, could we, please, get the updated circuit diagrams?
RockPro64 v2.1 is the latest one and schematic already posted at wiki site.
@tllim: Unfortunately, the PDF file you linked above seems to be outdated. Please, have a look at the attached image, which is a screenshot of the page 27; for example, resistors R89508, R89509, R89510 and R89511 are not present on my RockPro64 v2.1 board. This clearly shows that the currently available schematic is outdated.
Could you, please, ask the hardware engineers for the updated RockPro64 v2.1 schematic?
