Jump to content

anonymoustemp

Members
 View Profile  See their activity

  • Posts

    8

  • Joined

  • Last visited

 Content Type 

Posts posted by anonymoustemp

    ayufan rock64 mainline PCIE initialization failure

    in Pine RockPro64

    Posted

    5.1.0-1111-ayufan tag.

     

    Kernel crash when PCIE card is installed (thus pcie host root complex initialize).

     

    Will try previous tags soon, BTW, if anyone successfully run the "mainline" kernel with PCIE cards?

      

    [  161.895780] io scheduler mq-deadline registered                              
[  161.897340] io scheduler kyber registered                                    
[  161.911264] io scheduler bfq registered                                      
[  162.136905] vcc5v0_host: supplied by vcc5v0_usb                              
[  162.740884] rockchip-pcie f8000000.pcie: no vpcie12v regulator found         
[  162.746764] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found         
[  162.750391] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found         
[  163.280713] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges:  
[  163.284059] rockchip-pcie f8000000.pcie:   MEM 0xfa000000..0xfbdfffff -> 0xf0
[  163.286820] rockchip-pcie f8000000.pcie:    IO 0xfbe00000..0xfbefffff -> 0xf0
[  163.302884] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00      
[  163.305119] pci_bus 0000:00: root bus resource [bus 00-1f]                   
[  163.306968] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff]   
[  163.310027] pci_bus 0000:00: root bus resource [io  0x0000-0xfffff] (bus add)
[  163.542130] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reg
[  163.560746] SError Interrupt on CPU5, code 0xbf000002 -- SError              
[  163.560932] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G             L    5.1.0-3
[  163.561051] Hardware name: Pine64 RockPro64 (DT)                             
[  163.561157] pstate: 60000085 (nZCv daIf -PAN -UAO)                           
[  163.561258] pc : rockchip_pcie_rd_conf+0x1e8/0x280                           
[  163.561356] lr : rockchip_pcie_rd_conf+0x214/0x280                           
[  163.561440] sp : ffff00001004b7f0                                            
[  163.561527] x29: ffff00001004b7f0 x28: 0000000000000000                      
[  163.561800] x27: 0000000000000000 x26: 0000000000000000                      
[  163.562047] x25: 0000000000000004 x24: ffff800004de13c0                      
[  163.562275] x23: 0000000000000000 x22: ffff8000f61d6800                      
[  163.562499] x21: ffff00001004b894 x20: 0000000000100000                      
[  163.562718] x19: 0000000000000000 x18: 0000000000000000                      
[  163.562936] x17: 00000000250ca3fe x16: 000000009ae7c865                      
[  163.563154] x15: ffffffffffffffff x14: ffff00001153d6c8                      
[  163.563374] x13: ffff8000ec3df91c x12: ffff8000ec3df190                      
[  163.563592] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f                      
[  163.563811] x9 : ff72646268756463 x8 : 00000000000003bd                      
[  163.564030] x7 : 0000000000000000 x6 : 0000000000000001                      
[  163.564248] x5 : ffff00001060f630 x4 : 0000000000000000                      
[  163.564466] x3 : 0000000000000000 x2 : 0000000000c00008                      
[  163.564686] x1 : ffff000017c00008 x0 : 0000000000000000                      
[  163.564961] Kernel panic - not syncing: Asynchronous SError Interrupt        
[  163.565098] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G             L    5.1.0-3
[  163.565196] Hardware name: Pine64 RockPro64 (DT)                             
[  163.565276] Call trace:                                                      
[  163.565367]  dump_backtrace+0x0/0x168                                        
[  163.565452]  show_stack+0x24/0x30                                            
[  163.565535]  dump_stack+0xac/0xd4                                            
[  163.565617]  panic+0x150/0x2e8                                               
[  163.565705]  __stack_chk_fail+0x0/0x28                                       
[  163.565798]  arm64_serror_panic+0x80/0x8c                                    
[  163.565884]  do_serror+0x11c/0x120                                           
[  163.565968]  el1_error+0x84/0xf8                                             
[  163.566064]  rockchip_pcie_rd_conf+0x1e8/0x280                               
[  163.566164]  pci_bus_read_config_dword+0xb8/0x108                            
[  163.566271]  pci_bus_generic_read_dev_vendor_id+0x40/0x1b8                   
[  163.566368]  pci_bus_read_dev_vendor_id+0x58/0x88                            
[  163.566464]  pci_scan_single_device+0x84/0xf8                                
[  163.566556]  pci_scan_slot+0x44/0x108                                        
[  163.566653]  pci_scan_child_bus_extend+0x5c/0x350                            
[  163.566749]  pci_scan_bridge_extend+0x37c/0x518                              
[  163.566849]  pci_scan_child_bus_extend+0x204/0x350                           
[  163.566945]  pci_scan_root_bus_bridge+0x60/0xd0                              
[  163.567042]  rockchip_pcie_probe+0x5ec/0x718                                 
[  163.567135]  platform_drv_probe+0x58/0xa8                                    
[  163.567223]  really_probe+0x1f0/0x3d8

     

    0

    [RockPro64] Armbian upstream kernel/uboot test?

    in Pine RockPro64

    Posted

    2 hours ago, chwe said:

    going through the links spotted something for @martinayotte (and maybe @TonyMac32)

     

    https://github.com/archlinuxarm/PKGBUILDs/pull/1691/commits/dfe2881b2eaf32a5b2289005c675888345684fd7#diff-2347b909a334e35e45d31e5bb4961a3f

     

    there's a a patchset for upstream u-boot for the ram part.. as OP says it's not running stable.. but at least they got upstream u-boot up.. maybe worth a look as well.. to clean the rk u-boot mess asap. :P

    Unfortunately, that's from myself and the you can see the original author mentioned that it's just a basic setup.

     

    In fact, upstream Uboot, even just using evb board config, can boot on that RockPro64.

    While USB doesn't work in that case and no sdcard support, only eMMC and ethernet, and I haven't tested eMMC.

     

    With that commit, I ran into the ram issue.

     

    0

    [RockPro64] Armbian upstream kernel/uboot test?

    in Pine RockPro64

    Posted

    The armbian idbloader/uboot/trust combo survives at least one loop.

    While my bad upstream uboot build can not even survive 10 tests of a single loop.

     

    Armbian community/build rocks!

     

    And here is my feedback to Armbian:

     

    Upstream kernel works relatively well with armbian uboot.

     

    What I have tested:

    1. boot (WORKING)
    2. SDcard (WORKING)
    3. git checkout for mesa (WORKING)
    4. memtester, still running at least one loop passed (WORKING)
    5. base system upgrade (WORKING)
    6. ethernet (WORKING)
    7. USB2.0 and 3.0 port (WORKING)
    8. PCIE slot, no root complex, although PCIE power is on (NOT WORKING)

    What I haven't tested yet but will test soon:

    1. Memory performance (upstream alarm vs armbian, armbian uboot)
    2. LLVMpipe wayland/X11
    3. Maybe some basic audio test on that 3.5mm jack
    4. eMMC (will take some time for that purchase)

    What I won't test:

    1. Blob X11/wayland, I just hate blob, especially when I just want a NAS build
    2. BT/Wireless, Just don't want to spend extra money on a NAS.
    3. GPIO headers, the same reason.

     

    Now it's my turn to "steal" some juice from the armbian/ayumi uboot branch for alarm.

     

    But AFAIK for nas build, I still need to use armbian legacy kernel for a while.

     

    0

    [RockPro64] Armbian upstream kernel/uboot test?

    in Pine RockPro64

    Posted

    5 minutes ago, chwe said:

    Are you currently on RCs for your rockpro? Didn't this guy just hit mainline?

    http://lists.infradead.org/pipermail/linux-rockchip/2019-April/023867.html

    Not in rc5 nor rc6 yet.

     

    6 minutes ago, chwe said:

    ram on rk3399 is a painful story and the main reason why we have two boardfamilies here.. one based on upstream u-boot (rk3399), and one based on bsp u-boot (rockchip64). Yours is part of the second..

    Just saw the rockchip wiki mentioning it's *UBoot* initialize the memory controller, so bad Uboot build and bad that upstream patch.

     

    I'm just taking the shortcut to use the armbian idbloader/uboot combo and running Archlinux Arm kernel to test if the v5.0.8 works.

     

    Will report back soon.

    0

    [RockPro64] Armbian upstream kernel/uboot test?

    in Pine RockPro64

    Posted

    23 minutes ago, Igor said:

    More people means more pressure (more wasted time) to already small and scattered developers base. I estimate that ratio is already very toxic, at least 1000 end-users on 1 developer. Most of end-users have no clue how much work is needed and they are usually reporting stupid, repeated and irrelevant things. We, on the other hand, are wasting time with educating, communicating to and support people and people are frustrated that things doesn't just work. And we are frustrated since its hard and expensive to deal with this complexity and people are not grateful ...  even just a few regulars are investing 20-50 hours per day into the project which is public and everyone benefits at the end. This time is covered way way below 1% which means all project costs are covered from our private budget. And users again expect a services worth millions of dollars.  

    Thank you very much for such information.

    As I'm completely new to SBC community, and the huge different from my previous kernel experience indeed surprises me.

     

    Now it totally makes sense.

     

    25 minutes ago, Igor said:

    Armbian mainline support goes this way - 1st stage, we attach or create own development branch and stay on that until difference with mainline becomes manageable. Then base source is switched to mainline and diff is added with patches. When things progress, patches are getting removed when they start to appear in the mainline. Ofc in reality this looks a lot more messy, but you get the idea. It's much more manageable.

    Makes sense for the situation.

     

    I'll check the branch to see if I can find something related and test.

     

    And explore the armbian repo to find some clue with the Uboot/firmware (which is my current assumption of the strange crash).

     

    Thank you again for the detailed explanation on the workflow.

     

     

    0

    [RockPro64] Armbian upstream kernel/uboot test?

    in Pine RockPro64

    Posted

    20 minutes ago, Igor said:

    Which is normal and expected. RK3399 mainline support is far away from stable.

    That's what I didn't expect at all.

     

    Shouldn't upstream get more review and tests? Or it's a completely different case for ARM world?

     

    Quote

    most promising up-streaming branch.

    That branch looks pretty promising, although some commits don't meet upstream standard just by a quick glance.

     

    But still it provides a pretty good clue for me to look into the random hang.

    It pretty much limits the modification to a reviewable size, which is a huge leap compared to legacy kernel.

     

    Thank you very much for the info.

    0

    [RockPro64] Armbian upstream kernel/uboot test?

    in Pine RockPro64

    Posted · Edited by anonymoustemp

    Hi,

     

    I got my RockPro64 board several days ago, and got *UPSTREAM* kernel (v5.1-rc5) and uboot (v2019.04) running on it using Archlinux ARM. (Sorry guys, I like upstream and Alarm more)

    The pull request for uboot-rockpro64 can be found here:

    https://github.com/archlinuxarm/PKGBUILDs/pull/1691

     

    The upstream kernel is in the official core repor of Archlinuxarm (and that's why I like Alarm so much).

     

    It boots and runs mostly OK on full upstream kernel/u-boot setup.

    On rc-kernel it even has HDMI output working, but no hardware acceleration. I'm waiting panfrost as the open-source driver, so far it doesn't matter much as I don't plan to use it with X11/wayland anyway.

    But it's awesome that you can just run GNOME3 on wayland, using llvmpipe.

    And I even compiled mesa with panfrost natively on that board, so the future looks super bright.

     

    However the biggest problem I hit is, upstream (5.0.8 and 5.1-rc5) kernel has random panic.

    The panic itself is Async SError, and mostly happens for memory heavy operations (memtester and heavy file operations like checking out the whole kernel code).

    The last panic I hit has no meaningful kernel calltrace, just el0_error_naked (user space triggered, and memtester is running)

     

    At first I thought it's faulty ram, but when using the rockchip kernel from Armbian, it no longer crashes any more.

     

    I have no clue what's going wrong, device tree? idbloader? trust.img? Uboot? Or just upstream kernel sucks? (I really hate to admit the last one)

     

    Is there any upstream kernel precompiled in armbian for me to test so I could rule out one more problem?

     

    Thanks.

    0
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept