Jump to content

Recommended Posts

<
Posted
  On 1/14/2021 at 10:26 AM, Panzerknacker said:

Where did you get bl31.elf in u-boot src dir from?

Expand  

 

I did not copy bl31.elf src dir consciously to the spi.   It must still contain the original from t-firefly.com.   It might be some Chinese "protection" because it is bought as a industrial board.    What is the purpose of bl31.elf - is it similar to mbr (before the arm embedded revolution)?  The boot order of Rockship (rk3399) is problematic - should be CPU-SD-emmc

Actually you and balbes150 are by far much more advanced than I am.  

Posted
  On 1/14/2021 at 10:59 AM, Panzerknacker said:

If you really want to get rid of the SPI, you can erase it from your running u-boot.

Stop auto boot in u-boot and type "sf" at the prompt.

 

Expand  

 

 

Might try that.   If there is nothing on the SPI will that force booting up from SD and is it possible to flash the spi through the gpio pins afterward in case if the spi boot is needed?

 

Posted
  On 1/14/2021 at 9:51 AM, denni_isl said:

Using the 4 pin debug (close to usb-C) on the board connected to usb adapter (not the GPIO pins) connected to odroid-n2.   Are you talking about more options through the GPIO pins and a USB adapter like this one

Expand  

This is not about physically connecting the UART, but about setting up the output of the system startup log from Armbian to UART. I am interested in connected devices (how and where HDMI, LAN USB, etc. is connected).

Before recording SPI, did you have any systems working (the HDMI output was working) ? Why do you need to from SPI ? How do you plan to use the device ?

Posted
  On 1/14/2021 at 11:23 AM, balbes150 said:

This is not about physically connecting the UART, but about setting up the output of the system startup log from Armbian to UART. I am interested in connected devices (how and where HDMI, LAN USB, etc. is connected).

Before recording SPI, did you have any systems working (the HDMI output was working) ? Why do you need to from SPI ? How do you plan to use the device ?

Expand  

 

Did only change verbosity=7 in armbianEnv.txt on the SD card and the connections are all normal except the hdmi is connected to the Benq 24" through kvm switch

 

I was just interesting in learning about SPI booting process and u-boot in general.  The device is just used for the purpose of expanding the knowledge of the technology that is shaping the modern world.  So there is no special stress factor involved.

 

  Quote

verbosity=7
bootlogo=false
overlay_prefix=rockchip
fdtfile=rockchip/rk3399-roc-pc-mezzanine.dtb
rootdev=UUID=c8fe7fac-ac5e-4fe6-b6e6-1c7ed7f44ae2
rootfstype=ext4

Expand  

 

roc-rk3399-pc-plus-1.png

Posted
  On 1/14/2021 at 12:26 PM, balbes150 said:

Connect directly, so that there are no intermediate elements that may not work correctly with the signals

Expand  

 

Still yellow screen

 

  Reveal hidden contents

 

 

Posted
  On 1/14/2021 at 12:39 PM, balbes150 said:

You didn't answer the question - what systems did you try before (before the SPI change), did HDMI work or not?

Expand  

 

I did use your image Armbian_20.11_Arm-64_bullseye_current_5.10.0-rc4.img.xz and it did work perfectly (hdmi through kvm switch and everything else) as a desktop before the compiling and flashing the spi. 

 

 

Posted

How can one erase the spi with the u-boot command "sf"?

 

  Quote

=> sf probe                                                                     
SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB   
=>

Expand  

 

Some other useful hardware spesific u-boot info here https://wiki.dh-electronics.com/index.php/COM_iMX6_Bootloader_U-Boot

https://www.digi.com/resources/documentation/digidocs/PDFs/90000852.pdf

https://www.linuxsecrets.com/xilinx/U-Boot.html

 

  Quote

uboot> sf probe 0 0 0 SF: Detected N25Q128 with page size 256, total 16 MiB 16384 KiB N25Q128 at 0:0 is now current device   // Detect QSPI Flash parameters // To make QSPI clock run faster, higher speed can be set to second parameter, // e.g. setting QSPI clock to 20MHz // sf probe 0 20000000 0   uboot> sf erase 0 0x200000

Expand  

 

Did,

=> sf erase 0 0x200000                                                          
SF: 2097152 bytes @ 0x0 Erased: OK                                              
=>

 

Posted

EUREKA!

Thank you balbes150 and Panzerknaker - did make my third donatian to armbian through paypal. 

It did boot successfully from the sd card after -

=> sf erase 0 0x200000                                                          

 

  Reveal hidden contents

 

What is the best way for one to get himself familiar with memory address management.   To know offsett and size of memory addresses.   It is a bit a Hebrew to me and probably most others. 

 

This is a good source of information about practical use of u-boot commands, with examples and explanations. 

https://www.linuxsecrets.com/xilinx/U-Boot.html

 

 

 

Posted

  

  On 12/23/2020 at 11:54 AM, Panzerknacker said:

Boot from SPI directly to NVME works:

 

Latest U-Boot v2021.01-rc4 + this patch:

rockchip: roc-pc-rk3399: fix boot from SPI flash on spi1

https://patchwork.kernel.org/project/linux-rockchip/list/?series=403611

 

 

Expand  

 

Thanks for this, I just tried it yesterday and I actually get a post from SPI. It's a step in the right direction! I made a build environment in a Vmware player VM, which lets me manipulate the board as well. Compiling Armbian right now.

 

My issue is that I still have no keyboard input. I only have Unifying wireless keyboards, both do not work. I checked the config file and CONFIG_USB_KEYBOARD is set. I'm at a loss why it would not work. In the meantime, I'll flash to a USB stick to test and then migrate that to the nvme drive... 

Posted
  On 1/19/2021 at 9:28 PM, Panzerknacker said:

I forgot to mention how to build ATF (Arm Trusted Firmware)

 

git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git

 

make PLAT=rk3399 bl31
cp build/rk3399/release/bl31/bl31.elf ../u-boot

 

You need bl31.elf to build your u-boot!

Expand  

Yep, I had a previous bl31.elf built, that was not the issue. I had to enable CONFIG_DM_KEYBOARD=y in my defconfig... Keyboard now works. Thanks for the help! Next step, boot from nvme. ;)

Posted

This board is doing its best to drive me totally bonkers. Still can't boot anything...  It sees NVME, it sees my USB, able to see all files are there, but it just doesn't fire up anything. More digging required, I guess. Used Armbian compiler for most, compiled initramfs with linux-next instructions, followed most recommendations here. 

 

At least I figured out that having the board plugged into my laptop to power it, if I type ums 0 nvme 0 from u-boot, I can access the nvme drive from my Ubuntu VM and fully manipulate it from there. Learning experience :)

Posted
  On 1/21/2021 at 2:48 AM, Fred St-Pierre said:

This board is doing its best to drive me totally bonkers. Still can't boot anything... 

Expand  

You mean "anything" literally or "anything besides microSD/eMMC"?

 

With change described here this board works for me. Armbian 21.02.0-trunk is installed on eMMC and I typing this message on this board right it now.  There is of course several issues, such as not working DisplayPort and unreliable Type-C ports behavior, but at least it's as good as ROCKPro64, even Gnome Shell Wayland works (earlier it was limited to X11 due to workaround).

Posted
  On 1/21/2021 at 5:31 AM, RussianNeuroMancer said:

You mean "anything" literally or "anything besides microSD/eMMC"?

 

With change described here this board works for me. Armbian 21.02.0-trunk is installed on eMMC and I typing this message on this board right it now.  There is of course several issues, such as not working DisplayPort and unreliable Type-C ports behavior, but at least it's as good as ROCKPro64, even Gnome Shell Wayland works (earlier it was limited to X11 due to workaround).

Expand  

 

Yeah, just flashed SD card and tested, seems like my build does not work... It doesn't even fetch extlinux.conf to begin boot. More digging to figure it all out. Baby steps and progress.  Learning how to compile slowly.

Posted
  On 1/21/2021 at 11:37 PM, Fred St-Pierre said:

 

Yeah, just flashed SD card and tested, seems like my build does not work... It doesn't even fetch extlinux.conf to begin boot. More digging to figure it all out. Baby steps and progress.  Learning how to compile slowly.

Expand  

 

Ok, so progress: flashed u-boot from this release: https://github.com/amarula/bsp-rockchip/releases/tag/v1.3-roc-rk3399-pc and board boots into Armbian with a freshly compiled Armbian build. HUZZAH! Boots off nvme too... Now I'm kind of afraid to see what will happen if I update the board, as I think this is u-boot 5.5... At least it's a step in the right direction.

Posted

So further trying to get the board to boot, I tried to compile Linux-next, copied all files to the /boot folder, flashed spi.img as recommended and the board is dead in the water again. The u-boot from the amarula release seems to have initramfs built in to the image... So... More attempts required to get the board to boot with self-compiled u-boot and initramfs, I guess.

Posted
  On 1/26/2021 at 3:02 AM, Fred St-Pierre said:

So further trying to get the board to boot, I tried to compile Linux-next, copied all files to the /boot folder, flashed spi.img as recommended and the board is dead in the water again. The u-boot from the amarula release seems to have initramfs built in to the image... So... More attempts required to get the board to boot with self-compiled u-boot and initramfs, I guess.

Expand  

Maybe check this commit: https://github.com/armbian/build/pull/2572

Posted
  On 1/28/2021 at 6:19 PM, frauhottelmann said:
Expand  

 

I dirty modified the config code to include this... Booting from nvme doesn't seem like it's an issue, it's more the fact the initramfs on the amarula image is part of their SPI image, while the other needs to be added to the armbian image to boot properly. I don't have much time to play around with it lately, so I'll give it some time before I try it again. But the SPI image from Amarula boots the armbian latest compiled image without issues, so I'll keep this for now and play around with it further when I have time. Thanks! 

Posted

Ok lets tell my story of successfully flashing SPI with a Chinese programmer.    This is for educational purpose for others in similar situation.

 

Had done armbian-config, system, install to/update bootloader, install/Update the bootloader on SPI Flash roc-rk3399-pc-plus board and that did completely brick the board. 

 

Prior to that I had ordered EZP2019 flasher kit from https://www.aliexpress.com/item/33042726404.html?spm=a2g0s.9042311.0.0.491a4c4dxKfJuf

for 20$.  Witch turned out to be fortunate.

 

Compiled u-boot-2021-01 according to Panzerknacker advice as a had done before and

 

 

flashed the u-boot-rokchip.bin (8.8 MiB image) to the SPI chip throug my old Windows laptop with the EZP2019+ USB high speed programmer software that was included in the package.  

Had to chose, Chip - Type = SPI_FLASH, Manufacturer = WINBOUND, Name = W25Q128, Test, AUTO - few attempts because of the fragile connection through the clip.

 

The output from UART serial

  Reveal hidden contents

 

20210129_194001.jpg

Posted
  On 1/19/2021 at 9:28 PM, Panzerknacker said:

I forgot to mention how to build ATF (Arm Trusted Firmware)

 

git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git

 

make PLAT=rk3399 bl31
cp build/rk3399/release/bl31/bl31.elf ../u-boot

 

You need bl31.elf to build your u-boot!

Expand  

 

This was the missing link.   Now the spi boot work like a charm (have not tried yet to boot from nvme).

=> run bootcmd_mmc1 (sd) - with balbes150 bullseye image from https://users.armbian.com/balbes150/arm-64/

boots without a problem and supposedly also from NVME and USB.  

 

Some research;

https://duckduckgo.com/?q=bl31+uboot&t=newext&atb=v255-3__&ia=web

http://u-boot.10912.n7.nabble.com/SPL-load-ARM-Trusted-Firmware-BL31-td269471.html

 

Are you familiar with this warning? - 

*** Warning - bad CRC, using default envirt

 

This is the boot log.    

 

  Reveal hidden contents

 

Posted
  On 1/30/2021 at 10:53 AM, denni_isl said:

 

This was the missing link.   Now the spi boot work like a charm (have not tried yet to boot from nvme).

=> run bootcmd_mmc1 (sd) - with balbes150 bullseye image from https://users.armbian.com/balbes150/arm-64/

boots without a problem and supposedly also from NVME and USB.  

 

Some research;

https://duckduckgo.com/?q=bl31+uboot&t=newext&atb=v255-3__&ia=web

http://u-boot.10912.n7.nabble.com/SPL-load-ARM-Trusted-Firmware-BL31-td269471.html

 

Are you familiar with this warning? - 

*** Warning - bad CRC, using default envirt

 

This is the boot log.    

 

  Reveal hidden contents

 

Expand  

Normal message on first boot. Just enter u-boot without a boot drive, type saveen. If you want, you can use printenv to see your environment variables and modify them to your liking (for example edit boot_targets) and then type saveen. CRC error should dissapear.

Posted

Is it right understood that ATF (Arm Trusted Firmware) is necessary for u-boot to function by it self as a mini kernel to recognize all the necessary hardware by it self on various embedded devices? 

What is the purpose of having multiple bl* - bl31,bl32 bl2u * ?

- ma

  Quote

make PLAT=rk3399 bl31

Expand  

- you define the platform (PLAT) and then other hardware support you chose through bl31?

I can see that plat directory is under trusted-firmware-a/plat/rockchip/rk3399/ 

 

Posted

Did "brick" rokpro64 and there is a workaround there to disable spi, jumper on pin 23 and 25 release the jumper to boot from sd or mmc. 

 

Just want to put it here for those who are flashing the gd25q128 spi with programmers, to unplug all extra electrical connections from the board UART serial adapter, lan and the power cord.

Did get error messages from the programmer software for the EZP201+ "programmer - flash check error address 0h" and no writing to the spi few times.  

 

Did then eventually flash the same  u-boot-rokchip.bin (8.8 MiB image) that I dis use for flashing roc-rk3399-pc to flash the rockpro64.  It seems to be enough to get one up and going if he bricks rk3399 spi. 

 

  Reveal hidden contents

 

 

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.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines