• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by TonyMac32

  1. @ning Yeah, I was keeping up with the mailing list, reverted it here: Now it all works, we had a Vim1 issue because it wasn't using the modified card name so PA wasn't immediately enabling it (I chose to use "gx-sound-card") I have not touched vim2 and up, I don't have test boards.
  2. Thank you @jrober19, that's what I would expect from an eMMC in this case.
  3. let's go with iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 We used to do this to benchmark SD cards, however I think we should probably do it to benchmark Kernel/SBC/etc. It will only tell us if something is very wrong or significantly improved, small differences are meaningless because too many variables
  4. on 5.6 yes, I patched 5.6 ;-) However my quick test on 5.7 this was not the case. I will check again of course [Edit] Found the issue, all of the board dts patches got wiped with the bump to 5.7 somehow. putting them back. [edit2] Can anyone run iozone on their meson64 boards and tell me the outcome? I'm working on sound, but my SD performance seems really bad.
  5. I tried reverting a patch in 5.7 that chewitt blamed for some problems but it didn't restore sound. @balbes150 our current Amlogic patch situation is, well, interesting. I need to go through one by one and figure out what each one is for. I neglected my duties for too long.
  6. is the vendor opps for the rk3288-C (Tinker/chromebook version) If it isn't a "C", then it wouldn't have 600 MHz Mali or faster than 1.6 GHz CPU according to Rockchip (I don't know about the "W") @Myy Wow, that patch is garbage, I didn't even notice that. It's worse than you are summarizing: "NPLL is necessary for 500 MHz, ancient krusty kernel suxors and doesn't have this OPP, so in case someone hypothetically someday maybe in theory thinks about possibly re-purposing the NPLL like the ancient kernel did, make mainline suck too for everyone." Yikes. I don't see any reason to not reintroduce that OPP for Armbian use, as far as I know this purely hypothetical situation has not taken place.
  7. @guidol tested on Libre Computer Tritium with a Pimoroni PHAT DAC (PCM5102A), only changes needed: enable i2s@1c22400 (i2s1) change overlay to use i2s1 instead of i2s0.
  8. Thanks @ning, I just wanted to pin a thread so we could get the conversation going, I'll take a look at Khadas and the upstream, hopefully avoiding the patchtastrophy that resulted from multiple patch sources last time.
  9. With our Current moving to 5.7, anyone building it themselves should report anything missing/new/different/wanted here. Le Potato La Frite NanoPi K2 ODROID C2 VIM 1 USB OK OK OK OK OK REBOOT NOK OK OK NOK NOK SOUND OK OK OK OK OK HDMI OK OK OK OK OK Onboard WiFi NA NA OK NA OK
  10. I did. ;-) I can't remember if we have a patch for that or not, my 5.4 image does have fan though.
  11. OK. Boots, gets to desktop, plays the test video, sound via HDMI works, my RTL8821CU wifi was properly recognized. Only thing I see is no fan control, and the LED is just blinking at 1 Hz for no known reason. LibreELEC: same, boots, audio, etc. [edit] it did not recognize the wifi adapter. Now to dig up my Ugoos and stuff this on it.
  12. I certainly can, it will have to be a bit later today, you should see my reply in the morning. Sent from my Pixel using Tapatalk
  13. Yes, I do Sent from my Pixel using Tapatalk
  14. OK, now that I have these in-hand. The SD multiplexer board, for the 2x5 pin header, should that be a pass-through connector? Mine are soldered with a socket facing downward on both boards. Easy fix for me, maybe not for some of the others. ;-) All connectors are Mini-SPOX other than the SD card mini-board. the 1x4 pin header on each is populated, on the SD board it faces "up", on the serial board "down" I would assume one should be a socket. [edit] Well, I was not on the recent page when I wrote this, haha.
  15. I'm not worried about the INA219. I don't want 0.3V drop across that resistor. Unless you out the feedback after that resistor, if the buck converter supports it... Sent from my Pixel using Tapatalk
  16. I think I'll do a redesign, if anyone is interested. This one started out as a specific Tinker-based design, then kind of mutated. I found a 5A buck converter that might be nice. For shunt resistors, something more like 50 milliOhms as opposed to 100 would probably be better. The leads between the shunt and the amplifier need to be equal, and as short as possible. Sent from my Pixel using Tapatalk
  17. @Nielo if you are willing to put in the work, I would guess there are a lot of similarities? It looks like a neat board, but I doubt the community of devs (~10 people) will have time/interest. I think it's neat, but I have no time to maintain something like that.
  18. @guidol how bad do you want something like that, but say, just a bit more powerful? Sent from my Pixel using Tapatalk
  19. I don't see any reason not to, the patchset is a lot of backported stuff anyway. I have a cranky Asus board here that kernel panics on boot with our 4.4 (sounds familiar), I might scab the device tree into something mainline likes and skip legacy for the moment. @Lanefu, we need to make sure the big patch isn't "undoing" any of the other patches, I got most of it cleaned up, but not all. Sent from my Pixel using Tapatalk
  20. Yeah that must be a slip, 0603 is the standard package size. I need to go back and refresh that project to make sure there aren't any better options for parts now, thanks for the heads up. Sent from my Pixel using Tapatalk
  21. :-/ I'll take a look around, and maybe we should ping @Neil Armstrong just to see, they don't have a C2 in their test lab, but perhaps he has an idea.
  22. The thermal zones weren't added until after 5.4. Sent from my Pixel using Tapatalk
  23. My XU4 with the Armbian kernel is fine with Plex and file server duties. Once I put it on the MC1's and started Einstein@home, it was all over. I'll have to give this a shot. Sent from my Pixel using Tapatalk
  24. I got less time, my workload was very high before we were sent to work from home, and then the work didn't slow down, but everyone demanding meetings and phone calls increased. [emoji2357] Trying to avoid a burnout, I'm playing games with microcontrollers and easing back into fixing SBC's. :-) Sent from my Pixel using Tapatalk
  25. I have not changed yet, I will though, I never got the other kernel to work reliably for more than a day during number crunching. Sent from my Pixel using Tapatalk