Jump to content

jernej

Members
  • Posts

    1144
  • Joined

  • Last visited

Everything posted by jernej

  1. http://linux-sunxi.org/IRC IRC log can be found at: https://irclog.whitequark.org/linux-sunxi/ Unfortunatelly, this log has troubles sometimes, mostly over the weekends.
  2. Yes, all audio drivers also have proper license now. We should see more H3 media related work now. I already informed Jean-Francois Moine about that, the guy who works on DRM and HDMI video & audio driver for H3 and A83T. He said it will take couple of weeks to upload the driver. BTW, from what I saw, SPDIF driver should already work on mainline. I'm not sure about I2S driver though. It would be best if you ask codekipper or someone else about I2S on H3 status on IRC. IIRC someone already started working on some audio drivers, apart from SPDIF and HDMI audio.
  3. I checked code quickly and while it is true, that it has mostly uninterested things, it contains some interested bits. Newest 3.4.39 BSP kernel, which could also be compiled for H3. I will make a diff to see if there is anything important, but I guess not. Other interested thing is different mali framebuffer driver. Instead UMP it is using dmabuf. Probably it is not interesting for Armbian, becuase it doesn't support X11. I guess that now it can be officially added to linux-sunxi collection of userspace mali drivers.
  4. I checked driver code and found out that it is a bit strange regarding how to chose correct working mode. In addition of setting op_mode to 2, you also have to set firmware_path correctly. I checked driver code and it is a bit too complex to quickly draw a conclusion without actually testing. From what I found, op_mode=2 should be enough. You said that this doesn't really work. Next thing would be to add firmware_path=/lib/firmware/ap6212/fw_apsta.bin In essence, driver doesn't need that path is correct. What is needed is "_apsta" in fw path. So please try this, manually: rmmod dhd modprobe dhd op_mode=2 firmware_path=/lib/firmware/ap6212/fw_apsta.bin If it works, you can consider tkaisers advice for persistent mode change. EDIT: Please try tkaiser's advice first. I still think that op_mode=2 should be enough.
  5. Ok, that is very strange. Message "queuing unknown CIS tuple" comes from a mmc driver and not wifi driver. Error -12 means not enough memory. It may be that those errors are just continuation of U-Boot troubles. Did any image work before? If it did, does it work now? Can you check if you have U-Boot patch "fix-h3-rev3-dram-calibration.patch" in your build system?
  6. @spock, please send full dmesg. Many times issues are found in the part which you may think it is not relevant. As I don't have X2, I can't help with U-Boot. Try lower RAM speed?
  7. Did you try persuade U-Boot team to change that? I will be gone only for a few days OE is using basically same settings as Armbian. It is true that I didn't check how much is new lately regarding thermal regulation, but I recently commited few patches for that. One issue here is scrolling news feeds. If you disable it, you can get reportedly 40°C in home screen. News feeds issue also affects RPi and regardless it is still enabled by default. What you describe may well be RAM speed setting as described by bsccara. Thank Allwinner for that. There is no documentation on CEC. What is included is based on reverse engineering and there is not much to be improved, except maybe libcec, which is BTW updated in my git (from upstrem OE) and is not yet included in any image, except if you compile it for yourself. Well, I tried to integrate Cedrus, but because I'm not really familiar with VDPAU, I didn't managed to make it work. There is progress on this for A20, which I didn't thoroughly checked, because I'm more interested in kernel hacking. Option with external player is already integrated in RetroOrangePi, but there was some complaints, so they actually combined RetroOrangePi and OpenELEC in one image. One missing feature is no overlays IIRC. This means no graphical controls like play/stop/pause buttons, progress bar, subtitles, etc. I also think that there are some issues with keyboard shortcuts.
  8. Then AFAIK the only option you have is to modify the kernel to support R_UART as a serial port.
  9. Well, it will be hard as you are on your own. I would consider either using USB to UART or cutting BT uart traces and soldering wires to it.
  10. Currently it is not possible to use it on any H3 board with BSP kernel or mainline (vanilla). Maybe it would work if you modify kernel, but AFAIK noone has done this. Why do you need exactly this port so badly? Aren't others enough?
  11. Well, for one, I already connected R_UART port for debugging sleep/resume and I received output. Secondly, all things in script.bin which starts with "s_" are meant for ARISC. Check those comments here: https://github.com/igorpecovnik/lib/blob/master/config/fex/bananapim2plus.fex#L1187Why they are here named "s_" instead of "r_" I don't know, but if you check pins, it's the same. Third, I checked kernel source code, s_uart is referenced in arisc.c as ARISC resource: https://github.com/igorpecovnik/linux/blob/sun8i/drivers/arisc/arisc.c#L483 And while it is true that s_uart port is referenced in sunxi-uart.c: https://github.com/igorpecovnik/linux/blob/sun8i/drivers/tty/serial/sunxi-uart.c#L787 It is dependent on SUNXI_S_UART macro, which is defined here: https://github.com/igorpecovnik/linux/blob/sun8i/drivers/tty/serial/sunxi-uart.h#L202 but only for sun8iw5 platform. H3 is sun8iw7. Hope this answers all your questions.
  12. What are you trying to do? R_UART is only meant to be used by ARISC coprocessor. You can first enable R_UART in script.bin, then connect it to PC and while booting or suspend/resume procedure you can observe output from ARISC. It will be mostly about current RAM settings, etc. Basically, it is just for debugging.
  13. For example: sudo iw phy phy0 interface add wlan1 type managed phy name may be different, check with iw phy Really don't know. Other than instructions above, I can't help you.
  14. You can always try to add additional interfaces with "iw" but IIRC this didn't really work. Let's hope someone else will jump in to help you.
  15. Which bluetooth? AP6181 doesn't have one...
  16. Be careful when you are doing something like that. OPi+ has 3.3V signals and standard RS-232 can go up to 12V if I'm not mistaken. You would certainly need some kind of level shifter. Depending on your skills, you can solder one quickly from spare transistors and resistors or you can order one.
  17. Then I can't help you with A20 board as I don't have it, but procedure for OPi+ still stands. It will bring you wlan0 and wlan1 interface.
  18. It is in the repo, it will be available with new release.
  19. Which BPI? M2+? Yesterday wifi driver was updated for it. If p2p interface is what you want (I'm not sure as I newer needed such thing), then it is as easy as uncommenting one line from Makefile, located at drivers/net/wireless/bcmdhd, DHDCFLAGS += -DWLP2P -DWL_ENABLE_P2P_IF For 8189es situation is similar. Open drivers/net/wireless/8189es/Makefile and search for: ifeq ($(CONFIG_PLATFORM_ARM_SUN8I), y) right after that line add this below EXTRA_CFLAGS += -DCONFIG_CONCURRENT_MODE Note, to actually be able to see these two Makefiles, you need patched Armbian kernel. There are some instructions on forum, how to build your customized kernel.
  20. Igor, I finished and tested autoloading patch with opi2 and bpim2+. I think it is safe to assume that we no longer need to wory about wifi drivers, at least until new version of bcmdhd module shows up. bcmdhd WOW patch: https://github.com/jernejsk/OpenELEC-OPi2/blob/e148c9b4d685ca3987364177d9c7db519c6345a0/projects/H3/patches/linux/linux-202-bcmdhd-add-wow-selection.patch wifi auto power on & load patch: https://github.com/jernejsk/OpenELEC-OPi2/blob/e148c9b4d685ca3987364177d9c7db519c6345a0/projects/H3/patches/linux/linux-203-rf_pm-auto-power-on.patch
  21. I have no idea, definetly is not /proc/ thing - that thing only power on wifi chip and scan for SDIO device. It is some udevd rule, maybe because it is different driver name? There is no point to have yet another folder. There is firmware for almost all chips supported by the driver and when board with a new version cames, only config file should be updated with new nvram file location.
  22. You can wait for tomorrow. I will try to patch rf_pm driver in a way, that this won't be necessary. This behaviour would be identical to that on mainline kernel - there is a node for wifi power in device tree. If it is present, wifi chip is powered and scanned for driver.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines