• Content Count

  • Joined

  • Last visited

  1. It turns out that buildroot has exactly what I'm looking for. They call it KCONFIG_FRAGMENT_FILES. Essentially it allows one to just say that I want to use the default configuration, but change these specific options. I'm sure it wouldn't work 100% of the time, but it seems like it could be better in some circumstances than just replacing the current default configuration with an old, possibly now non-functional configuration just to change a couple of options.
  2. I have a Jenkins server that builds kernels/images for several boards that I own, and, for the most part it works very well. The biggest problem that I currently have is the kernel configuration. I need to add a few patches, which generally works well, and change a couple of configuration options, which sometimes fails. The problem is that I go through a process of creating a modified kernel configuration by first building a stock configuration. I then go into the kernel source directory under cache, make my changes, do a "make oldconfig", grab the new config file and add it to my userpaches directory. That works for a while, but eventually the kernel configuration changes enough that I get non-bootable images and have to go through the process again, potentially for each board. Is there a better way of doing this? Is there a way to build the kernel using the default configuration with just a few options changed?
  3. Do you have more information on this? I've been trying to setup my nanopi neo4 as an access point without success, and I believe the hardware is very similar, so it's likely a similar problem. FWIW, I got farther with the FriendlyArm distribution, but it still has issues that I haven't resolved yet. I would much rather use Armbian anyways. It's much more polished, and the support is top notch!
  4. I finally got it working. I don't know what the problem was, but I switched back to the default config and started from there again. This is a diff between the original script.fex and the one that enables composite video out: 314c314 < disp_mode = 1 --- > disp_mode = 0 317,318c317,318 < screen1_output_type = 2 < screen1_output_mode = 14 --- > screen1_output_type = 3 > screen1_output_mode = 5 327c327 < hdmi_used = 0 --- > hdmi_used = 1 331c331 < tv_used = 1 --- > tv_used = 0 419c419 < tvout_used = 1 --- > tvout_used = 0
  5. I should add that this is the H3 version of the board.
  6. I am trying to get composite video fully working on an Orange Pi Zero Plus 2. I installed the legacy kernel image, and I've been able to turn on composite out, but I just get a blank screen on boot and there is no /dev/fb0. Is there anything else I have to do to enable the framebuffer. This is the (I believe) relevant portions of the script.fex file: [boot_disp] advert_disp = 0 auto_hpd = 1 output_type = 4 hdmi_channel = 0 hdmi_mode = 4 cvbs_channel = 1 cvbs_mode = 11 output_full = 1 hdmi_mode_check = 1 [disp_init] disp_init = 1 disp_mode = 1 screen0_output_type = 3 screen0_output_mode = 5 screen1_output_type = 2 screen1_output_mode = 14 fb0_framebuffer_num = 2 fb0_format = 10 fb0_pixel_sequence = 0 fb0_scaler_mode_enable = 1 fb1_framebuffer_num = 2 fb1_format = 10 fb1_pixel_sequence = 0 fb1_scaler_mode_enable = 1 [hdmi_para] hdmi_used = 0 hdpc_enable = 0 [tv_para] tv_used = 1 tv_dac_used = 1 tv_dac_src0 = 0 these are some possible relevant lines from boot. [ 0.000000] Kernel command line: root=UUID=ab03f9a3-0ba3-4236-8857-33f3229b7a85 rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 monitor=composite-ntsc panic=10 consoleblank=0 loglevel=1 ubootpart=75ceecdb-01 ubootsource=mmc usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cma=96M cgroup_enable=memory swapaccount=1 [ 0.614087] [DISP]disp_module_init [ 0.614413] cmdline,init_disp= [ 0.614448] cmdline,disp= [ 0.615200] [DISP]disp_module_init finish [ 1.029299] cmdline,disp= [ 1.029629] [DISP] disp_init_tv,line:539:screen 0 do not support TV TYPE! [ 1.029647] [DISP] bsp_disp_tv_register,line:998:'ptv is null [ 1.029710] [DISP] disp_device_attached_and_enable,line:159:attched ok, mgr1<-->device1, type=2, mode=14
  7. I installed the experimental version of the NanoPi Neo Air distribution on my Air a month or two ago. At the time I believe Bluetooth was not working on that version. I don't see any indication that it is not working now, but it doesn't seem to be working on my install. Is Bluetooth working on the experimental kernel? If so, should I just re-install, or is it not hard to get it working on an existing install? I just installed the latest updates and rebooted, and that didn't fix it. The symptom that I'm seeing is that if I run bluetoothctl it prints a prompt, but seems to lock up.
  8. The heatsink is just bolted on, so it's easy to remove, but it doesn't interfere with the pins, so it's possible to solder pins on even with the heatsink installed.
  9. It doesn't look to me like that comes with a power supply, and I don't know why you would want to use that anyway if you just want to power it. Why not use something like this: https://www.amazon.com/Raspberry-Power-Supply-KuGi-Adapter/dp/B01E6YLFAO
  10. Okay, so you have to have the sdcard inserted at boot time for it to be recognized. I have it working now, but can't it be made to auto-mount on insert?
  11. Any recommendations on how to mount the sdcard when booting off the eMMC? Is there a module that I need to load?
  12. I just logged in and, ran nmtui, selected an access point, typed in the password, and it worked. I don't know what dhd or bcmdhd are.
  13. I'm confused. In one post above you describe how to connect via g_ether, then you reply to yourself that it doesn't work. What are you using to configure your wlan? I used nmtui, and it worked perfectly. I just selected a SSID, typed in the password, and it worked. And what do you mean "install my own system"? Do you have your own distribution that works better than Armbian? Remember, this is beta, and the developers of Armbian haven't even gotten their hands on hardware yet. I'm sure it will be working very well shortly. I think it's already working pretty well.
  14. That's odd. I'm able to load g_ether on the Armbian beta image (I believe from the 19th).
  15. Thanks. That is exactly what I remember now from my past experience. The latency is not too bad, but it makes the device feel slow, since it can take a second to respond to commands. It's also bad if you're trying to control anything over WiFi that would be affected by higher latency. Also, copied off the contents of the eMMC before I overwrote it, so I should be able to poke around it if necessary. I should also be able to post it somewhere if others want to look through it. I don't think there should be any issues with distributing it.