Jump to content

jock

Members
  • Posts

    1848
  • Joined

  • Last visited

Posts posted by jock

  1. 20 hours ago, pakos96 said:

    I just used the script to change the DDR frequency and everything works perfectly at 660mhz. As per your advice I don't go any further to avoid bricking everything. Thanks!

    P.S. no crying (yet) :D 

    👍 (of course the "crying user" was not intended to you but to the average guy who stumbles upon the post and does not spend one minute to read the disclaimers!)

  2. 2 hours ago, Ben N Voutour said:

    i clocked it to 800 MHz and it is still working...

    Mmmh, dmesg does not tell anything. You need to post the serial output of the ddrbin, or do:

    sudo cat /sys/kernel/debug/clk/dpll/clk_rate

    that will tell you the effective frequency of the memory in DDR mode (ie: should be 1600000000 for 800 mhz memory, 1320000000 for 660 mhz memory, 660000000 for 330 mhz memory)

     

  3. 19 hours ago, Dripz said:

    Even using clock pin method. Red and Blue lights flash after some time.

     

    if the red and blue light are flashing, perhaps the new kernel has some issues with HDMI. The board is running fine, but recently some kernel adjustments broke HDMI output in some cases.

    You may login via ssh to fix the issue (install and older 6.1 kernel) or erase the eMMC and reinstall armbian, or boot a new armbian installation from USB (now you can, because the bootloader coming with armbian allows USB boot)

  4. @pakos96 attached to this message there is a script that does the trick to change the ddrbin frequency.

    Can be used on the boot block device directly on the board, or on a file to modify a ddrbin binary or an armbian image before sdcard burn.

     

    Usage and examples are in-built with the script, so launching it without arguments provides all the help that could be needed.

     

    Some notes:

    • THIS IS AN EXPERT THING. If you're not an expert, do not do this; do not come here later sobbing you made a mistake, or you will receive more insults that will make you cry even more 🫣
    • always always always test the ddrbin frequency change on a system booting from sdcard
    • if there is a bootloader installed in eMMC, it has priority: changing the ddrbin on sdcard won't have any effect until you clean the eMMC (or the bootloader)
    • some boards (notably X88 Pro) do not like ddr frequencies above 330MHz: they won't boot
    • changing the ddrbin frequency of the bootloader in the eMMC is very dangerous! You may brick the board (only way out: maskrom via eMMC clock pin gating)

     

    ddrbin-switch-freq.sh

  5. 9 hours ago, Dripz said:

    from what I understand I need to:

    1. Run the device in Maskroom mode (seems to already be in that state)
    2. get MiniLoaderALL.bin onto the device (I'm assuming using the upgrade firmware tab in rkdeveloptool) 
    3. rkdeveloptool wl 0X0 yourimage.img (I believe this means to write the image onto the emmc, not sure if I do this on the download image tab or the advanced functions tab) 

     

    1. yes, the device seems already in maskrom mode

    2. no, you're not "upgrading the bootloader" with that command, but you are just uploading a bootloader into the board memory and booting it to gain minimal management functionality. Nothing is written on the emmc in this step: if you power cycle the board, you have to do again this step

    3. yes, this step writes the raw image onto the emmc.

     

    Unfortunately I don't know exactly how this translates against AndroidTool/rkdevtool for windows, but my best guess is that you don't need step 2 because AndroidTool/rkdevtool already does that for you. Perhaps the "download image" tab is what you need, and there you should upload only the raw image starting at 0x00000000, because the raw image already contains all the necessary booting code, but I don't know if it is the right step. Perhaps @fabiobassa is more experienced with that tool and could lend a hand.

  6. 3 hours ago, Dripz said:

    hey man thanks for responding, the board I have is the RK3318 and I do not have a SD card. just a USB drive would it still work? and am I burning it with multitool or just the .img file 

    no, USB won't work. rk3318 does not support boot from USB.

    rkdeveloptool is available or compilable for windows too, you should use that to write the armbian image using and usb male-to-male directly on the emmc then.

    These instructions may help you: https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards/page/19/#comment-130453

     

  7. @Dripz Hello!

     

    Actually, the regular installation instructions via sdcard never mention Linux: all you need is multitool, an armbian image and a generic tool to write on sdcard.

     

    Since you're in maskrom mode (perhaps you erased the internal emmc), and you did not mention what board you have, the first thing you can try is to take a fresh armbian image (see first page, take a nightly build based upon kernel 6.6), burn it on sdcard, plug the sdcard in the box see if it boots.

  8. On 2/5/2024 at 12:49 AM, pakos96 said:

    I found the bin in the "rkbin" archive but I don't know now how I can make the change. Could you give me some suggestions?

     

    The ddrbin is "packaged" by the u-boot command mkimage, then some other code (uboot SPL) is appended to the resultant binary.

     

    In theory the ddr frequency is set in just a bunch of bytes in the ddrbin, so substituting the ddrbin (or altering the target bytes) on the sdcard/emmc with a bare "dd" command would work. But that requires some math and a hex editor to find the exact position where to put it with dd command AND I don't know if there are some CRC checks that would break the whole thing.

     

    I need to investigate a bit about, surely it is a job for a script because manual intervention would be a bit risky.

  9. 1 hour ago, shellless said:

    @Alex ThreeD the reason why there is no ground is that i used a usb cable to get the ground since i was afraid of ripping components up while soldering the wire to the ground pin on the serial interface; so i dont think that was the problem

    Ground must be connected on both the edge (the USB serial and the board), otherwise you can't get proper communication.

    That is essential and you can easily electrically break things when you don't connect the shared ground. Ground first, always!

     

    For the other problem about emmc erase: if you did erase from multitool and you can run multitool but not armbian from sdcard there could be two main reasons:

     

    • your armbian image is a bit old and has the 667Mhz ddrbin; recent images have a slower but more compatible ddrbin
    • your emmc is faulty and accepts but really does not execute erase/write commands (ie: you erase it, but the contents still remains)
  10. 6 minutes ago, some0ne said:

    The interesting moment here, is that when i've got working image in emmc the device don't want to boot from SD or USB (tried with reset button and even with a procedure which i did to enter in maskmod).

    If you meant a working image of the original firmware, note that only the Multitool can boot only from sdcard when a stock Android is installed.

  11. @some0ne I can't tell you why multitool does not find the eMMC anymore, could be several causes, but without the multitool log it is difficult.

     

    A note about maskrom mode emmc clock pin, in case you are using or used that in the past: when the emmc clock pin is gated, emmc is de facto turned off.

     

    If you are able to get in maskrom mode, then you can erase manually the eMCP connecting the board via male-to-male USB cable and using rkdeveloptool:

     

    ./rkdeveloptool db rk322x_loader_v1.10.238_256.bin
    Downloading bootloader succeeded.
    
    ./rkdeveloptool ef

     

    The loader file and other instructions are on first page.

     

    However, at the moment I don't understand what you have on your eMCP, if Android boots, or is already empty or what?

    Lastly, I don't know where your 60 seconds issue comes from. You should first clean the eMCP from anything on it and then boot pristine armbian from sdcard, then we may talk about that.

  12. On 1/21/2024 at 5:26 PM, hardheid said:

    Having spdif toslink would be so so sweet with my dac. Aplay indicates that the device is card 1, but when assigning plughw:1,0, hw:SPDIF, or hw:1,0 there is no sound and no light seems to be being immited. Have tried with a 4.4 and 6.1 build. The device is an MXQ 4K Pro with led settings 6 enabled.

     

    Does anyone know how to get the toslink spdif port running? Thanks so much

    Probably there is a GPIO that enables the toslink. Your board is new because I have never seen an rk322x with toslink. You should post photos of the board and the original device tree to get toslink supported.

     

    4 hours ago, Shone79 said:

    Does this legacy kernel after update support ESP8089 WiFi, or I must install mainline kernel on SD to use Wifi?

    esp8089 works only on mainline, legacy is not maintained anymore

  13. @Sean Perez

    Sorry for the very late answer; I'm not sure the orange pi debian contains the proper patches or the proper device tree things; I strongly suggest you to use on of the latest armbian images.

     

    I tested it on Allwinner H3 with 1gb of RAM and it worked well, but don't know the status of the hardware video decoders of H618. Probably it is better to use a kernel 6.6 and ask support in the allwinner forums just to know what kind of hardware decoders have.

     

    Don't know if CMA is an issue, 128mb should be more than enough to decode full-hd content. rockchip has no need for large CMA buffers since hardware decoders have their own MMUs. If allwinner has a similar design should even not need CMA buffers. Raspberry Pi (1, 2, 3 and probably 4) GPU/VPU instead has no MMU, so it requires CMA for video decoding and 3d graphics.

  14. 1 hour ago, some0ne said:

    Can you please share the older version of Multitool (build 52d0101 14 Mar 2021)?

    Sorry but I don't have the older versions around; they can be rebuilt cloning the github repo and moving to the commit of interest.

    Usually the latest is always the best and more compatible.

     

    1 hour ago, some0ne said:

    I've tried with that version in the first page - when i brick the device, it started the flash with that multitool - get around 60% and than reboots. After that multitool says there are no eMMC.

    Can you please share the older version of Multitool (build 52d0101 14 Mar 2021)?

     

    If the board reboots there is something else going on and the fact that after the spontaneous reboot there is no eMMC makes me think there is indeed something else going on, out of the control of the multitool.

    Erasing the internal eMMC and booting armbian from sdcard may help you trying to isolate where the issue could be, maybe your eMMC is just faulty or defective and is causing weird behaviour.

     

  15. On 1/18/2024 at 11:53 PM, suser said:

    First I want to say BIG thanks to @jock for his hard work!

    You're welcome

     

    On 1/18/2024 at 11:53 PM, suser said:

    And also i will love the "Play" symbol to blink with heartbeat after booting by adding to "/etc/rc.local"  something like:

    This is actually not possible with the openvfd driver because it is not wired to the kernel led framework but is a totally custom module that just exposes the hardware to userspace.

  16. @some0ne in the first page there is the updated multitool version.

     

    For some reason a closed source binary blob, on some very rare boards, turns off or put the board in suspend.

    The reason is not known, since something happens in a closed source blob.

    I don't know if it is your situation, but it looks something that already happened.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines