Jump to content

Recommended Posts

Posted
Quote

 

Now I run MultiTool, select "Jump Start," and shut down the rk322x.
I burn my Armbian .img to the USB stick with: sudo dd if=/root/Armbian_24.2.5_Rk322x-box_bookworm_current_6.6.22_minimal.img of=/dev/sdb conv=fsync bs=4M status=progress

But when I turn on the power, the blue LED shows init (the same as with MultiTool), but the video doesn't appear again 

 

hahahha  I took my pendrive out of the OTG port and put it in the normal USB, surprise:

36a35a8b-9af4-4f72-b167-3e44efe877ae.thumb.jpg.b52c25f0e372eac1dd348b93277cb5ee.jpg

Tkys Team ❤️

Posted

Hello everyone!
 

I'm willing to develop a script that automates firmware, u-boot, and ROM compatibility testing with the boards via OTG.
 

I've thought of a workflow something like this:

1. Download a list of files by type from several different sources.
2. Extract files from pre-built images, ROM, loader, u-boot.
3. Check for duplicate files by size and checksum.
4. Apply and test in stages: ROM, loader, u-boot, kernel, rootfs, network, video.
5. Log what worked and what went wrong.
6. Since this process can take hours, emit a beep when user interaction is needed.
 

What I need help with from you:
Is this idea feasible?
Will it produce results and facilitate the implementation process on rk322X boards?
Can it be reused and adapted for other boards?
 

I have little experience with ROMs and ARM firmware, but if it's feasible, I intend to create a public repository for the community to help me with the development.

Thank you for your attention!

Posted

I would love to get this or support with the devices I own.

 

I think we should continue developing Mini-AndroidTV-PCs as easy as possible and give that junk devices a sensful feasible life.😃

Posted

@Aroldo Bossoni

 

The optimal would be understanding the reason why the watchdog triggers, but could be a difficult task without a hint because of the closed source proprietary trust os.

 

The easiest thing is to provide armbian images with the opensource trust os rather than the proprietary, which is totally feasible because it just requires to swap a file in the armbian build scripts. That would blow the issue away, but unfortunately the proprietary trust os provided DDR scaling and virtual poweroff. The latter is a seldom used feature, but the DDR scaling provided a dramatic improvement in performance and it is hard to give up on that.

 

Swapping the things at runtime is not savvy: when u-boot updates, the proprietary trust os will be reinstalled overwriting whatever you put in there.

 

I would be happy with opensource Trust OS and no runtime DDR scaling, but stil having it at a fixed decent rate (660MHz, instead of the default 330MHz), but some boards do not boot at all when they are instructed to boot at 660MHz.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines