Bump to linux-4.x.y

[ndoo]

linux-3.4.y is quite an old release, and the amount of changed lines from upstream kernel is not too much.

Are there plans to work on a newer kernel version? Also it would be great if support for this SoC is upstreamed.

[rafaello7]

I have tested it. I hadn't any problems.

dd may be used as well. It's right, it contains FAT partition with 3 files. It contains also u-boot in boot sector.

[erazor83]

the display output is set to HDMI?

[rafaello7]

Yes.

[erazor83]

erazor@Nuc ~/Downloads> md5sum debian-installer-nanopi.img d262a0cdac38c90dc297072e7d0c8f40 debian-installer-nanopi.img this is probably correct too?

[rafaello7]

Yes, it's correct.

[rafaello7]

I have tested it again: welcome screen appears after about 20 seconds after power on. Although I have quck SD card... One question: does the blue led go off after some time?

[erazor83]

it's not going off.

with the default debian image the board just starts without issues... I'll add a serial adapter tomorrow and check if there is any output on the uart

[erazor83]

I got it. Looks like my UART is noisy and stopped the boot process.

[rafaello7]

And you've never had a problem with that original debian from this reason?

[erazor83]

well, i got 2 boards here... the M2 where I'm running Gentoo and the M3 which I haven't really touched yet...

[erazor83]

setup worked and booted gnome successfully :-)

[JamesKingdon]

I gave it a try but the install failed with sd card errors. Possibly just a bad card, although it's a brand new Lexar 300x UHS-1 bought from Amazon, and it looks ok when in my laptop. I'll do more tests on it and/or find a different card to try.

[weirdchaos]

Hi, thanks for your efforts!

After using debian installer, can we use the board with a lcd screen like the S430 or only HDMI output is available?

[erazor83]

This is probably a question of your kernel. So maybe all you need to change is the kernel binary. He could provide different kernels for this task. Not sure about uboot. This probably also needs some config changes.

[rafaello7]

LCD and LVDS output are disabled in kernel config. I have disabled because I haven't any such devices so I have no way to check whether the drivers are working.

[erazor83]

i got an LCD display and am willing to test ;)

[weirdchaos]

Thanks for your answer.

I'll have to compile my own kernel after I find time to use your debian installer. I need LCD output as I'm building a hand held device using a H43 lcd screen :)

[JamesKingdon]

I tried again with a different SD card but got the same failure (a little sooner this time) with lots of failed IO to the card. The cards are the same brand and bought at the same time, one 16G and one 32G. It's not impossible they are both bad, or I may have a NanoPi M3 with a problem with its card interface (but I haven't seen any signs of that running the official OS). It will be interesting to see if anyone else hits card io errors - maybe there is something in the installer image that is running a little too close to the limit?

[rafaello7]

At which point of installation the problem occurs? Is some heavy I/O performed at this time?

[JamesKingdon]

It's been at different points for the two attempts (sorry, I didn't record the exact point of failure), but yes I think most of the installation process is very heavy on I/O - basically writing large amounts of data to the card to build up the image. Once it has failed any attempt to repeat the step then fails very quickly.

[rafaello7]

I looked through the SD card settings, I have checked whether they differ from settings for kernel 3.x but I haven't found anything that would be relevant for the I/O.

You can try to install Linux in, let's say, "safe mode", I have prepared s5p6818-nanopi-m3.dtb file with disabled high speed card capability. You can get it using this link.

The file from link should be copied to SD card after put the the debian installer image onto SD card. The card should appear in system as one 40MB FAT partition. Please mount it and replace file s5p6818-nanopi-m3.dtb with this one (set name to s5p6818-nanopi-m3.dtb, not s5p6818-nanopi-m3-nohighspeed.dtb!). Unmount and try to install Debian using such modified card.

If the installation error reappears anyway, please do the following: press Ctrl+Alt+F2. Press Enter. When shell prompt appears, invoke:

ip addr ls

This command should show IP addresses assigned to network interfaces, among others IP address of the network interface configured by you (wlan0 or eth0). On your PC, open web browser and enter http url with IP address that appeared on the device, e.g. http://192.168.1.101/. A page with "Debian-installer logs and screenshots" should appear. Click on syslog. All the installation logs should appear. Please paste here the errors that appeared and a few lines around the lines with errors.

I'm wondering, maybe the card simply overheats. Try to test the card on stock Debian - do a lot of I/O and check kernel logs for possible errors. Maybe the stock kernel better copes with I/O errors.

[JamesKingdon]

Many thanks, that's much appreciated. I'll see if I can give that a go tonight (I'm embarrassed to say I have to negotiate with the family to use the main tv as a monitor!)

[erazor83]

Any idea how to change the video mode on HDMI? I'd like to use a WaveShare 1280x800 ctouch display.

[rafaello7]

In Display settings. But I see in driver source that only a few resolutions are available, 720x480, 720x576, 1280x720, 1920x1080. I will have to add a few more...

[erazor83]

@rafaello7 display settings of the kernel? is there a way to set this via kernel arguments? I've seen things like video=mxcfb0:dev=hdmi,1680x1050M@60

First of all, that raises the question whats the name of the framebuffer module and the second one would be if it supports the video arguments.

[JamesKingdon]

Ok, I gave it a go but the install still failed. I wasn't able to connect via http but I used the console to copy the syslog to a usb drive. I could also see from the console that roughly 200MB had been written to the card before the failure, and that after the failure the filesystem had gone read-only.

The first sign of problems in the syslog was

Aug 2 22:36:47 debootstrap: Setting up libncurses5:arm64 (6.0+20161126-1) ... Aug 2 22:36:48 debootstrap: Setting up libseccomp2:arm64 (2.3.1-2.1) ... Aug 2 22:36:48 debootstrap: Setting up libprocps6:arm64 (2:3.3.12-3) ... Aug 2 22:36:56 kernel: [ 675.728000] mmcblk1: card_busy_detect: error sending status cmd, status 0x80e00 Aug 2 22:36:56 kernel: [ 675.728000] mmcblk1: retrying write for general error Aug 2 22:36:56 kernel: [ 675.728000] mmcblk1: mmc_blk_cmd_recovery: general error sending stop or status command, stop cmd response 0x0, card status 0x80d00 Aug 2 22:36:56 kernel: [ 675.728000] mmcblk1: retrying write for general error Aug 2 22:36:56 kernel: [ 675.832000] mmcblk1: mmc_blk_cmd_recovery: general error sending stop or status command, stop cmd response 0x0, card status 0x80d00 Aug 2 22:36:56 kernel: [ 675.832000] mmcblk1: retrying write for general error Aug 2 22:36:56 kernel: [ 675.832000] mmcblk1: mmc_blk_cmd_recovery: general error sending stop or status command, stop cmd response 0x0, card status 0x80d00 Aug 2 22:36:56 kernel: [ 675.832000] mmcblk1: retrying write for general error Aug 2 22:36:56 kernel: [ 675.936000] mmcblk1: mmc_blk_cmd_recovery: general error sending stop or status command, stop cmd response 0x0, card status 0x80d00 Aug 2 22:36:56 kernel: [ 675.936000] mmcblk1: retrying write for general error Aug 2 22:36:56 kernel: [ 675.936000] mmcblk1: mmc_blk_cmd_recovery: general error sending stop or status command, stop cmd response 0x0, card status 0x80d00 Aug 2 22:36:56 kernel: [ 675.936000] mmcblk1: retrying write for general error Aug 2 22:36:56 kernel: [ 675.956000] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, actual 396825HZ div = 63) Aug 2 22:36:56 kernel: [ 676.000000] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 25000000Hz, actual 25000000HZ div = 1) Aug 2 22:36:56 kernel: [ 676.104000] mmcblk1: mmc_blk_cmd_recovery: general error sending stop or status command, stop cmd response 0x0, card status 0x80d00 Aug 2 22:36:56 kernel: [ 676.104000] mmcblk1: retrying write for general error Aug 2 22:36:56 kernel: [ 676.104000] blk_update_request: I/O error, dev mmcblk1, sector 17428240 Aug 2 22:36:56 kernel: [ 676.104000] Buffer I/O error on dev mmcblk1p3, logical block 2105826, lost async page write

There's then lots of similar errors for mmcblk1, including for the swap partition, plus other errors that are presumably a direct consequence of the file errors:

Aug 2 22:37:00 debootstrap: dpkg: unrecoverable fatal error, aborting: Aug 2 22:37:00 debootstrap: unable to fsync updated status of 'libprocps6:arm64': Input/output error

Ah, and here is where the fs gets remounted read-only:

Aug 2 22:37:04 kernel: [ 684.316000] blk_update_request: 65 callbacks suppressed Aug 2 22:37:04 kernel: [ 684.316000] blk_update_request: I/O error, dev mmcblk1, sector 581632 Aug 2 22:37:04 kernel: [ 684.316000] buffer_io_error: 62 callbacks suppressed Aug 2 22:37:04 kernel: [ 684.316000] Buffer I/O error on dev mmcblk1p3, logical block 0, lost sync page write Aug 2 22:37:04 kernel: [ 684.316000] EXT4-fs error (device mmcblk1p3): ext4_journal_check_start:60: Detected aborted journal Aug 2 22:37:04 kernel: [ 684.316000] EXT4-fs (mmcblk1p3): Remounting filesystem read-only Aug 2 22:37:04 kernel: [ 684.316000] EXT4-fs (mmcblk1p3): previous I/O error to superblock detected

[JamesKingdon]

I found this thread based on the status code: https://github.com/raspberrypi/linux/issues/1518

If that's in anyway related it might explain why two cards of the same type both behave the same way. I'll try and get hold of a different brand of card to try.

[rafaello7]

@erazor83 in this kernel drm driver is used, not fbdev. The driver source is here. Resolution should be set according to monitor capabilities - one of which both gpu and monitor agree to handle.

@JamesKingdon As I see the kernel for raspberry pi has added non-standard quirk. I can add the quirk, you will check whether it works for the card you have.

[awl1]

Hello @rafaello7,

first of all, thanks a million for your great work! Cool! :sunglasses:

I have tried the Debian installer last night, and I succeeded to do a proper 64-bits Debian Stretch install on my NanoPC-T3 on a 64GB SD class 10 card without any issues. HDMI mode 1920x1080 works out of the box for me! :smile:

But I need to raise a kernel issue, possibly related to the findings you described earlier in this thread: https://github.com/friendlyarm/linux-3.4.y/issues/3#issuecomment-314094255

On my NanoPC-T3, the kernel seems to detect only 5 (five - most interestingly, an odd number :confused:) instead of the eight cores. (Note that the original FriendlyARM 32-bit v3.4 kernel properly detects and uses all 8 cores, so I think it is not a hardware issue.)

Looks like the following line in dmesg output is at the heart of the issue:

[ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=5.

Do you have any idea what might be going on here and how to fix it to get all eight cores to be recognized? The full dmesg output looks like the following: dmesg_ouput.txt

Many thanks one more time for looking into this! :-) awl1

[awl1]

Additional info: cat /proc/cpuinfo output for the five CPUs detected as described above is as follows (note the very suspect BogoMIPS of 19.84 - I think this should equal the max processor clock in MHz):

processor : 0 BogoMIPS : 19.84 Features : fp asimd aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 3

processor : 1 BogoMIPS : 19.84 Features : fp asimd aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 3

processor : 2 BogoMIPS : 19.84 Features : fp asimd aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 3

processor : 3 BogoMIPS : 19.84 Features : fp asimd aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 3

processor : 4 BogoMIPS : 19.84 Features : fp asimd aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 3

[rafaello7]

It is strange, it looks wrong number of CPU's is read from dtb file. In the RCU line NR_CPUS value is kernel config value, the CONFIG_NR_CPUS. The _nr_cpuids value is obtained at runtime, in this case from dtb file. Does the kernel read config database from installer? I'm confused.

Secondary processors are brought up later, starting from line "smp: Bringing up secondary CPUs". Four secondary CPUs are expected and four are brought up. If the kernel would expect more CPUs but it would unable to bring up some, appropriate errors would appear.

[rafaello7]

The BogoMIPS value is architecture dependent. On arm it is usually small.

[awl1]

I'm not sure that indeed four "secondary" CPUs are brought up - in my dmesg output, note the line "SMP: Total of 5 processors activated." at the end of this block... (see below)

Also, when the kernel has finished booting, from a running Debian, wouldn't you expect /proc/cpuinfo to show 8 CPUs/cores? It still shows only five.

Where would you expect those "secondary" CPUs to show up in /proc if they were indeed active?

And do you get the same /proc/cpuinfo output that I get? Or is it maybe a question of NanoPC-T3 hardware revisions? Mine is one of the very first T3's that have been shipped more than one year ago...

[ 0.092000] smp: Bringing up secondary CPUs ... [ 0.124000] Detected VIPT I-cache on CPU1 [ 0.124000] CPU1: Booted secondary processor [410fd033] [ 0.156000] Detected VIPT I-cache on CPU2 [ 0.156000] CPU2: Booted secondary processor [410fd033] [ 0.188000] Detected VIPT I-cache on CPU3 [ 0.188000] CPU3: Booted secondary processor [410fd033] [ 0.220000] Detected VIPT I-cache on CPU4 [ 0.220000] CPU4: Booted secondary processor [410fd033] [ 0.220000] smp: Brought up 1 node, 5 CPUs [ 0.220000] SMP: Total of 5 processors activated.

[awl1]

Regarding the BogoMIPS: I need to reboot my T3 with the 32-bit kernel, but I think the BogoMIPS value there is 1400 like the S5P6818 max speed of 1.4 GHz...!?

[awl1]

Have you checked with the 4.4.x kernel from Samsung ARTIK from your previous attempts on the M3 whether it behaves the same regarding number of CPUs as the 4.11.6 kernel?

[awl1]

OK, so I hope the following is helpful:

It looks like with kernel 4.11, the second socket (cores 4-7) does not get fully initialized, rather only one of the "second" socket's four cores is detected.

lscpu 64-bit kernel 4.11: Architecture: aarch64 Byte Order: Little Endian CPU(s): 5 On-line CPU(s) list: 0-4 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 2 Model: 3 CPU max MHz: 1400.0000 CPU min MHz: 400.0000 BogoMIPS: 19.84 Flags: fp asimd aes pmull sha1 sha2 crc32 cpuid

CPU SOCKET CORE ONLINE MAXMHZ MINMHZ 0 0 0 yes 1400.0000 400.0000 1 0 1 yes 1400.0000 400.0000 2 0 2 yes 1400.0000 400.0000 3 0 3 yes 1400.0000 400.0000 4 1 4 yes 1400.0000 400.0000

lscpu 32-bit kernel 3.4: Architecture: armv7l Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 2 CPU max MHz: 1400.0000 CPU min MHz: 400.0000

CPU SOCKET CORE ONLINE MAXMHZ MINMHZ 0 0 0 yes 1400.0000 400.0000 1 0 1 yes 1400.0000 400.0000 2 0 2 yes 1400.0000 400.0000 3 0 3 yes 1400.0000 400.0000 4 1 4 yes 1400.0000 400.0000 5 1 5 yes 1400.0000 400.0000 6 1 6 yes 1400.0000 400.0000 7 1 7 yes 1400.0000 400.0000

nproc 64-bit kernel 4.11: 5

nproc 32-bit kernel 3.4: 8

[rafaello7]

@awl1 Could you do the following: download file from this link. Unpack it in some empty directory. In the SD card with Debian installed by you, in 1st partition (which mounts as /boot in Debian) replace files: s5p6818-nanopi-m3.dtb and vmlinuz with files from the tar archive. Next, run the _embedenv.sh script as root, with the SD card drive path on /dev as parameter. This srcipt embeds changed environment for u-boot on the SD card. Boot Debian on your NanoPC with the changed SD and provide dmesg output.

The kernel has added some debug logs. I hope the additional logs give me more information what is going on.

[awl1]

@rafaello7 Many thanks for looking into this! :-)

Just followed your instructions very carefully, but nevertheless the resulting SD does no longer boot when inserted into my T3... :-(

I will reinstate my serial debugging environment in order to hopefully find out what went wrong (I really have no idea, as embed_env.sh completed fine without warning, so it successfully detected the old bootargs at the proper offset; and replacing vmlinuz and the dtb file also should not really have failed!?) and will report back when done - possibly later today, but maybe only on Monday, so please give me some time... ;-)

Thanks again heaps for your great support! awl1

[rafaello7]

Have you the /boot partition as ext4 ?

I see there are two partitions on your card. I guessed the first one is /boot, second one is root. Is it correct?

[awl1]

No, the /boot partition is FAT16 (exactly as created by the installer) - is that wrong?

Disk /dev/sdi: 58,2 GiB, 62537072640 bytes, 122142720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x0e35cb1d

Device Boot Start End Sectors Size Id Type /dev/sdi1 2048 81919 79872 39M 6 FAT16 /dev/sdi2 81920 122140671 122058752 58,2G 83 Linux

[awl1]

And indeed, second partition (sdi2) is ext4 root (/).

[rafaello7]

I thought the installer forbids to have /boot as fat. If it is fat, the env.bin is wrong. Wait a moment, I fix the env

[awl1]

The installer does not forbid to create /boot as FAT, AFAIK the installer image had already contained this first partition as FAT16, the installer already showed it when it started up - so sdi1 existed already, and the only partition that I created was sdi2...

[rafaello7]

https://drive.google.com/file/d/0B8m_JgFBfEzwNXViS0pzVEF2Vlk/view?usp=sharing

[awl1]

HEUREKA - it works! All eight cores are up! You are a hero! Thanks a million! :-)

Here's the new output: dmesg_new.txt lscpu_new.txt cpuinfo_new.txt

Whatever you changed in the kernel inbetween, on top of added debug output, has done the trick: Now, everything initializes properly, and I can see all 8 cores as expected. :-)

In case you did not change anything by will (other than debug output), it most probably is a timing issue, and the cores may not yet be ready when additional debug output is removed again...

So did you change something on top of the debug output, and if yes, what?

Thanks, best regards & have a great weekend! :-) awl1

[rafaello7]

OK, I see... The dtb file in my installer is wrong. The updated dtb is fine.

One question, can your read mmcblk0p1 .. mmcblk0p7 without problems? Could you perform some tests?

[awl1]

OK, great, so the previous kernel with the new dtb file does the trick.

Regarding mmcblkX, do you mean mmcblk2 (the SD card) or indeed mmcblk0 (the emmc)?

From cursorily testing, it seems like I can access both fine (can mount and read partitions from my emmc containing the FriendlyARM 32-bit install).

What would you like me to test? I'm happy to do so... :-)

[rafaello7]

I'm asking for emmc card. NanoPi M3 does not have emmc memory but I have added the emmc support in the dtb given to you. I want to know whether the emmc works properly. I can even add to debian installer a possibility to install debian on emmc, but I have to know whether the emmc works. I need also to know how it is visible by u-boot. I guess the SD is visible as "mmc 0", otherwise the Debian installed by you would not start. But the emmc, is visible by u-boot as "mmc 1"? Can you verify that?

[rafaello7]

One more question: how you make a choice between boot from SD and boot from emmc? NanoPi M3 does not have any... ;)

[awl1]

How do I select between booting from emmc or SD? Well, the T3 has a small additional (real "hardware") button. When this button is not pressed, and you switch it on, it boots from emmc, while if the button is pressed when it is switched on, it will boot from SD card.

Regarding whether the emmc works correctly with the new dtb: Yes, as far as I can say, it does. Note that even when Debian boots from SD, mmcblk0 still maps to and means the emmc, while mmcblk2 represents the SD.

I haven't tried booting your 64-bit kernel from emmc yet: I fear that things might either stay this way (i.e. emmc stays mmcblk0 and SD still is mmcblk2), or might swap (i.e. when booting from emmc, SD might become mmcblk0 and emmc mmcblk2). I will need to check this as well when I have the serial debugger running again and report back.

As far as u-boot is concerned, am I correct that I need to reinstate my serial port debugging environment in order to see u-boot output and be able to interrupt it and make it list devices? I can and will do that, but please bear with me until (at the latest) Monday night before I will be able to do so...

Thanks again for your great work on this & have a great weekend! awl1