Jump to content

Armbian + EFI\grub + NVMe


balbes150

Recommended Posts

version 20230103-edge with kernel 6.2. running from an SD card works, but there is no USB and LAN, so there is little practical use yet. Added support for PCIe, the eth0 interface appeared, but the network does not see it. may need drivers or additional settings for DTB. A link to a working image with kernel 6.2, and DTB with eth0 enabled.

 

 

Link to comment
Share on other sites

Version 20230103-EDK2-edge with kernel 6.2. The launch procedure is the same - burn images to two media SD card and USB flash drive, connect both media at the same time and turn on the power. Management only via the UART console.

Link to comment
Share on other sites

Quote

Now, to solve this problem,  have to use a regular power supply (12 or 20 volts) and a jack to USB-C adapter.

Just for the record:

I used a PD+QC3.0 12V adapter for cars behind a programmable power supply (5-20V/3A).

 

Findings (lot's of open doors):

- get the smallest PD adapter you can find, since a 65W PD adapter uses more power than a 30W PD adapter (the 65W adapter provides 20V, where the 30V generatesonly 9V, the difference is almost 1W continously).

- Since you don't need the battery saving function from PD using QC acts like a constant voltage connector.

- With QC and a cheap cable the only data from the power supply is "1.5A".

- A direct power connection depends on the cable used, with 5V and a cheap cable expect the cable to be recognized as 1,5A!

- The  Raspberry power supply probably is detected as 5V with 3A cable.

 

The obvious conclusion is that starting with 20V instead of 9V burns more energy, since the internal step-down convertor just generates more heat.

With a lab power supply, expect 9V/1,5A or 12V/1.5A with a cheap cable. You might want to cut up a 3A cable if you want something better.

 

The direct power with cheap cable (5V/1.5A) is unstable, while the Raspberry power supply works (limit in the Rock5B?).

 

My current settings:

$ cat /sys/class/typec/port0/power_operation_mode
usb_power_delivery
$ sensors|grep -A3 tcpm
tcpm_source_psy_4_0022-i2c-4-22
Adapter: rk3x-i2c
in0:           9.00 V  (min =  +9.00 V, max =  +9.00 V)
curr1:         2.22 A  (max =  +2.22 A)

Direct power with 9V/1.5A or 12V/1.5A is usable for a quick start. A 3A cable is something you should really want (like I said, open doors).

Testing with eMMC, without NVMe, the small PD adapter gives a stable power, without wasting too much.

Link to comment
Share on other sites

Hello @balbes150, thanks for your hard work by providing these images for those who own the ROCK5B.

 

I flashed the following images into my microSD:

 

- Armbian_23.02.0-trunk_Rock-5b_jammy_legacy_5.10.110

- Armbian_23.02.0-trunk_Rock-5b_jammy_edge_6.2.0

 

and both of them did not make any HDMI video output in my ROCK5B, there is no blue light activity LED blinking.

 

I have tried to access through SSH and UART, but neither of them worked.

 

I flashed the .img files directly to microSD (with and without nvme plugged in the M.2 PCI-e slot).

 

Can someone, please, tell me the right procedure to run armbian-install from u-boot to install in my NVME drive?

 

Thanks in advance!!

Link to comment
Share on other sites

I'd like to get Armbian to boot from NVME on the rock-5b, but have not had any luck with that, though I've not tried recently. Also, I've had zero issues with my PD supply that so many have highlighted. At this point, after re-reading this long thread, I'd like to ask if I've understood it correctly. If I :

 

- boot the latest Armbian image from SD then use it program SPI flash as provided for in the install procedure.

- then dd the Arbian image to the NVME device,

- then shut down, remove the SD card, and power cycle,

 

It should work, right? It did not the last time I tried it. If however, I dd the Radxa image to NVME it boots correctly everytime.

Edited by lurk101
Link to comment
Share on other sites

16 часов назад, chandlerkc сказал:

and both of them did not make any HDMI video output in my ROCK5B, there is no blue light activity LED blinking.

 

16 часов назад, chandlerkc сказал:

I have tried to access through SSH and UART, but neither of them worked.

In all my versions, output to the UART console is enabled, so if there are any problems with startup, you will be able to see at what stage the problem is.

If you did not write anything to SPI and there are no radxa loaders (in which the UART output is disabled), then you have a power problem.

 

15 часов назад, lurk101 сказал:

I'd like to ask if I've understood it correctly. If I :

The right steps :

 

- boot the latest Armbian image from SD then use it program select a menu item SPI + NVMe as provided for in the install procedure.

- then shut down, remove the SD card, and power cycle,

 

No manual DD operations to write the image to NVMe - UNNECESSARY. The installation script itself will write everything correctly on NVMe (the only condition is that a partition must be created on NVMe)

 

15 часов назад, lurk101 сказал:

If however, I dd the Radxa image to NVME it boots correctly everytime.

It means that you already have an old version of the loader in SPI, which contains a number of errors.

Link to comment
Share on other sites

Nope, still doesn't work.

Quote

It means that you already have an old version of the loader in SPI, which contains a number of errors.

Then it also means that the option provided to flash the SPI flash doesn't work! It takes a few minutes and doesn't indicate any errors, but seems to leave me with the old Radxa boot loader.

Link to comment
Share on other sites

31 минуту назад, lurk101 сказал:

Armbian_23.02.0-trunk.0179_Rock-5b_jammy_legacy_5.10.110_minimal.img.xz

 

From here

 

https://github.com/armbian/build/releases/download/

These are the official versions, please contact the appropriate section with all questions. Modified versions are discussed in this topic, they differ from the official ones.

Link to comment
Share on other sites

23 минуты назад, lurk101 сказал:

The SD image wouldn't boot! It boots to nvme and does not use the SD card image.

I already wrote above, you have old shit in SPI. The only way to fix this is to disable NVMe physically, launch Armbian from the Sd card and overwrite SPI with a new bootloader. Only after that you connect NVMe back and start the system from the SD card and the correct installation is performed (re-start the system installation on NVMe + SPI).

Link to comment
Share on other sites

@lurk101 I will try to reproduce the steps @balbes150 gently told us, I have not had yet enough time to do that.

 

When I get it to run, I will post a full report of how to do that.

 

Quote

If you did not write anything to SPI and there are no radxa loaders (in which the UART output is disabled), then you have a power problem.

 

I am using a dumb 5V 3A USB-C Power Supply that I have always used with my Raspberry Pi 4, do you think using a PD PSU will be better?

Edited by chandlerkc
Link to comment
Share on other sites

17 часов назад, lurk101 сказал:

Will not boot from SD. I get solid green LED then nothing else. However, the standard Armbian image boots fine from SD with NVME removed.

Which power supply do you use ? Which version of u-boot did you write to SPI?

 

1 час назад, chandlerkc сказал:

do you think using a PD PSU will be better?

Do not use PD power supplies, this is complete crap, for their proper operation requires the mandatory presence of a built-in battery (for the operation of the voltage matching stage).

 

Link to comment
Share on other sites

@balbes150

I use an INVZI USB C Charger 67W, GaN III. As I've said before I've had 0 issues with it. It never fails to negotiate 20V with the standard Arbian image or the Radxa image. I don't think the hardware is crap, I think the idea of negotiating voltage in the kernel rather than in uboot is crap.

 

The bootloader was flashed to SPI flash using the standard Armbian image.

 

As I pointed out, with no NVME connected the standard Armbian image boots fine from SD, but does not boot your image. I can't understand why that would be!!! I thought it might be an MBR vs GPT formatted SD thing, but no that's not it. I tried your image as is, then converted it to MBR but still no-go.

 

Edited by lurk101
Link to comment
Share on other sites

32 минуты назад, lurk101 сказал:

It never fails to negotiate 20V with the standard Arbian image or the Radxa image.

They use an old crappy u-boot with UART disabled, incorrect startup order (when NVMe is connected with the system on it, startup from any other media is blocked), etc. If you are satisfied with this, use the official versions of the images.

 

32 минуты назад, lurk101 сказал:

I don't think the hardware is crap, I think the idea of negotiating voltage in the kernel rather than in uboot is crap.

The very idea of using power supplies with PD is complete crap. And this was done by the stupidity of the developers of this device, they are trying to use USB-C, which has a very small thickness of contacts, and to transfer high power, they have to increase the voltage. If these idiots used a normal power connector (Jack 5\2.1mm) and a normal standard voltage value of 12V (or 24 for direct industrial use), this would save all users from the problems of idiotic solutions with PD.

 

32 минуты назад, lurk101 сказал:

As I pointed out, with no NVME connected the standard Armbian image boots fine from SD, but does not boot your image. I can't understand why that would be!!!

Because I use a full-fledged u-boot (starting from SD without disabling NVMe, with a UART console, the correct order of device selection, in the next version with support for launching from USB, etc.) without shit for PD approvals, and only normal power solutions (without PD) should be used with it.

Link to comment
Share on other sites

Ok,  you have no clue why your image won't boot from SD, so you blame the supply. Fine, I'll just keep using the standard Armbian image. I've wasted enough time on this. I don't need to boot from SD and NVME boot works well.

 

Edited by lurk101
Link to comment
Share on other sites

I think the power supply might deserve it's own topic.

 

Like balbes mentioned PD is meant for devices with internal battery. There it saves the battery during fast charging by preventing overcharging.

The Rock 5B is further 'borked' since the negotiation starts after the system starts. The advantage is it can be open source (more or less), but the big disadvantage it is so slow most PD chargers stop negotiating during system start in the meantime.

 

If you realise that the power supply in the Rock 5B (IP2315) is just a step-down converter with some logic and a PD car-adapter adds an step-up adapter to the equation you might realise it makes no sence to operate the power input at 20V. While the resistance in the cable might be minimized the power loss in the step-down and the step-up converters are maximized. Most power supplies can achieve 95% efficiency, but cheap step-up/step-down converters can only achieve that when V_in is almost equal to V_out. Normal PD-adapter should work more efficient than 12V car-adapters, but even then if they very efficiently produce 20V which the R5B very inefficiently transformes to 3.3-5V does that make sense?

 

A 20W PD car-adapter adds roughly 0.5W to the power consumption. With a 65W/20V PD car-adapter the adapter might add more, but the step-down converter in the R5B will definitely work more inefficient than at 9V.

Edited by specs
Link to comment
Share on other sites

Quote

 

I think the power supply might deserve it's own topic.

 

Like balbes mentioned PD is meant for devices with internal battery. There it saves the battery during fast charging by preventing overcharging.

The Rock 5B is further 'borked' since the negotiation starts after the system starts. The advantage is it can be open source (more or less), but the big disadvantage it is so slow most PD chargers stop negotiating during system start in the meantime.

 

If you realise that the power supply in the Rock 5B (IP2315) is just a step-down converter with some logic and a PD car-adapter adds an step-up adapter to the equation you might realise it makes no sence to operate the power input at 20V. While the resistance in the cable might be minimized the power loss in the step-down and the step-up converters are maximized. Most power supplies can achieve 95% efficiency, but cheap step-up/step-down converters can only achieve that when V_in is almost equal to V_out. Normal PD-adapter should work more efficient than 12V car-adapters, but even then if they very efficiently produce 20V which the R5B very inefficiently transformes to 3.3-5V does that make sense?

 

A 20W PD car-adapter adds roughly 0.5W to the power consumption. With a 65W/20V PD car-adapter the adapter might add more, but the step-down converter in the R5B will definitely work more inefficient than at 9V.

 

 

Yes, I understand all that, but instead of of giving reasons why it's a bad design maybe tell us why the design fails for so many? I'm not that interested in subjective assessments, I'd like to understand the root cause and how it might be mitigated.

As for why the design was chosen, who knows! I would guess that most consumers (of the non nerdy class) already have a PD charger for use with their other devices. After all, who wants to mess around with specialized adapters, risking the possibility of getting a reverse polarity barrel jack (there's no official standard). I agree that 12V would be a better choice and perhaps that could be accommodated in software since a software component has its fingers in the negotiation.

Edited by lurk101
Link to comment
Share on other sites

6 hours ago, lurk101 said:

Ok,  you have no clue why your image won't boot from SD, so you blame the supply. Fine, I'll just keep using the standard Armbian image. I've wasted enough time on this. I don't need to boot from SD and NVME boot works well.

 

What did you do to boot Armbian only with NVMe?

 

Thanks in advance for sharing!

Link to comment
Share on other sites

Hard to say, I've had so many different configurations on this board in the last 6 weeks. Here's how I did it last time.

 

- The 1st time I started with an unformatted nvme SSD. Then using https://github.com/armbian/build/releases/download/23.02.0-trunk.0186/Armbian_23.02.0-trunk.0186_Rock-5b_jammy_legacy_5.10.110_minimal.img.xz burnt to SD.

- Booted the SD then used arbian-install and selected the 3rd option (i think) to flash the boot loader to SPI flash. It's a slow operation, be patient.

- Then selected option 1, install to mmc, nvme, or something like that.

- Power cycle after removing the SD card.

 

The downside of this configuration is that you can no longer boot from SD, as pointed out previously. This leads to problem with consecutive installs. To workaround the problem I zero out the 1st few blocks of the nvme before shutting down prior to the install.

 

That said, for the time being I've given up on Armbian for the rock-5b and have reverted to to Radxa's Ubuntu server image. I run exclusively headless, except for installs, and that configuration best meets my needs. I've alsways had a trouble free experience with Armbian running on all my previous Rockchip based SBCs so this is a 1st!

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines