jock
-
Content Count
244 -
Joined
-
Last visited
Posts posted by jock
-
-
I think you are lucky. The firmware blob is already there (you can see the version: 5.90.125.104), but you need the txt file which is also called the NVRAM.
You just need to try to copy /lib/firmware/brcmfmac-ap6330-sdio.txt into /lib/firmware/brcm/brcmfmac4330-sdio.tronsmart,vega-s95-meta.txt and reload the brcmfmac module (or just reboot the machine).
If that one does not work or work badly, you may try to copy /lib/firmware/brcmfmac-ap6330-sdio.bin over /lib/firmware/brcmfmac4330-sdio.bin to replace the binary blob too with a blob very specific for ap6330, which may work better and enable 802.11a frequencies too.
-
Oh God, no sd card slot is something which is over the red-line-of-dignity for such boards
. That's a pity anyway, because the board looks like quite well arranged and of good quality.
Maybe there is a chance to let something boot from the USB with the existing u-boot and maybe even maskrom. The rockchip boot flow (here) talks about booting from USB.
I never had experience of that and never read about, but if it is possible it could be really useful!
-
Hello,
following the recent thread on LibreElec forum about an unofficial image for rk3229 devices, I would like to make public the work made by me and @fabiobassa about bringing rk322x support to armbian.
For those which are interested, at the moment it is available on github -> here <-
It is still in a heavy work in progress status, but all the fundamentals are in place.
Most of the love has been poured into supporting and bringing up the legacy rockchip 4.4 kernel, but in the near future the goal is to fully support the mainline kernel.
What works now on legacy kernel:
- Two rk3229 tv box board (the signature on the PCB says R329Q and Chiptrip xt-mx4vr-v01), as a proof of concept
- Mainline u-boot
- OPTEE provided as Trusted Execution Environment
- All 4 cores are working
- Ethernet
- Serial UART (configured at 1.5 megabits/s, but will be switched back to 115200 bps soon)
- Thermals and frequency scaling
- OTG USB 2.0 port
- EHCI/OHCI USB 2.0 ports
- MMC subsystem (including eMMC, SD and sdio devices)
- Hardware video acceleration (via RKMPP)
- NAND is available (but not as boot device due to mailine u-boot missing the rockchip NAND driver)
- SSV6051 wifi over SDIO (crappy driver, blacklist ssv6051 driver in /etc/modprobe.d/blacklist.conf in case your kernel crashes)
- Whatever is supported for other rockchip devices in legacy kernel, including possible graphics acceleration support
Building:
You can build your own image follow the common steps to build armbian for other tv boxes devices (ie: when you are in the moment to choose the target board, switch to CSC/TVB/EOL boards and select "r329q" or "xt-mx4vr-v01" from the list). In case your board is not listed here, I suggest you to try with xt-mx4vr-v01 board, which has more chances to boot.
Prebuilt images:
If you don't want to build Armbian yourself, there are some prebuilt images already available:
- Armbian 19.11.5 Ubuntu Bionic Desktop 18.04 - kernel 4.4.189
- Armbian 19.11.5 Debian Buster Server Minimal - kernel 4.4.189
As long as this is a work in progress, I suggest you to try building the image yourself for your board because every prebuilt image will become obsolete very soon.
Quick installation instructions:- In order to run armbian from an SD card you need to put the device in maskrom mode. To do so, follow the instructions below.
- Flash the image on the sdcard, plug it in and plug the power cord
- Wait some seconds, the led should start blinking soon. HDMI output during boot is not available yet, so just wait for the kernel log and login prompt; the first time the boot process will take a couple of minutes or so
- As usual, armbian default credentials are user: root password: 1234
Putting the device in maskrom mode:
It is essential that the device is put in maskrom mode to let it boot from the external sd card.
In order to do so, you need to erase the internal eMMC/NAND flash memory. If you don't want to erase the existing firmware, at the moment you can't proceed.
You obviously need to do this step only once.
- Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. If you prefer, you can compile it yourself from the sources available at official rockchip repository
- Unplug the power cord from the tv box
- Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors)
- Plug the other end of the USB Male-to-male cable into an USB port of your computer
- If everyting went well, using lsusb you should see a device with vendor ID 2207
- run ./rkdeveloptool -ef and wait a few seconds
- once done, the internal eMMC is erased and the device will boot from the sdcard from now on
Note: rockchip devices cannot be bricked. If the internal flash does not contain a bootable system, they will always boot from the sdcard. If, for a reason, the bootable system on the internal flash corrupts or is unable to boot correctly, you can always force the maskrom mode shorting the eMMC clock pin on the PCB. Just google around if you get stuck on a faulty bootloader, the technique is pretty simple and requires a simple screwdriver.
I will continue to work on this project and refine both the legacy and mainline kernel and when the support will be in the same ballpark as other targets I will ask @Igor if it is a good idea to merge it into the main armbian repository.
Critics, suggestions and contributions are welcome!
Credits:
- @fabiobassa for his ideas, inspiration, great generosity in giving the boards for development and testing. The project of bringing rk322x into armbian would not have begun without his support!
- Justin Swartz, for his work and research to bring mainline linux on rk3229 (repository here)
-
2 hours ago, fabiobassa said:@jock
first of all ty for your kind replay
well you are the 1st to go deep in specific problem.
I googled a lot about this , what i am experiencing when I launch chromium by the command line is:
as I said many many times I am not a coder, but a good technician with good soldering skills and optimum hardware modding, but of couse can even read a bit of " diagnostic" so it is clear there is a mismatch between kernel driver and userspace libraries
anyway here it goes the new 3ad on rk3229 deviceshttps://forum.armbian.com/topic/12401-long-story-linux-on-rk3229-rockchip/
I have no problems to go on mainline 5.x.x, but here is lacking of rk_nand drivers so compilations will only work on devices with emmc
post scriptum :
maybe you forgot the link to your work ???where ??
Oops, I removed the link by mistake...
I fixed it, so you can following the link in the previous post. You can compile the driver and install it, it may work or may not work, as I said I don't know the DRM state for rk3229. Then you need to compile and install the kernel driver for mali 400/450 (rk3328 has the mali 450, you should be able to use that one), then install the userspace egl/opengles libraries. It's a bit long journey, I know.
Thanks for the new thread, I will read it into, even if I don't own an rk3229 box (I got a rk3288).
edit: You can take a look to this post, you can find there a precompiled armsoc (which may or may not work for your xorg server version) and some instructions on how to install it. Armsoc driver replaces the default Modesetting xorg driver, which in general is not a great idea, but only Armsoc is capable to let EGL and OpenGL ES proprietary userspace libraries work for 3D acceleration.
edit 2: hardware acceleration should also work on legacy 4.4 kernel. There you should also get some video decoding acceleration which will probably never be supported on mainline for that chipset. But you will need a different armsoc driver than mine if you want to run it on legacy 4.4 kernel because the DRM interface is different (no generic dumb buffers on 4.4, instead there are per-vender IOCTLs :/ ) and the armsoc driver has to deal with that.
-
On 12/8/2019 at 5:10 PM, fabiobassa said:@hexdump
yes you right never opened a different 3ad
but I went in bad mood when I read this on official respeaker site:
it seems no interest in developing a decent support to video acceleration
BTW i can publish at least a method to get a working kernel if this interests someone
My armsoc variant (you can find it here) has decent support for video acceleration. To be honest I just fixed some minor issues to get page flipping when in full-screen and copy-pasted some code to allow rockchip, amlogic and allwinner chipset to use the DRM dumb buffers in mainline kernels; nonetheless using it you can then use the proprietary Mali drivers to get windowed and full-screen 3d acceleration. I don't what is the state of DRM bits for rk3229, maybe it worth a try (but you need mainline kernel).
-
5 hours ago, eric971 said:Hi,
i have installed armbian 5.98 aml debian buster desktop on a x96 mini smartbox tv with the meson gxl s905w p281 dtb file. The desktop run but only 1 gb memory is available.
how do i do to have 2 gb memory available ?
Best regards.
Modifying the memory node in the device tree should suffice to match your hardware configuration
-
On 10/24/2019 at 8:22 AM, hetao said:Then I guess this much cheaper H96 max rk3318 is more suitable for me
I want to underline that AFAIK rk3318 is still missing support from opensource communtiy, it does not even boot (ie: no documentation, no source code, ...)
If you don't want to run armbian or any other Linux distro soon and possibly never, it could be.
Personally I would not choose rk3318 for anything at the moment. S905X2 and S905X3 are in a better shape according to http://www.linux-meson.com and have more modern hardware on board
-
@fabiobassa Open a new thread focusing just on rk3229. It's a very old SoC, and probably you won't get much support from the community because of the newly-released SoCs, but nonetheless it's easier by far to find and share experiences in a dedicated thread.
About acceleration, I guess you mean hardware graphics acceleration? If so, it's up to rockchip to release the right ARM Mali drivers tailored for the rk3229 chip, nonetheless the opensource lima driver landed in mainline kernel and mainline mesa and it is already working at least for some clients (ie: Kodi)
-
On 10/5/2019 at 12:26 PM, pro777 said:jock, do you have the opportunity to publish the latest images with Armbian from your repository?
Just made a fresh Ubuntu Bionic image with kernel 5.3.4. It's untested, but should work flawlessy: https://drive.google.com/open?id=1YTw2gD21G7nyXZZmJac-u4qsWkuoeK9X
-
Theoretically rk3318 is a cheap version of rk3328. We don't know yet perfectly what rockchip means with "cheap version", what is stripped down and what has been removed from rk3328 that makes it less expensive because there is no datasheet, no official launch and no technical documents about.
It's just my guessing that maybe they reduced the video encoding/decoding media features, but some other people said that the rk3318 has a bit more powerful GPU than rk3328, and on par with s905x (which is a bit strange, because rk3318 should be the cheaper version...)
edit: ah, rk3328 has support from armbian and mainline kernel, 3318 in theory is exactly the same but still does not appear officially anywhere
-
Hello, I managed to bump the rockchip-dev kernel to 5.3.y on my fork. After removing a couple of redundant patches and updating two or three of them I'm able to compile with no problems. The new kernel also boots fine on my rk3288.
Don't know if anyone is already working on this (maybe @Igor or @TonyMac32), if my work can ease someone's else fatigue I can make a merge request from my repo to main armbian repo for code review (the single commit is here) documenting the steps I did.
-
22 hours ago, aElmecker said:Which device are you using?
a tv box (xt-q8l-v10)
22 hours ago, aElmecker said:I changed the mode in the device tree, but nothing is happening...
I used both the latest legacy and mainline kernel image download for the tinkerboard.
Mostly the same as yours, but I tried different OTG adapters and all worked fine.
BTW, mine was just a suggestion to play with, as long as I don't have a tinkerboard to test by myself it's not the real solution.
Do the OTG port can be used as a HOST port with official OS?
-
7 hours ago, aElmecker said:But shouldn't dr_mode = "otg" work, because it switches automatically to slave or master depending on the cable you insert?
It should, but I don't know if there are all the bits in the drivers and if there's something needed to do in userspace (like udev rules, usb mode switching, ...).
I don't own a Tinkerboard but a device based on rk3288. The OTG port comes out directly from the SoC and dr_mode="host" works flawlessy on my device
-
On 8/9/2019 at 2:47 PM, martinayotte said:In such case, then, you could create a patch that will increase default value directly in common/usb_hub.c ...
I had the chance to try (had to bring out the serial adapter, cables, etc...) and I confirm it works!
Finally I decided to not hardwire it in u-boot but set the environment variable, which is fine for my setup. Definitely a video console could be really helpful to tinker with u-boot environmental variables instead of the need for the serial adapter and a separate PC each time...
-
Looking at the device tree, the OTG port is explicitly enabled and configured in "otg" mode, so there is a hint that could possibly work but it is not an evidence.
You may try to decompile the device tree, find this section:
usb@ff580000 { compatible = "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2"; reg = <0x0 0xff580000 0x0 0x40000>; interrupts = <0x0 0x17 0x4>; clocks = <0x7 0x1c1>; clock-names = "otg"; dr_mode = "otg"; // Change this to "host" g-np-tx-fifo-size = <0x10>; g-rx-fifo-size = <0x113>; g-tx-fifo-size = <0x100 0x80 0x80 0x40 0x40 0x20>; phys = <0x40>; phy-names = "usb2-phy"; status = "okay"; };
and change dr_mode into "host". Then recompile the device tree and try again.
Maybe the mode can be changed at runtime, but I'm not aware of any way to do it.
-
10 minutes ago, qstaq said:Thanks @jock
I have created a new dtb with the following change:
linux,cma { compatible = "shared-dma-pool"; reusable; size = <0x0 0x2000000>; alignment = <0x0 0x400000>; linux,cma-default; };This should reduce the cma size to 32MB (0x2000000) if I understand correctly?
However even with that change I still see "cma: Reserved 256 MiB" in dmesg, not 32MB as I would expect. I have also tried various different "cma=x" values on the kernel command line but the argument seems to be ignored
Have I misunderstood something?
Yes it should work that way. At least, it worked on my S905 machine. Didn't you forget to recompile the dts back to dtb, did you?
I'm not sure, but the reusable flag there should allow the kernel to use the same CMA region for its own needs, so it should act totally as a shared dynamic memory. You can anyway take a look to the official documentation becuase I may miss something: https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
-
On 8/8/2019 at 3:32 AM, qstaq said:I presume this is reserving 53MB for ROM and ATF?
The reg property is used to declare where the device have their memory-mapped region to interact with the operating system. You can imagine that devices (like the ethernet, the gpu, etc...) have one or more "windows" in the virtual address space of the CPU. Normally these windows are fixed in the address space, and the device tree declares where those windows are, letting the operating system drivers know where to access the devices.
In case of reserved-memory section, I see no real drivers involved there, so I guess that the memory is already reserved by bootloaders (the amlogic proprietary bootloader, mainly) and the declarations there inform the kernel not to use those locations because they are reserved.
You could remove the reserved sections, probably the kernel will show that more memory is available, but you may also expect malfunctions because some application may write in those reserved locations causing unpredictable behaviour!
Also check the size of the reserved CMA block (dmesg | grep cma). It should be possible to resize it via extraargs in armbianEnv.txt or recompiling the kernel. 8 megabytes there should suffice.
edit: I checked on a S905 device, the CMA can be changed only editing the device tree and should not be less than 32M, otherwise X fails to start on my configuration.
-
Thanks for the finding, I will try to test as soon as I can; unfortunately u-boot on rockchip has no video console, so it requires a serial port access :/
Also armbianEnv.txt is of no use here because the USB detection happens before its parsing.
-
On 8/1/2019 at 12:31 AM, Sergei Steshenko said:"You can add kernel command line parameters" - do you mean to add them to /boot/armbianEnv.txt or I can add them interactively while booting ? If the latter, how do I do this ? I.e. what keys should I press in order to be able to add 'extraargs' ?
@Sergei Steshenko yes, add extraargs=... to /boot/armbianEnv.txt to append options to the kernel command line.
@DRAGO4k I prepared a debian buster image (kernel is the very latest 5.2.6, u-boot is v2019.04) with the changes to the device tree I mentioned some posts ago. I'm currently using the modified device tree and I see no regressions. You can download the image from here to see if the power down/power up event still happens.
In the meantime I had a session with the serial attached to see why I had issues with my USB-to-SATA adapter. In practice it looks like there is no issue at all: my adapter takes some seconds to initialize. The box just does not enumerate the USB device because it is not ready yet. More of that, I found no evidence of any configurable timeout in u-boot not in the code nor in the environment variables. Eventually it looks like there isn't any issue from the box side, it's just the adapters that expose themselves after a timeout, probably to wait for the SATA disk to fully spin-up.
-
4 hours ago, DRAGO4k said:@jock I noticed a 1s where the USBs are powered off after 8s during boot, I suspect it is between first and second stage of the boot process ? I did not had time to add a serial to mine to see what is going on. will continue to debug this when I will have the time. It might be that the usb to sata bridge is powered off and needs a bit of time to initialize.
hmm that's interesting. I guess I should take some care about that. For example the kernel device tree contains these lines
Maybe adding regulator-boot-on and removing the pinctrl-* properties from the vcc_host_5v and vcc_otg_5v sections will prevent the USB ports to be powered off
5 hours ago, DRAGO4k said:used a 5v 2.5A Logitech power adapter (so it should be real 2.5A or close enough).
1) the power for the USB devices go through the power management chip and is 0 while the unit is turned off
2) the voltage dropped in a range of 4.3-4.8v under load meaning even 2.5A is not enough for the unit alone.
3) a ~0.20mA load on the usb dropped the voltage to 4.5v during idle.
4) a ~0.60mA load on the usb dropped the voltage to 4.2v during idle.
I will probably power this from an ATX PSU and measure the amps and usb load.
When i have the time I will test with an actual hdd.
1) I guess that there is a mosfet or whatever that controls the power to the USB ports, controlled by GPIO lines. You can see from the piece of the device tree I highlighted previously that GPIO 14 of bank 0 controls the power of the two non-OTG ports and GPIO 12 of bank 0 controls the OTG port. In theory it could be interesting to find the part on the board, read the signature on it and try to understand how much current it can sink.
2) True, under heavy load the chip and the board can draw quite an amount of current. Definitely an ATX power supply is a good way to benchmark this.
3) and 4) Very interesting! Where did you sample the voltage, I guess near the USB port? Clearly so much voltage drop even with modest load could not sustain any external hard drive.
-
4 hours ago, Sergei Steshenko said:@jock, the following are contents of my /boot/armbianEnv.txt file:
"
verbosity=1
overlay_prefix=rockchip
fdtfile=rk3288-xt-q8l-v10.dtb
rootdev=UUID=<whatever>
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u".
I.e. there is no 'rootdelay'.
@Sergei Steshenko You can add kernel command line parameters using the extraargs argument. They will be appended to the command line as is:
extraargs=rootdelay=30
If you are booting the kernel from the sdcard/emmc and the root filesystem is on the external HDD this may work. Of course if the HDD is suffering power outages (like you're describing), it won't work anyway.
-
13 hours ago, DRAGO4k said:it looks to me like a problem regarding the negotiation of amps over usb.
1) check power consumption of the hdd in a normal pc - or try to see how much is negotiated
2) check what power you get via Q8 or what is negotiated
as a last resort splice a usb cable, get the VCC and GND from a proper power supply.
PS: might be also a limit in the device tree for the usb(s) - or a limit of the hardware itself
@Sergei Steshenko - your power setup is a bit shady...if I have the time and find a working HDD I will try a spliced usb cable with external 5v power. what type of HDD did you use ? 3.5 ? or 2.5 ?
@DRAGO4k I also thought it could a software issue, I mean some kind of power limit to prevent issues from too demanding devices. So I tried the very same HDD with the original firmware and the motor failed to spin up, exactly the same way it happens on armbian. I guess that's a limit of the hardware.
A thing I noticed is that, while taking the photo above, the box is able to be backpowered from USB: while moving the things to arrange the photo, by the barrel connector slipped outside from the box but the box didn't turn off: the other barrel connector feeding the hdd was backpowering the box via USB
-
Hello @Sergei Steshenko, I'm in your very same situation: I have a external 2.5" HDD connected to a non-OTG USB port that contains the whole armbian rootfs. U-boot is installed in internal eMMC, so I don't required the sdcard to boot from the USB.
My HDD enclosure has a convenient barrel power connector for auxiliary 5V power. The non-OTG USB port itself is not able to spin-up the hard disk (neither the OTG port is), so auxiliary power is required.
I use a 12V 2.0A PSU which feeds a very small DC-DC switching power converter outputting 2A at 5V, which in turn feeds the box and the HDD. I thought that 2A are way too low for both the devices, in fact the DC-DC power converter gets quite hot, but after a couple of months of work it has not yet failed.
I have the same problem as you: if I turn on the box too soon, the hard disk is not detected. I have to wait a couple of seconds letting it initialize and then I can turn on the box. It's clearly a timeout issue.
After a quick look into u-boot compilation config file I could not find the USB timeout we are looking for, I guess I need to check better.
If the USB timeout is stored into an u-boot variable, it can be changed very easily setting it into /boot/armbianEnv.txt, otherwise it is necessary to recompile u-boot. Stay tuned, I'll look into it.
-
2 hours ago, ljones0 said:So after looking at this website am I correct in thinking that there's no xorg accel/drivers for the R69 until the 5.2 kernel?
ljones
If you mean hardware accelerated 2D desktop, the out-of-the-box xorg modesetting driver is sufficient for light desktop usage.
If you want 3D acceleration you need to compile and install the Mali kernel driver, compile and install the xorg armsoc driver and install the ARM Mali OpenGL ES proprietary binary drivers. It's not a titanic job, but requires some experience
[WIP] Armbian for RK322X devices
in Development
Posted
Mainline kernel is working mostly well for headless or simple terminal-based jobs. HDMI and DRM have some issues and probably the device tree is not complete: some video-related IRQs are not caught and the kernel blames for that.
I didn't test it very much, but other devices like ethernet, mmc and USB subsystems seems to be already stable enough.
Wayland would be great and would avoid dealing with mali blobs, but at the moment just inserting the lima module causes the kernel to issue a stack dump. DRM also is not in a very usable state.
I can't give many more details about mainline because at the moment the focus is on the legacy kernel to see what we can get from the SoC and boards; once the situation stabilizes on the legacy 4.4 kernel I'll happily give more love to mainline.
Mainline u-boot instead is in good shape for rk3229, I just recently added support for USB booting from the OTG port, but it still requires some fine-tuning to be really usable.