jock
-
Posts
1849 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
6 hours ago, MattWestB said:
Way not adding it to normal armbian archive like RK322X and getting UB and DEB in Desktop, CLI and Minimal in latest major release of armbian so user can install "experimental stable" build that is getting updates and is not so likely being broken ?
I'm not sure I understood what you mean with "normal armbian archive" and "experimental stable" terms
What I really would like is one and only one place for public images to be produced and deployed; at the moment this place is the github community repository and it is perfectly fine to have one single place with the images, just missing the stable kernel images for the reason I said above (ie: edge kernel is not guaranteed to always work).
The other images you find here and there, especially on users.armbian.com/jock URL, are old or experimental images, but surely unmaintained and prone to be erased sooner or later.
For all the other needs, there is always the option to build a custom image, it will receive regular updates via apt just as well as public images do.
-
2 hours ago, MattWestB said:
By the way the USB is the most crappy part in this boxes then the system cant handle reconnect of USB devices and is oft blocking all USB posts (both USB 2 and 3) if one device is getting problems and must re power the box for getting USB working.
Never had particular problems with USB on rk322x/rk3288, but on rockchip 64 bit (in particular rk3328) the USB3 implementation has some issue that makes it quite a bit troublesome. I never investigated very througly in it though.
-
@MattWestB @SteeMan I've been thinking about that too and I would have liked to ask @Igor in the last release meeting but I did not want to be off-topic.
Perhaps the community images are "too edgy", and perhaps it is more savvy to produce images with current kernel, then upgrade to edge via apt install, than starting with edge kernel, that is not guaranteed to work correctly, and then downgrade to current.
I just had a very brief test after burning an image with kernel 6.1 and, against all my thoughts because I was sure I already checked kernel 6.1, it does not boot on my rk3318 box, while kernel 6.0 had no troubles in booting (broadcom bluetooth was broken although).
Did not have the time and tools at hand to dig into the issue (moving into a new house...), but I hope to check better very soon, perhaps during the weekend.
About moving rockchip64 to 6.1 for the next release, I'm a bit reluctant and maybe a bit more testing is required.
32 bit rockchips although seems rather acquainted with 6.1, no issue and no troubles so far (my HA testing rig on rk322x has an uptime of 10 days and doing a variety of jobs that is pretty amazing for the piece of junk it was
)
-
@Serkan Polat no static public address, hundreds of device behind NAT, ... sounds like you should work on network level rather than trying to get access to the devices using some trick that firewalls may intercept. For example, I would consider to let your devices establish a VPN targeting an external public server that acts as a gateway. If your firewall allows free outbound traffic you should have no issues with wireguard/openvpn solution.
-
On 1/8/2023 at 3:19 PM, snowphish said:
After a few more hours of tinkering I figure only the 5.15.35 images are working on this (Armbian_22.05.0-trunk_Rk3318-box_bullseye_current_5.15.35_minimal)
for some reason everything else I have tried is not working.
Hello, good you finally had the board running happily armbian.
It would be nice if you could detail a bit over the non-working images: kernel version, where you did pick them, do you get something on the serial port if you have any, do the led is blinking while you try to boot or it is steady... You should be able to burn a testing image and a sdcard, plug it in and the system should boot from sdcard instead of internal eMMC.
-
3 hours ago, Vladd11 said:
Hello. Is it possible to use WiFi SmartChip 02e7:9086 with Armbian?
You can read exactly two posts above yours.
-
@kfj Hello, I imagine you are powering off and on the board when you experience such issue, aren't you?
The brand name of the tvbox says nothing about the board itself, so it is not helpful for other digging. Although sometimes it happens on a board of mine that on reboot the board does not boot from sdcard and then requires another power cycle to boot again.
Anyway you may want to install armbian on internal eMMC, since it looks it works ok on your board.
-
@Elbie Kittens Thanks a lot! I'm sorry I told you that you already should have been in maskrom mode, but it really had to work that way if you erased the eMMC. I really don't what was wrong in first instance. Surely the serial log would have been helpful.
About the tools, I don't know what tools are you using, but the armbian images are provided as xzipped raw images, not the proprietary format expected by AndroidTool for Windows, for example. Multitool is capable of burning them decompressing them on the fly, otherwise rkdeveloptool is able too but you have to decompress them first.
Anyway yes, it is very odd what you describe. X88 Pro has been tested in the past and should work without issues with armbian.
-
@Elbie KittensAFAIR I don't remember a rockchip device that was unable to be restored using the maskrom mode + male-to-male cable.
You can go with emmc clock pin shorting, probably one of the pads behind the eMMC is the right one, nonetheless in you erased the eMMC it should already go in maskrom mode.
-
-
@sum1saw Very well, the fact that you found the emmc clock pin is a great advancement!
There is no issue with power with your board. The problem you are facing is one of the first great headaches I had when I was first dealing with these boards.
In practice when you give the signal to power on the board through the button, the ACT8846 PMIC receives a signal to turn on the board. The ACT8846 then starts powering the SOC and the firmware boots.
The firmware then must raise a GPIO to tell the ACT8846 that the board has been really powered on and it has to hold the power on.
If the ACT8846 does not receive this feedback signal, it cuts the power.
If you keep the power button pressed, you can let the ACT8846 hold the power on for up to 10 seconds.
Another way hold the power on should be the presence of the OTG cable connected to PC and the board, or at least this happens on my board.
This message:
Unknow param: PWR_HLD: 0,0,A,0,1!
tells that the firmware wants the GPIO (bank 0x0, GPIO pin 0xA) that needs to be turned on (1) to keep the power on, but somehow u-boot does not understand that parameter, does not raise the GPIO and then the ACT8846 shuts the whole thing down.
Now the problem you have with AndroidTool makes me think if you have the right firmware for your device and the right AndroidTool for your device... maybe you need an older version since the rk3288 is a bit old device?
Also try and see if you are able to Erase the flash from Android Tool while you're in maskrom mode: that won't brick your device, but will force the device to boot from sdcard or, if no sdcard is found, go in maskrom mode without having to short the emmc clock pin anymore. (some reference here)
I don't know if you also have a raw image of the good firmware, in such case you may also try to boot with the multitool sdcard inside the slot and try to burn the raw image directly from there.
-
-
28 minutes ago, sum1saw said:
For shorting could I join both the pins at back of board which you circled and then supply the power and press on button to check. Also after short if device go in maskrom mode then will reflect on Android Tool other wise if forced to boot from SD card will that be shown on serial port ?
No, the pads on the back of the board must not be shorted together!
They must be shorted, in turn, to a ground point of the board, like the HDMI or ethernet metallic chassis.
The other part should be exactly like you describe: if there is no sdcard, the device goes in maskrom mode and it should appear automatically in Android Tool; instead if the sdcard is inserted, the soc will try to boot from there and, if a suitable image is found, the serial will tell you that the boot is happening.
-
@sum1saw Well that's definitely NOT in maskrom mode.
The device is booting, but then it gets stuck in u-boot for some reason. Also it looks like it is lacking the "miniloader" part, hence does not boot from sdcard, but it could easily be that u-boot gets stuck and does not go further.
IMHO you definitely need to short the emmc clock pin, either to get into maskrom mode or force the device to boot from sdcard.
The procedure:
1) remove power plug
2) insert power plug
3) put the screwdriver on the emmc contacts to short emmc pins or short the pad on the backside to GND
4) turn on the board (via power button)
5) unshort the emmc clock pin
6) you should not see anything on the serial; if you get any message from ddrbin/u-boot, then the board booted from eMMC, so start again from 1) and try another pair of contacts or the other pad on the backside
7) if you have the sdcard inserted, the board will probably boot from there, otherwise plug the USB male to male cable in the OTG port and into PC
😎 you should see the device in maskrom mode with lsusb tool within linux
9) use rkdeveloptool to restore the original firmware
-
@Elbie Kittens If you erased the emmc, it must be in maskrom mode, there is no further need to short the eMMC clock pins.
f it is in maskrom mode, the serial will be totally silent. Beware that there are other possible serial pins on the front side of the board, nearby the IR receiver. I don't remember which ones where in use for debug.
Beware that you MUST connect the USB cable in the OTG port only, other ports won't work at all. Your board should have one USB2 and one USB3 port, the OTG should be the USB2 port.
Also you should also try with and without the power plug connected, but try to power the box only via USB cable: when the USB cable is inserted in the USB OTG port, the box should be automatically powered on.
Last but not least: when you plug the cable, you should use lsusb tool to see if there is a rockchip device in maskrom mode, and not wait for something to automatically show up like a storage device.
-
-
@fr3d Thanks, happy new year to you too!
The OF dtb is shared among regular tinkerboard and tinkerboard S, the latter should just have a soldered eMMC.
About the still missing secret, well, I really don't know what's wrong. Looks like a software issue rather than hardware/dtb related.
If you could try a different router or a different distribution (maybe a debian one) could give some more hints... Also are you using WPA3?
-
-
@MR01 that 5.19.15 version was an experimental version; I compiled it without the extra wifi drivers because they were causing compilation issues. If you need something "stable" you should stay stick with the community version available on github which is updated regularly and prefer the "current" kernel flavour in place of edge.
-
@sum1saw The chances that the pointed CLK pin is the right one are near to zero, I can exclude that one is the clock pin you're looking for.
I was referring to the pads I circled in green in the attached image, and only to those ones! Don't go blind shorting pins randomly, or you will surely damage something. Feeding a bad voltage to the wrong device can easily damage it.
Also I see another "PWRON" label which is probably the power on button. Probably you need to briefly short that pin to 3.3V or 5V depending on which one is available during the board "stand by" to give power to the system. I don't think "volume up" is of any use in this case.
-
@MR01 It should work as usual, that part never changed and the boot priority is always sdcard -> USB -> eMMC. I don't remember if there were minor or major bugs in that part in the past. Perhaps you can try to upgrade the bootloader with apt update && apt install linux-u-boot-rk322x-box-current, but usually it is best to upgrade bootloader and kernel together, so I don't suggest to do that.
You can also try to boot multitool from USB stick, but the best way to do experiments is to burn an armbian image onto sdcard or USB stick so you don't touch the installed system. Of course remember to decompress the image first, if your image writer does not so automatically.
-
@Elbie Kittens AFAIR the X88 has the sdcard connected to sdmmc_ext bus, that's the reason why it won't boot from sdcard when firmware is erased. You should have install the armbian image right after erasing the emmc.
Now you are probably in maskrom mode, the board should show when connected to PC via USB male-to-male cable, but you have to use the board USB OTG port. Then you can use rkdeveloptool to upload an armbian image.
Read the paragraph The Multitool does not boot / How to burn image directly on eMMC on the support page
-
-
@mwe Perhaps you're trying to ping the wifi interface from another machine? Because the ssv6051 suffered a problem with the broadcast ARP packets that has been solved in the mainline flavour of the kernel, which does not work with NAND yet.
In practice the driver does not respond to ARP packets, so the wifi interface does not "announce" itself to others when asked to. The presence of the ethernet may cause some side effects that let the interface announce deliberately and so it works.
CSC Armbian for RK3318/RK3328 TV box boards
in Rockchip CPU Boxes
Posted
@Eli Ribble Thanks for testing. The missing ethernet is quite strange on that board. I have a sample of that board and it works fine on mine; maybe they are two different revision, but don't know.
About the HDMI problem, the 5.19.15 image you probably found here in the forum is an experimental image that uses the libreelec patches: when you upgraded the kernel, you got installed the standard armbian kernel without the libreelec patches and so the issue came back.
For now, the discussion to implement those patches is stuck, so don't expect seeing them as in armbian kernels soon. Sorry, but that's not my choice 😕 (see here for reference