Posts by jock2

    oneillb did you try to keep only a single CPU operating point in the device tree?


    On armbian I had many issues and crashes on a board of mine because the transition between the slowest (600 mhz) and highest (1.4 ghz) operating points was "too fast"; actually the legacy 4.4 kernel worked plenty well, but the mainline kernels crashed a lot in a matter of minutes or seconds.


    That what pretty strange on my case, but I solved by either using a single cpu frequency (thus not allowing the frequency switching), or raising enough the voltage of the slowest operating points to reduce the voltage gap between slowest and highest operating points.

    That board now runs pretty well with uptimes of several weeks! (this is the device tree overlay for the modifications I used in my case)

    The board will boot from SD (which I'm using to test out the LE10 builds) and fall back to NAND without issue when the SD card is removed... My problem is with stability once things are up and running... If the bootloader puts the board into 1T mode at startup, is that mode maintained through u-boot and kernel startup, or can the kernel driver switch the mode later on?

    Uhm, this makes my hypothesis invalid as the answer to your question is no: the kernel driver can't swtich from 1T to 2T.

    Once your box boots in 1T mode it can't switch to 2T mode.

    oneillb


    Code
    [    3.520762] rk3228-dmc 11200000.dmc: memory type DDR3, timings (tCL, tRCD, tRP, tRAS): CL10-10-10-25 command rate: 1T (mcfg register: 0x50021)
    [    3.535269] rk3228-dmc 11200000.dmc: detected DDR3 memory

    The 1T Command Rate may be the reason you get your issue.

    DDR memories have this Command Rate parameter which specifies how many clock cycle are required to send a command to the DRAM banks. It can be 1 clock (1T) or 2 clocks (2T). 1T is faster but less compatible, 2T is slower but more compatible.


    Most boards works fine with 2T, but 1T may let the system become unstable.

    On the contrary, a very small set of boards (like my r329q v3.0 and some other boards out there) works fine with 1T Command Rate, but don't boot with 2T Command Rate. This is way disappointing because the board freezes during initial boot with no other chances to interact with it.

    Long story short: if you install a bad loader on NAND/eMMC on a small set of boards (like my r329q), you may brick it and you have to force maskrom mode (the serial console will print the infamous "Err!" message).


    If you used my 660MHz loader that I posted on armbian forum, I may have set it CR incorrectly to 1T. I shall remove that loader which is not exactly stable for all boards.


    Now, since the dram memory controller driver is available for mainline kernel, using that 660MHz loader is less than ideal for many reasons. I may suggest to you to erase the NAND using rkdeveloptool and let the LibreELEC image boot with its own loader (which uses 2T Command Rate, as like as LE9.2 builds) and see if your board is stable that way.

    If it is stable, I can give you a properly compatible loader for your board so you could also install and boot libreelec from internal NAND.

    oneillb  ilmich This looks very very suspicious X/ (journal log):

    Does this sound reasonable?

    Well, not really to me... I mean, memory scaling is only for DDR3 boards; if your board comes with DDR2 chips then memory scaling is not supported and the kernel driver is instructed to bypass. Modifying that table should do no difference to your board.


    Also I'm using v88mars dtb too and I see that the [email protected] node in the device tree is disabled:

    So any change to the dram frequency table surely won't affect anything.

    I don't think I've removed the idbloader, I can reinstate the Android backup image using Multitool, and return everything back to as it was. Does that mean that idbloader is still intact?

    That's a point, you're right, the idbloader is still there if you're able to restore Android with multitool. So the issue is probably related to libreelec and a serial adapter is absolutely the way to go to debug.

    The gzipped libreelec image is burned very quickly because the uncompressed libreelec image is quite small (500 megabytes circa); the backup of the existing Android is the same of the whole NAND (8 gigabytes I guess).


    Multitool is quite capable to handle gzip and other compressed formats: it will decompress them on the fly while burning is in progress, so no need to do that manually.


    A possible issue that may come from your steps is the Flash Erase step you said you did. I don't remember if it is so, but it may be that the Erase Flash step completely erases the NAND, idbloader included. idbloader can't be installed again by multitool because of the NAND rockchip driver limitation and you may need to do that manually using rockchip upgrade_tool (see this post on armbian forum, paragraph
    NAND Bootloader Upgrade)

    Hi,

    Please take a look at miniloader. I got it from jock2 on armbian forum. Trust & uboot from your tar version which also don't work for me. Here are trust & uboot for your reference link

    Since you apparently removed the original idbloader (of which the miniloader is part), you have to follow two procedures I described in the armbian forum first post under the paragraphs:

    1. first restore a working idbloader: "NAND bootloader upgrade"
    2. install a special u-boot that allows USB boot: "Installation (without SD card, board with NAND)"

    Then you finally can put multitool and libreelec image on a USB stick and boot from there, using the "Burn image to flash" menu item.

    It's a longer procedure, but unfortunately you have the worst combo ever (no sdcard slot and NAND flash chip).


    A serial adapter attached to the box UART is very welcome, otherwise you're blind in case of issues.

    Hi,

    I tested the new build and I can confirm that it works (also ssv6051p wifi is ok, even if, quite strangely, I cannot ping the device and I cannot access via ssh over wlan interface, but outbound Internet connection is ok)

    Thank you

    Regards

    It is my opinion that it is strangely refusing to answer ARP "whois" network requests; once the 6051p successfully sends a packet onto the network, other network hosts discovers the MAC address of the 6051p and switches can finally route packets correctly.

    chewitt thanks for the moral support :D

    It would be a nice pet project, it could be useful to learn how to write a wireless driver for linux, yet I need to figure out where to start from; mostly I miss the background knowledge of kernel context, with its rules and function helpers. I would really love to read a valid book about kernel programming, but I just found ancient resources from 10 years old ago or even more. Kernel is a moving target, 10 years are quite too much...


    BTW icomm company seems to have took over SSV and they show ssv6256p on their site, but not ssv6051p; I guess the ssv6051p is just a so old and discontinued part that it is not interesting at all for the company. For my point of view, it is still a valid chip that deserve a decent driver.


    About the realtek clone, I heard about that for other chips, but never for ssv ones. I inspected the ssv source code but never found any hint about realtek compatibility. It looks to me that it is an ancient style code wrote by kernel newbies because there is tons and tons of boilerplate code that is totally useless nowadays and could be just thrashed away with no pain. I'll keep you updated if I try this feat :D

    I adjusted the ssv6x5x driver to work on armbian with legacy 4.4 rockchip kernel only. The driver is a huge mess. When compiled it turned out to be several megabytes, which is just wrong since a wifi driver should not be bigger than 50-100 kbytes.


    I would really like to start a project to rebuild a fresh new simple driver for ssv6256p and ssv6051p as knaerzche suggested to me some months ago, but yet I'd like to introduce myself to kernel wifi module programming first, which may take a looong time...


    The chip, although, proved to work pretty fine with nice throughput even with the onboard antenna!