Basically because the new kernel on my nanopc-t4 has a compatibility glitch with the nvme ssd, but the 4.19 kernel doesn’t seem to have this glitch.
So I want to try the old kernel.
Look for it in the “Manjaro Settings Manager” application.
You should be able to find it there, and you can then install it.
It’s available in the default Manjaro release, I don’t have an ARM processor, so don’t know if it’s available for ARM or not 
I think it is though:
I think he’s referring to:
To be precise I didn’t find Linux419 in the Manjaro ARM repositories. 
Hey @YoungFellow
Thank you for the reply but this is not right for ARM processors.
Currently only 1 kernel can be installed and used on arm as we do not have grub and uefi support yet.
Currently we only Maintain the latest LTS kernel and the RC kernel on arm project.
If you’re comparing Linux-4.19 from vendor then that is a BSP kernel and not mainline kernel.
Please check the difference between BSP and Mainline kernel on internet search as it is out of scope for this thread.
If you can share more about this issue then maybe I can look into it and see why it does not work as it works on BSP Kernel.
Regards,
1 Like
Sounds interesting.
Also is there a way to make the kernel print more logs? There doesn’t seem to be much valuable information.
https://bugzilla.kernel.org/show_bug.cgi?id=216009
I have reported this glitch.
Kindly follow this first.
Kernel.org team might not respond to your bug cause it does not belong to mainline kernel.
Someone have to write drivers in mainline to make it work. Comparing Apple/BSP kernel to Mango/mainline kernel is not right.
Also comparing Manjaro X86 with Manjaro ARM is not right, please try to ready more about the architectural difference.
It would be better if you can explain the real issue here in details.
I really can’t seem to get any more useful logs. 
I am not asking about logs.
I am asking about what works on 5.17 and what does not work.
Please share.
PCIE node is already present so I expect PCIE slot to work fine
Hey @Dark_iaji
Can you add this to the extlinux.conf file inside /boot/extlinux
earlycon in this line
console=ttyS2,1500000 root=PARTUUID=dcee78f5-50ba-42e0-b267-8179689bc7a4 rw rootwait audit=0 splash plymouth.ignore-serial-consoles
Like this
console=ttyS2,1500000 root=PARTUUID=dcee78f5-50ba-42e0-b267-8179689bc7a4 rw rootwait audit=0 earlycon splash plymouth.ignore-serial-consoles
With this you will get better logs.
Also which NVMe are you using ?
Samsung’s OEM SSD PM981a, this SSD works fine, and ZhiTai TiPlus5000, this SSD has a system freeze failure.
Oh dear. Now you explain the real issue.
ZhiTai TiPlus5000 sounds like unbranded NVMe and there is no detail about it on internet so I doubt any linux kernel developer would ever work on it.
Maybe you need to find more about this drive and share the details so maybe we can enable the required function for it or maybe it is just not very much supported on arm architecture.
Zhitai is basically the own brand of ymtc, a flash memory manufacturer.
The flash memory of ymtc is characterized in that the rewritable number of times is twice or even several times higher than that of Samsung’s flash memory.
Nice so maybe you should report it to ymtc so they can look into linux drivers and patch it as needed.
1 Like
I have actually reported the failure to the manufacturer of the SSD.
But I don’t think they’re going to spend more on such a niche segment, so this glitch might be a low priority.
root@FriendlyELEC:~# lspci -vv -n -s 01:00.0
01:00.0 0108: 1cc1:0021 (rev 01) (prog-if 02 [NVM Express])
Subsystem: 1cc1:612a
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 76
Region 0: Memory at fa000000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] Express (v2) Endpoint, MSI 1f
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s (downgraded), Width x4 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, NROPrPrP-, LTR+
10BitTagComp-, 10BitTagReq-, OBFF Via message, ExtFmt-, EETLPPrefix-
EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
FRS-, TPHComp-, ExtTPHComp-
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 16ms to 55ms, TimeoutDis-, LTR+, OBFF Disabled
AtomicOpsCtl: ReqEn-
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable+ Count=9 Masked-
Vector table: BAR=0 offset=00003000
PBA: BAR=0 offset=00002000
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
HeaderLog: 00000000 00000000 00000000 00000000
Capabilities: [148 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [158 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS+, Next Function: 0
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [168 v1] Secondary PCI Express
LnkCtl3: LnkEquIntrruptEn-, PerformEqu-
LaneErrStat: 0
Capabilities: [1d4 v1] Latency Tolerance Reporting
Max snoop latency: 0ns
Max no snoop latency: 0ns
Capabilities: [1dc v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=10us PortTPowerOnTime=14us
L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
T_CommonMode=0us LTR1.2_Threshold=0ns
L1SubCtl2: T_PwrOn=0us
Capabilities: [1ec v1] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?>
Capabilities: [2ec v1] Vendor Specific Information: ID=0001 Rev=1 Len=038 <?>
Kernel driver in use: nvme
Earlier, I reported that they took up the PCI ID of 1cc1, which belongs to ADATA, and they still haven’t replied to me.
U-Boot 2021.10-2 (Dec 25 2021 - 23:04:28 +0000) Manjaro Linux ARM
SoC: Rockchip rk3399
Reset cause: POR
Model: FriendlyElec NanoPC-T4
DRAM: 3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 3, mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
This file has been truncated. show original
The additional earlycon kernel parameter doesn’t seem to provide much more logging. :neutral_face:
1.293779] mmc_host mmc0: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 1.668818] dwmmc_rockchip fe310000.mmc: Successfully tuned phase to 192
[ 1.679025] mmc0: new ultra high speed SDR104 SDIO card at address 0001
[ 92.011931] random: crng init done
The UART’s kernel log timestamps seem to indicate that the kernel has become very slow. 
Yes I had similar issue before with Lexar NVMe then I switched on Kingston A1000 NVMe.
So from the above explanation, I understand that ZhiTai TiPlus5000 is a replica of ADATA drive and ADATA already have bad driver support in Linux.
And that’s sad.
I have learned that for data storage also go with the known brands like Sandisk, Kingston, Transcend, Samsung and Crucial.
In my experience using SSD production tools, usually if you don’t modify the ID of its device manufacturer, usually the default setting will have a default ID, which may be why it is 1cc1, but the kernel parameters can modify this ID ? This may load a more correct driver.
In fact, the reason for choosing TiPLUS5000 is that its flash memory reliability has been proved by the miners who mine Chia coins in the past. Basically, the number of times of erasing and writing can be comparable to the past 2DMLC, and the 1TB PC005 can reach 1000TB or even higher write volume. Samsung’s 970 EVO PLUS typically runs out of flash life before reaching this write volume, while the PC005 uses ymtc’s outdated 64-layer stacked V-NAND, and the TiPLUS5000 is a state-of-the-art 128-layer stacked V-NAND, theoretically It will only be better, and from the evaluation point of view, the read and write performance of TiPLUS5000 is good, and the biggest highlight is that its power consumption is very low, almost tied for the best with Hynix P31. The low-temperature SSD has excellent performance and the highest reliability. This is the reason why I choose to use this SSD on the ram development board.
1 Like
Then why did @Strit use the plural tense?
Perhaps a mistake?
1 Like
No.
Cause we so have multiple kernels and they’re more About arm soc variant based then like upstream version based.
Example
linux-lts
linux-rc
linux-khadas
linux-odroid
And many more.
Okay, thanks for the info @spikerguy
You’re welcome 
1 Like
I don’t know whether it’s lucky or unlucky. The RMA of SSD found technical support from the SSD master control manufacturer for me. They claimed that they just bought Nanopc-T4 last month to test SSD compatibility with embedded scenarios. It seems that this fault will be fixed in the next firmware version.
But RK3399’s PCI-E PHY compatibility is too bad, U-BOOT’s NVME boot has failed, and the kernel has also lost support for NVME boot in version 5.19. It seems that Rockchip has no intention of supporting the mainline kernel and U-boot’s PCI-E driver. to fix it, I’m now completely at a loss as to what to do next.
The good news is that the SSD firmware containing this fix has been submitted to ADATA, the manufacturer of the SSD, and optimistically I should get a firmware update for the SSD in a month.
Well, it seems that YMTC does not produce the PCB for manufacturing SSD, but only produces NAND, which is very common in the industry according to this SSD firmware engineer.
interesting.