TonyMac32

Yes, this. So, there are several different RK3288's out there, the kernel supports them all as one. Only the RK3288C can do 1.8 GHz officially, and that is the one in the Tinker Board. Apparently the patch adding the opps has not been applied correctly. May I add that I believe this is being corrected upstream for the Tinker Board, I saw it mentioned on the mailing list.

I'm afraid not. :-/ @mboehmer you say only the later board revision? Very odd. [edit] https://wiki.odroid.com/odroid-c2/hardware/hardware EL-1709 rev0.2 20170830 The schematic is 100% identical to rev0.2 20160226. however, PCB manufacturers are different and some signal patterns were reinforced and modifed to improve productivity. EL-1801 rev0.2 20171114 Added a 0Ω between USB Hub IC and load switches. To disable the USB over-current protection, you need to remove the 0Ω resistor. I don't know what this would have to do with the eth0 interface. Sent from my Pixel using Tapatalk

ahhh, ok. I would have to check on that, I'm not sure

As stated, the 12V rail (feeds the mezzanine) is run by a buck/boost converter with no mainline driver, so it sits at 5V instead of 12. (4.67 volts, in my case). The board would always boot with a large enough "dumb" supply, but a USB- power delivery supply would default to ~400 mA and fail.

So far what I'm seeing is dt slop (on all boards using this chip) 1) lack of a connector node, which, when added, brings along lack of port nodes for the connector IRQ errors (related how? no idea) 2) lack of "op-sink-milliwatt" property Once op-sink-milliwatt is added it will boot, which leads me to believe the chip is receiving commands from the driver, however probe fails with "failed to register tcpm error -22" I haven't gotten past that, so 5V only, no mode switching. And I am not immediately inclined to write a driver for the dc-dc converter. ;-) My current device tree entry: &i2c7 { i2c-scl-rising-time-ns = <600>; i2c-scl-falling-time-ns = <20>; status = "okay"; fusb0: usb-typec@22 { compatible = "fcs,fusb302"; reg = <0x22>; interrupt-parent = <&gpio1>; interrupts = <2 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; vbus-supply = <&vcc_vbus_typec0>; usbc_con2: connector { compatible = "usb-c-connector"; label = "USB-C-0"; power-role = "dual"; sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM) PDO_VAR(5000, 15000, 3000) PDO_PPS_APDO(5000, 15000, 3000)>; op-sink-microwatt = <25000000>; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; usb_con_hs0: endpoint { remote-endpoint = <&u2phy0_otg>; }; }; port@1 { reg = <1>; usb_con_ss0: endpoint { remote-endpoint = <&tcphy0_usb3>; }; }; port@2 { reg = <2>; usb_con_sbu0: endpoint { remote-endpoint = <&tcphy0_dp>; }; }; }; }; }; }; [edit] I want to be clear all the port definitions could be nonsense, the documentation is a bit thin on all sides of this. One thing I'd like to consider is the interrupt type, even though the fusb302 specified it's interrupt pin is active low... @Neil Armstrong, in case you have some insight into this.

There is special driver work done in their kernel to cover an unsupported I2C buck/boost converter that provides the 12V rail on this board, and for reasons I'm digging into, the fusb302 driver is a complete mess after they moved it out of staging, it has a lot of odd behaviors and a completely new set of requirements for the device tree. I temporarily ran it back to the staging driver for our mainline expert builds (limited improvement), but am working on the proper driver.

I haven't read up on this one yet, but if it is like La Frite in structure, then yes.

OK. I mis-read on my mobile what uname was printing out.

What is this kernel, self-compiled? Sent from my Pixel using Tapatalk

I leave for family reasons for a few months and look at this place.

Placeholder for Libre Computer La Frite general topics Marked "Supported" as of Nov. 24, 2019 Reference pages: https://libre.computer/products/boards/aml-s805x-ac/ https://forum.loverpi.com/categories/libre-computer-aml-s805x-ac https://drive.google.com/file/d/1Dl3lLTs407OZ7HhPYjjlvDX2_FPfKHMr/view

I am proposing after decision is made on a board to close the thread for that board in this subforum. Please pose any questions relating to this board to the appropriate support forum. (In this case S905(X), as S805X is the same family)

Good. It is not the simplest thing to find the firmwares. Might also want to (I can do this if I remember the credentials) put a note about flashing the eMMC, which USB port is important, and unplugging the A - A when finished because it really corrupts things if you don't (ask me how I know) @Igor Oh, forgot: I tried to install the full desktop/etc from the minimal image, it was not amused, lightdm failed completely. I didn't really have time to diagnose the issue I'm afraid.

Just built/tested desktop Bionic for this board, flashed to eMMC and from USB, added topic in "Bring-up" to move it to "Supported".

I know there is a template, but this board is already on the download page as unsupported, just ran a group of tests on it after building a full desktop image, I think we can move it to supported without any issues, the S805X is the same as an S905X with some things turned off, like comparing an H3 and an H2+. Pros: SPI contains u-boot, we don't have to do anything with that. Libre Computer updates the firmware periodically (available on their site) already supports USB boot, etc, and has a "press escape for menu" option, making it very difficult to brick. UMS mode is menu selectable (I feel like we need to look at this. I have booted Armbian from both USB and eMMC using the SPI bootloader without issue Board has no special hardware that isn't part of the SoC, so as long as mainline support for the SoC remains, should be minimal support Amlogic devices are being cared for by BayLibre Cons: less powerful than other Amlogic powered offerings will bring "bought the cheap one need support" crowd (not that that's unique)

I liquid cool my XU4 [emoji38] if I had the HCx it would probably be better off, but nowhere near as cool. ;-) The N2 has some patches to fix the USB3 to my understanding. I haven't tried them just yet, or perhaps Igor has integrated it already... The Renegade Elite has an add-on board for nvme and a wifi, and a nice case with giant heatsink that should dissipate far better than the M4 (but is generally larger). All that said, the XU4 and relatives are still king for all-around performance and software support. I have the big heatsink one set up for retro gaming, if(once) the RK3399 or s922 are finally properly supported (looking at you Rockchip, shame on you for your RAM bullshit, and Amlogic, one word, "blobs"). Sent from my Pixel using Tapatalk

The HCx's are XU4's purpose built for server work. Nice hardware. I use an XU4 now, considering the N2 once I verify the patch I saw actually fixes USB3. Sent from my Pixel using Tapatalk

That would be pretty interesting to debug, I've always been horrified at the "division of labor" between the two, sometimes U-boot configures some hardware and the kernel just assumes it's there, sometimes not, no standard... Drive levels are a possibility, perhaps the 4.4 kernel is assuming U-boot configured the I/O levels, or maybe a regulator is being set up in FriendlyElec's u-boot that isn't in mainline. All I know for sure is I want anything with RK3399 in it to behave logically and consistently, which seems too much to ask most of the time...

Welcome! I am an EE who primarily did assembly language work/ microcontrollers before this. Also, excellent name. [edit] do you have this? https://www.digikey.com/product-detail/en/stmicro/STM32MP157A-DK1/497-19037-ND/9990056?WT.srch=1&gclid=CjwKCAiAws7uBRAkEiwAMlbZjtyct1CX2zPW8XrI1Xrld6Rle6ew3tsgtcCvtsccpYZ9lLNx1LNmrRoCUIcQAvD_BwE

"SIM-Karten". I immediately distrust it's country of origin. which board(s) have you tried it with?

That Linux stick thing is cool, what were they hoping to do with it? Sent from my Pixel using Tapatalk

Sigh... My guess (entirely guessing, I have not looked yet), is that we or Mainline fixed the Rev 3, which broke the Rev 2. I am not entirely pleased at the significant hardware changes made by Pine in this case, it is causing problems...

Thank you for the update, I'll have to take a look, I thought the patch was there, I might be able to look at it tonight (I've been out of the office for a while)

Same! Life has been a bit tough lately, I've been supporting my wife through her recent surgery, she gets to come home this week (3rd week in hospital/rehabilitation)

The u-boot source code should be able to help, I remember a regulator being involved. Sent from my Pixel using Tapatalk