Jump to content

NanoPi M4 V2 - M4 Image not working

NicoD

By NicoD
in Rockchip

 Share

Recommended Posts

pkfox

pkfox

Posted
Posted
5 minutes ago, nickngsr said:

I dd'd it directly to the emmc via usb after the 'nand-sata-install' completed.

 

I haven't checked but if you can ignore the shutdown/reboot at the end of the script you should be able to download @pask's patch and flash it to the emmc on the board itself

I will have to do it via USB as the board can't see the the eMMC - fdisk -l doesn't list it

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
1 hour ago, TCB13 said:

is there an estimate on when the NanoPi M4v2 image will show on the downloads page? 


If you wait on me certainly not this week, since I am working day and night on this. Then I am travelling around the world for two weeks, then its December and than I have some time off.

Link to comment
Share on other sites
piter75

piter75

Posted
Posted

I started working on the build config for M4V2 but it will certainly not happen before the PR, that @Igor referred to, is merged into master.

 

I have a device finally so I should soon have a branch that I would like M4V2 owners to build locally and test.

Link to comment
Share on other sites
piter75

piter75

Posted
Posted

I don't want to make another thread about M4V2 images, at least yet, so I will squeeze in here ;-)

 

@pask, @NicoD, @pkfox all of you are using NanoPi M4 image patched with Rock Pi 4 u-boot that @pask prepared. Is it stable for you?

 

On my M4V2, both retrofitted M4 image and my own builds specifically for M4V2, I observe Kernel errors from time to time - especially during boot-up.

I started wondering whether my device may be faulty...

Link to comment
Share on other sites
NicoD

NicoD

Posted
  • Author
Posted
37 minutes ago, piter75 said:

Is it stable for you?

Not stable with dev.  I've had tons of crashes when using 5.x kernel. And different kinds of crashes. But I was using a panfrost build, so I had put the blame on that.


With default it works very good. But I've had USB ports failing. Everything else seemed to still be alive, there was power on USB. But devices didn't work. No num lock on keyboard... Both USB3 controllers seemed to have given up. A reboot fixed it. I'm using the M4V2 as desktop. So I'm using it a lot, and it only has happened twice in +1 week. 
Before that I used the M4 the same and never had this fail like that.


I'll have to see to get another friendlyElec ttl adapter. I burned mine on the Odroid N2(stupid fools using the same connector but reversing polarity(stupid fool not checking the pin-out...)) 

Link to comment
Share on other sites
piter75

piter75

Posted
Posted
51 minutes ago, NicoD said:

But I was using a panfrost build, so I had put the blame on that

Ok, the causes of the crashes could be different for us as I use it solely in the terminal ;)

 

Anyway, I did something which I cannot imagine could help but... it seems that it helped.

I remember reading somewhere lately about instability of PX30 at 408MHz that was avoided by changing min frequency to 600MHz.

Our images for RK3399 have default min of 600MHz so I did the opposite and changed the min to 408MHz.

 

I will definitely observe it for a longer time but last 40-50 reboots were clean of errors while before it happened every 3-5 reboot.

1
Link to comment
Share on other sites
pkfox

pkfox

Posted
Posted
4 hours ago, piter75 said:

I don't want to make another thread about M4V2 images, at least yet, so I will squeeze in here ;-)

 

@pask, @NicoD, @pkfox all of you are using NanoPi M4 image patched with Rock Pi 4 u-boot that @pask prepared. Is it stable for you?

 

On my M4V2, both retrofitted M4 image and my own builds specifically for M4V2, I observe Kernel errors from time to time - especially during boot-up.

I started wondering whether my device may be faulty...

Hi I only use mine as NFS file server feeding Ras Pi music streamers and have nad no problems been up for about a week now without any problems

 

Link to comment
Share on other sites
pask

pask

Posted
Posted

@piter75

At the moment I'm running Manjaro with 5.3.11 kernel on the M4v2: I'm experiencing lots of freezes that I'm not been able to diagnose and troubleshoot so far. I was suspecting power issues (which could also explain the USB issues that @NicoDdescribes).

But, this morning I tried to use the Raspberry Pi4 official power adapter and cable, which I know to be dependable. But while I was doing a dd of a 4GB file on the SD card, the board got stuck for the umpteenth time: so, now I believe my issues might be related to the SD card / controller. 

 

Anyway, in the evening I'll burn a M4 image with the default kernel to see if it's stable under high CPU and I/O load.

 

@piter75 Do you have any link to share explaining all the components needed and where to get them, to build from scratch and burn the bootloader for arm rk3399 boards? I found so much information around but nothing clear and simple enough I could use

Link to comment
Share on other sites
piter75

piter75

Posted
Posted
5 hours ago, pask said:

now I believe my issues might be related to the SD card / controller

Well, I remember sometimes seeing strange errors related to u-boot script loading in the logs when you were testing my `blind` builds. For which I thank you again @pask :)

 

I continue to run stable with the combination of latest ddr/miniloader/bl31 combo from Rockchip and min frequency lowered to 408MHz but I use only console so our crashes may not be related.

 

For building u-boot I mostly exploit Armbian build system running in Vagrant.

After this PR: https://github.com/armbian/build/pull/1616 which I merged into my branch it became really easy to tinker with u-boot, build u-boot alone and dd the bootloader parts to SD.

 

When it comes to docs I think these places come to my mind as a starter:

http://opensource.rock-chips.com/wiki_Boot_option#U-Boot

https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip

https://github.com/armbian/build/blob/d184b0393038be2bf29d78fd9cf469e7a26b5f0c/config/sources/families/rk3399.conf#L23

https://github.com/armbian/build/blob/master/config/sources/families/include/rockchip64_common.inc#L63

Link to comment
Share on other sites
piter75

piter75

Posted
Posted

@pask, @NicoD, @pkfox, @TCB13

Would you find some time for building and running the Armbian image from my branch:

https://github.com/armbian/build/tree/nanopi-m4v2-u-boot-v2019.10-ddr-miniloader

 

The build:

  • is based on latest: u-boot and ddr/miniloader/bl31 from Rockchip (could not get mine to run reliably with u-boot's TPL/SPL combo)
  • has lowered min frequency to 408MHz
  • contains wi-fi firmware provided by @martinayotte in this thread

For my tests I mainly build minimal `dev` target: 

./compile.sh minimal BOARD=nanopim4v2 BRANCH=dev RELEASE=buster

It would be grate if you could find some time to test it :)

Link to comment
Share on other sites
pask

pask

Posted
Posted
13 hours ago, piter75 said:

@pask, @NicoD, @pkfox, @TCB13

Would you find some time for building and running the Armbian image from my branch:

https://github.com/armbian/build/tree/nanopi-m4v2-u-boot-v2019.10-ddr-miniloader

 

 

 

 

Hello @piter75

compile.sh fails because of some absolute paths left into the code.

  

pack uboot.img success! 
/home/pask/armbian-master-build/config/sources/rk3399.conf: line 70: /home/vagrant/armbian/patch/atf/atf-rk3399/add-trust-ini.patch: No such file or directory
config(trust.ini) not found!
merge failed!
[ error ] ERROR in function compile_uboot [ compilation.sh:216 ]
[ error ] U-boot file not found [ trust.bin ]
[ o.k. ] Process terminated

which was easy to fix by myself. But, some steps later:

  

pack input ./u-boot-dtb.bin 
pack file size: 829663 
crc = 0xdf37889f
pack uboot.img success! 
/home/pask/armbian-master-build #pask info
patching file trust.ini
out:trust.bin
E: [mergetrust] filter_elf /home/vagrant/armbian/cache/sources/rkbin-tools/rk33/rk3399_bl31_v1.30.elf file failed
merge failed!
[ error ] ERROR in function compile_uboot [ compilation.sh:216 ]
[ error ] U-boot file not found [ trust.bin ]
[ o.k. ] Process terminated

which I don't have time to catch at the moment as I'm already (very) late for going to work :lol:

 

 

Link to comment
Share on other sites
piter75

piter75

Posted
Posted
3 hours ago, pask said:

compile.sh fails because of some absolute paths left into the code

Sorry @pask

That's what happens when a prototype leaves factory without proper testing ;p

 

It is fixed now in the branch so please pull.

 

As a side note I followed your comment about possibility of SD controller problems and I find it possible.

Until yesterday I was always testing with SD for the convenience and simplicity of it but yesterday I burned eMMC finally and I must admit that I had no errors in mainline on bootup in that setup.

Default/legacy build was stable even with the SD card for me.

This needs further testing of course...

Link to comment
Share on other sites
pask

pask

Posted
Posted
21 hours ago, piter75 said:

Sorry @pask

That's what happens when a prototype leaves factory without proper testing ;p

 

It is fixed now in the branch so please pull.

 

 

 

@piter75

the dev kernel boots correctly: https://pastebin.com/jrghsmPi

I have also tried the desktop version which works quite well if panfrost is disabled. Audio doesn't work: strangely it seems that this kernel version doesn't support the Realtek ACL 5651: I tried to manually edit the .config, but with no success

 

Instead, images with the default kernel fail (tested with various sd cards): https://pastebin.com/FSfEs9Kq

 

I guess that the friendlyelec 4.4.y kernel dts isn't compatible with the 2019 uboot branch

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted
4 hours ago, pask said:

I guess that the friendlyelec 4.4.y kernel dts isn't compatible with the 2019 uboot branch

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...  :wacko:

 

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...

1
Link to comment
Share on other sites
piter75

piter75

Posted
Posted
7 hours ago, pask said:

images with the default kernel fail

I briefly tested it in one of the iterations and I remember it working but I could definitely break it on the way.

I will check it out and sound card as well.

 

10 hours ago, chwe said:

we've some history with SD cards or rockchip... 

That's what came to my mind too and I was going to explore that too.

 

1 hour ago, lburais said:

this is just working out of the box including full access to my Transcend SSD

Thanks for feedback. Great to hear that it worked :)

What $BRANCH did you use - dev / default? Was it desktop, default or minimal build? Oh.. and what boot medium did you use SD/eMMC?

Link to comment
Share on other sites
lburais

lburais

Posted
Posted
2 minutes ago, piter75 said:

I briefly tested it in one of the iterations and I remember it working but I could definitely break it on the way.

I will check it out and sound card as well.

 

That's what came to my mind too and I was going to explore that too.

 

Thanks for feedback. Great to hear that it worked :)

What $BRANCH did you use - dev / default? Was it desktop, default or minimal build?

minimal and dev 

Link to comment
Share on other sites
pask

pask

Posted
Posted
15 hours ago, lburais said:

minimal and dev 

Indeed, the dev kernel image worked for me too.

Could you also check a default kernel image, please? (using the nanopi-m4v2-u-boot-v2019.10-ddr-miniloader branch)

Only this one failed on my M4v2, instead. 

./compile.sh BOARD=nanopim4v2 BRANCH=default RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no

 

 

12 hours ago, piter75 said:

@pask I have just booted default images (using SD), both minimal: http://ix.io/22yt and desktop: http://ix.io/22zD.

I have enabled verbose boot logging in the branch so maybe we can see where it hangs for you.

 

Thank you @piter75 . Comparing the two default image boot logs, mine and yours, they have some "small" differences.

 

Yours: ChipType = 0x10, 316     Mine: ChipType = 0x10, 250

I do not know to what this attribute references . Perhaps to the sd card vendor/model?

 

Yours: 

## Executing script at 00500000
Boot script loaded from mmc 1
244 bytes read in 9 ms (26.4 KiB/s)
6514583 bytes read in 421 ms (14.8 MiB/s)
18395144 bytes read in 1172 ms (15 MiB/s)
103833 bytes read in 19 ms (5.2 MiB/s)
## Loading init Ramdisk from Legacy Image at 04000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    6514519 Bytes = 6.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f58c6000, end f5efc757 ... OK
ERROR: reserving fdt memory region failed (addr=0 size=0)
   Loading Device Tree to 00000000f5844000, end 00000000f58c5fff ... OK

Mine: 

## Executing script at 00500000
Boot script loaded from mmc 1
142 bytes read in 5 ms (27.3 KiB/s)
7556947 bytes read in 480 ms (15 MiB/s)
18395144 bytes read in 1161 ms (15.1 MiB/s)
103833 bytes read in 14 ms (7.1 MiB/s)
## Loading init Ramdisk from Legacy Image at 04000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    7556883 Bytes = 7.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f57c8000, end f5efcf13 ... OK
ERROR: reserving fdt memory region failed (addr=0 size=0)
   Loading Device Tree to 00000000f5746000, end 00000000f57c7fff ... OK

On the same hardware, the same running software shouldn't lead to the same amount of bytes read?

 

Anyway, I'll try the debug enabled image and I'll further check.

 

In the meantime, could you also share the default minimal image it's working to you? Just to be sure I'm not doing some dumb error while compiling the image I'm not aware of.

 

 

 

 

Link to comment
Share on other sites
piter75

piter75

Posted
Posted
3 hours ago, pask said:

On the same hardware, the same running software shouldn't lead to the same amount of bytes read?

There is one thing that comes to my mind... I have some features disabled in my config-minimal.conf.

I have AUFS disabled for sure, which is irrelevant. Will let you know about the rest later.

 

Dev kernel should have a sound card working by now 😉

1
Link to comment
Share on other sites
piter75

piter75

Posted
Posted
On 11/23/2019 at 10:31 AM, pask said:

could you also share the default minimal image it's working to you?

Here is the one I compiled few minutes ago.

https://drive.google.com/open?id=1xAh4i7cw9KgVo4ZGWm5F58nMXfIB5li4

 

For this build I removed my custom config from "userpatches/config-default.conf" and copied there one from the "config/templates/config-example.conf" directory so it is pristine.

Here are its contents:

Spoiler 

# Read build script documentation https://docs.armbian.com/Developer-Guide_Build-Options/
# for detailed explanation of these options and for additional options not listed here
KERNEL_ONLY=""                      # leave empty to select each time, set to "yes" or "no" to skip dialog prompt
KERNEL_CONFIGURE=""                 # leave empty to select each time, set to "yes" or "no" to skip dialog prompt
CLEAN_LEVEL="make,debs,oldcache"    # comma-separated list of clean targets: "make" = make clean for selected kernel and u-boot,
                                    # "debs" = delete packages in "./output/debs" for current branch and family,
                                    # "alldebs" = delete all packages in "./output/debs", "images" = delete "./output/images",
                                    # "cache" = delete "./output/cache", "sources" = delete "./sources"
                                    # "oldcache" = remove old cached rootfs except for the newest 8 files
DEST_LANG="en_US.UTF-8"             # sl_SI.UTF-8, en_US.UTF-8
# advanced
EXTERNAL_NEW="prebuilt"             # compile and install or install prebuilt additional packages
INSTALL_HEADERS=""                  # install kernel headers package
LIB_TAG="master"                    # change to "branchname" to use any branch currently available.
USE_TORRENT="no"                    # use torrent network for faster toolchain and cache download
DOWNLOAD_MIRROR=""                  # set to "china" to use mirrors.tuna.tsinghua.edu.cn
CARD_DEVICE=""                      # device name /dev/sdx of your SD card to burn directly to the card when done

 

 

Can you post contents of yours "userpatches/config-default.conf" file too?

 

The differences of loaded file sizes are strange indeed:

142 vs. 244 - that's "/boot/armbianEnv.txt" - we should have exactly the same file here out of the box but maybe you were referring to a build before my latest changes with extra logging

6514583 vs. 7556947 - that's "uInitrd-4.4.192-rk3399" - 1M difference in init ram disk - this I cannot explain, yet

 

Can you share the "/boot/initrd.img-4.4.192-rk3399" file from your install?

Link to comment
Share on other sites
pask

pask

Posted
Posted

Thank you @piter75

While booting your minimal default image (as well a default desktop one compiled by me using your last commits), if the ttl serial dongle is plugged in, my board gets stuck somewhere at kernel time. Here is a log http://ix.io/22L4

 

For many tries I had not understood that the problem was, actually, the ttl dongle itself.

But, as a last try (given that I was suspicions because of the lack of hdmi activity during kernel boot, at least until it went stuck), I have disconnected the serial debug dongle, and finally I have seen hdmi activity and, at the end, the login prompt.

In other words, the problem with the default kernel image seems to be the serial dongle plugged in.

 

On the other hand, once booted the board (default kernel) without the ttl dongle plugged, and once normally running the Armbian OS, if I try to plug the ttl usb dongle into my laptop usb port, the board freezes.

 

 

 

 

 

Link to comment
Share on other sites
Enrico

Enrico

Posted
Posted

Hello I am new here and from Germany,

 

I got 2 Nanopi m4v2. 

I tried all image i found but nothing Booting.

 

only the buildroot from friendlyarm is booting but it is with asia symbols on the desktop.

 

I Need the nanopi as Server for IoBroker (NodeJS). no Desktop needed only minimal System

 

I used a Sandisk microSD class10 32GB (New)

 

what can i try i need the server to dezember and nothing works:angry:

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
2 hours ago, Enrico said:

Hello I am new here and from Germany,

 

Welcome!

 

2 hours ago, Enrico said:

I tried all image i found but nothing Booting.


This board is not supported yet. It is expected and known that it doesn't boot. I would add notes to the download pages, but I simply have too much other things ... We are working on it.
 

2 hours ago, Enrico said:

i need

Minimal stable system is the most expensive and hard thing to do. Everything else is cheap.

Wait until you don't read information about support here: https://docs.armbian.com/Release_Changelog/. You can also try to use unofficial test builds but I don't know if they work good enough to rely upon ... 

Link to comment
Share on other sites
pask

pask

Posted
Posted
12 hours ago, Enrico said:

Hello I am new here and from Germany,

 

.

 

I Need the nanopi as Server for IoBroker (NodeJS). no Desktop needed only minimal System

 

 

 

10 hours ago, Igor said:

 

Wait until you don't read information about support here: https://docs.armbian.com/Release_Changelog/. You can also try to use unofficial test builds but I don't know if they work good enough to rely upon ... 

 

@Enrico

You can use the minimal "test" image shared by @piter75 some posts above: it works already quite well, altough more testing is needed.

You can also compile it yourself using nanopim4v2 ddr branch from armbian/build git repository. 

Link to comment
Share on other sites
piter75

piter75

Posted
Posted
23 hours ago, pask said:

the problem was, actually, the ttl dongle itself

That's odd. Especially that the same dongle works for you in dev kernel.

If only I could replicate the issue with my CP2104. I will try to use one of the other dongles I have and see.

Out of curiosity.. What dongle is that? Do you use TX,RX and GND wires?

I guess that it was working well for you with NanoPi M4 default image patched by you with RockPi 4's u-boot?

 

Not that it will change anything for your issue but I will rebase my branch onto master now before further experiments.

 

It would be great if anyone else beside us would try to make a default's branch build from this branch (nanopi-m4v2-u-boot-v2019.10-ddr-miniloader) or dared to use the binary image here: https://drive.google.com/open?id=1xAh4i7cw9KgVo4ZGWm5F58nMXfIB5li4

Link to comment
Share on other sites
pask

pask

Posted
Posted

My usb ttl dongle is a "DSD TECH SH-U09C5" with a FTDI FT232RL chip.

 

Here is today dmesg from the default kernel image http://ix.io/22SV

and it doesn't look like totally "healthy" to me

 

Yes I use TX,RX and GND wires. As soon as I plug in the dongle (or connect the gnd to the board), the nanopi m4v2 freezes. The problem is that I do not see anything recorded in the logs of the freezing event.

 

 

 

Link to comment
Share on other sites
piter75

piter75

Posted
Posted
4 hours ago, pask said:

it doesn't look like totally "healthy" to me

Doesn't. You probably had a display connected? I will test that scenario.

 

4 hours ago, pask said:

or connect the gnd to the board

This seems more like an electrical problem but as you said before... it works well in "dev". I am puzzled :(

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept