8 hours ago, Redferne said:

I was trying to get "Option 3: Package the image with TPL" pure U-Boot

What we have right now is, probably, exactly what you wanted to achieve:

• Option 2 for building
• Option 3 for packaging

This boils down to having all bootloader components built from source code as opposed to having to load binary blob from vendor in the process.

 

I am not an expert on ATF but I understand it as a firmware running in a secure zone of the processor with a set of interfaces (eg. PSCI for power control) that let it interact with the rest of the software.

Not using ATF would mean that one had to code those interfaces themselves.

Yes. This exactly what I wanted to achieve, no blobs. But I got the impression while glancing over the U-Boot commits, that ATF was not needed for the TPL+SPL combo. I was wrong 🤣 Thanks for clearing this up 👍

@piter75 Are you planning to send the ATF "switch power domains on before reset" patch upstream to https://review.trustedfirmware.org/ ? It fixes the issue with mainline ATF + Linux where Linux will hang after rebooting; I have tested the patch with my own custom build of Debian and it now reboots 100% successfully. It would be really useful for all mainline distros if it was applied to mainline ATF.

18 hours ago, Hugh Cole-Baker said:

Are you planning to send the ATF "switch power domains on before reset" patch upstream

Sure, I was thinking about it.

Feeling motivated by your message  I will do that tonight

So happy to see all this traction! I'll finally be able to use my renegade elite. Just need to set up my build environment... Last step will be to make the m2 ssd available in u-boot and this thing will rock. 

Sorry for offtop, but I have some question about this SBC and Mezzanine extention before ordering:

 

1) Can I use power port on Mezzanine extention for powering main board?

2) USB WiFi is working, or I need to dance around with drivers/kernels etc?

3) Any body use 2 cams?

 

And finaly. I can't understand - Armbian allready released for this board, or not?

 

Thx!

9 hours ago, NAgain said:

USB WiFi is working

Most of important ones are supported out of the box with best driver found, recommended ones you can find on download pages. If you get exotics, you will have to dance. With Armbian SDK, this is easy.
 

9 hours ago, NAgain said:

I can't understand - Armbian allready released for this board, or not?

Officially supported:
https://www.armbian.com/download/?device_support=Supported

All:

https://www.armbian.com/download

 

In general:
https://docs.armbian.com/#what-is-armbian

11 hours ago, NAgain said:

Sorry for offtop, but I have some question about this SBC and Mezzanine extention before ordering:

 

1) Can I use power port on Mezzanine extention for powering main board?

2) USB WiFi is working, or I need to dance around with drivers/kernels etc?

3) Any body use 2 cams?

 

And finaly. I can't understand - Armbian allready released for this board, or not?

 

Thx!

 

Mezzanine is powered by the mainboard's USB-C through its connection on the board's GPIO. Otherwise, the mezzanine does offer an m.2 key slot for a wifi module. Sadly, Libre/loverpi is jerking around backers of the board and not delivering missing parts like the wifi module and emmc, so I wouldn't rely on them for these parts.

https://forum.loverpi.com/discussion/861/upstream-u-boot-status

Will it be possible to use the forthcoming SPI u-boot to boot armbian?

 

11 hours ago, strongtz said:

Will it be possible to use the forthcoming SPI u-boot to boot armbian?

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

I build yesterday for this board, and tried it today with no luck.
I have the standard PSU that was delivered with it.
I can boot Android on a SDCard, and Firefly's Linux on eMMC, but not Armbian for the time being.
I haven't plugged UART yet, so I don't know what's going on.

17 hours ago, gounthar said:

I build yesterday for this board, and tried it today with no luck.
I have the standard PSU that was delivered with it.
I can boot Android on a SDCard, and Firefly's Linux on eMMC, but not Armbian for the time being.
I haven't plugged UART yet, so I don't know what's going on.

Does this bring some light to power supply?

https://lkml.org/lkml/2019/12/10/517

I'm not sure I got what you meant.
I know there are some troubles with the power units for this board, but as I use the power adapter that was supplied with my board, I thought I would be good to go.
My board can boot Android on the SDCard and Linux on the eMMC with this power adapter.
Would you mean that Armbian would take too much current when starting, so that the board shuts off by itself?

12 hours ago, gounthar said:

there are some troubles with the power units for this board

Well... the troubles are not with the power units per se but with the combination of issues in mainline kernel for this board:

• lack of support for MP8859 buck-boost converter which means it always provides 5V instead of switching to 12V
• possible misconfiguration of FUSB302B PD chip driver used in roc-rk3399-pc

If I understand the patch correctly, Markus made some modifications to the power curve of fusb302 PD chip to switch usb-c voltage to 15V when more power is needed.

This should workaround power issues when powering from usb-c with pd compliant power units.

I see. I will give it another try later on.
Thanks.

On 9/12/2019 at 5:16 AM, frauhottelmann said:

Interesting. I don't recall it being picky with the power supply when I tried the images from Firefly.

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.

3 hours ago, TonyMac32 said:

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.

Found this discussion, over a year old.

fusb302 type-c chip driver supply cutting out

https://www.spinics.net/lists/linux-usb/msg171468.html

 

On 12/13/2019 at 4:39 AM, Panzerknacker said:

Found this discussion, over a year old.

 

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.

I have it running with the poe mezzanine, with an Armbian image built with the docker ubuntu method and it seems to be running okay.  When I did an apt-get upgrade it downgraded the kernel to 5.3, so I rebuilt a current 5.4 kernel image with the docker ubuntu method and with both kernels there is no pci express as the m.2. ssd is not being recognised.

 

I tried again with custom kernel config but Rockchip pcie is already being compiled but I can't find any kernel messages about pci express.

 

The only difference is with the 5.3 kernel and 5.4 kernel I can see is a green led comes on the mezzanine when 5.4 is running.

 

Is the mezzanine pci express?

33 minutes ago, a16bitsysop said:

 

 

Is the mezzanine pci express?

Yes, it's PCI-E and it is working on the firefly images. Maybe they have published code which could give some hindsight? 

4 hours ago, a16bitsysop said:

Is the mezzanine pci express?

 

3 hours ago, Fred St-Pierre said:

Yes, it's PCI-E and it is working on the firefly images.

 

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. 

 
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. 

I'm booting with it powered by Poe though, it has another converter on the mezzanine I think. Which then feeds the board?

No idea how it is wired so that quite probably goes to buck boost converter on board as well.

The Poe switch says it's drawing about 70mA at 50+ volts DC, the switch can power at 24v or 48v.

Sent from my moto g(7) power using Tapatalk

6 minutes ago, a16bitsysop said:

I'm booting with it powered by Poe though,

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

 

18 minutes ago, a16bitsysop said:

I'm booting with it powered by Poe though, it has another converter on the mezzanine I think. Which then feeds the board?

No idea how it is wired so that quite probably goes to buck boost converter on board as well.

The Poe switch says it's drawing about 70mA at 50+ volts DC, the switch can power at 24v or 48v.

Sent from my moto g(7) power using Tapatalk
 

 

I confirm that booting in POE circumvents the USB-C issues I had... My final spot for this thing will be in a cabinet powered by POE as well

 
I confirm that booting in POE circumvents the USB-C issues I had... My final spot for this thing will be in a cabinet powered by POE as well

Yes it's a neat board with the Poe mezzanine M2 SSD and single Poe cable.

Sent from my moto g(7) power using Tapatalk

19 hours ago, a16bitsysop said:

I have it running with the poe mezzanine, with an Armbian image built with the docker ubuntu method and it seems to be running okay.  When I did an apt-get upgrade it downgraded the kernel to 5.3, so I rebuilt a current 5.4 kernel image with the docker ubuntu method and with both kernels there is no pci express as the m.2. ssd is not being recognised.

 

I tried again with custom kernel config but Rockchip pcie is already being compiled but I can't find any kernel messages about pci express.

 

The only difference is with the 5.3 kernel and 5.4 kernel I can see is a green led comes on the mezzanine when 5.4 is running.

 

Is the mezzanine pci express?

The M.2 M-Key (PCIe) slot on the mezzanine board is supported from mainline kernel 5.5-rc1 on and works with NVME SSDs.

https://github.com/torvalds/linux/commit/f9010b0edcd5a3112ab3d4fc79c296c5a1c5ee16

 

The M.2 M-Key (PCIe) slot on the mezzanine board is supported from mainline kernel 5.5-rc1 on and works with NVME SSDs.
https://github.com/torvalds/linux/commit/f9010b0edcd5a3112ab3d4fc79c296c5a1c5ee16
 

Great, thanks for the info. Will try 5.5 when it's released.

Sent from my moto g(7) power using Tapatalk

Maybe I was looking bad, but I did not find the information, how much is the delivery of this model in Russia, if you order on the official website of Libre Computer ?

 

Maybe I was looking bad, but I did not find the information, how much is the delivery of this model in Russia, if you order on the official website of Libre Computer ?
 

The libre.computer website purchase page has links to LoveRPI.com and Amazon USA, which website are you looking at?

Sent from my moto g(7) power using Tapatalk

38 minutes ago, a16bitsysop said:

The libre.computer website purchase page has links to LoveRPI.com and Amazon USA, which website are you looking at?

https://www.loverpi.com/collections/renegade-elite