• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by fraveydank

  1. My bread and butter day job includes embedded Linux engineering; I may be needing to navigate these avenues soon enough. In any case, I do get full console video from uboot, but it drops to no signal after kicking off the kernel. I haven't investigated much, but the device tree shows the HDMI disabled (and dmesg indicates that its power domain is powered off). I'll see what I can dig up relative to the Pine64 build.
  2. Verified; it's not even the same connector. The PINEA64 connector seems to be pretty closely related to the 7" LCD they have a module for (it's not exact, but presumably there's an adaptor board in the middle), while the Xunlong one doesn't seem to have anything easily available (though if anyone knows of one, I'd be interested). Easy enough to adapt, though.
  3. Well, yes, that is assumed. Right now, I don't think either the HDMI or MIPI displays are supported on the true mainline kernel without patches (the matrix says the A64's HDMI is a WIP, while the LCD is a "no". I'm not under any impression that it'll happen overnight. :-) In general, Xunlong's pinouts aren't the same as anyone's, at least if the CSI headers are any indication. I should probably check before I put the work/$$ into it, though. Define "mostly useless"... I'm looking to write an EGL application that runs on the framebuffers, which doesn't require any of the massive overhead that Android involves. "Open" is a bit of a misnomer, indeed, but we have Mali support on non-mainline 32-bit builds using the binary blobs. I haven't done the research necessary for the 64-bit ones. Indeed, I'd have to write it. That's not a huge problem, I'm quite used to kernel code, though I haven't written a new Linux module since the 2.4 days... lots of catching up to do.
  4. fraveydank


  5. The other interesting thing that the A64 has is a smartcard reader. There doesn't seem to be an existing driver for this, but the device is quite simple and it looks like the pins are properly exposed on the GPIO port and just need to be remapped. One potential application area I'm looking into is payment terminals, so the smartcard reader would be quite handy there. Add in an SPI-based NFC frontend and you could have quite the neat system...
  6. Just FWIW, I recently got one of these (well, the Win Plus, which mainly just has more RAM) for a project I have in mind. The main reason I chose it over an H5 model (which is better supported, AFAICT) is that it has both HDMI and MIPI-DSI outputs; my application wants both a larger HDMI display and a small touch panel. This, presumably, is one of the primary differences between the A line (meant for application processors, incl. smartphones and tablets) and the H line (meant for set top boxes, which generally don't have built in displays). Alas, I don't think there are any compatibly pinned LCD panels out there, so I'll have to work up an adaptor board some time and get a MIPI panel. The other nice thing about the A64 vs. the A31s (which I have in the frankly underwhelming-for-the-price Banana Pi M2) is that it has a Mali GPU, which at least has a chance in hell of being supported in an open distribution. The A64 seems to be the red-headed stepchild of 64-bit devices in Armbian land, but the datasheet indicates that we should be able to make both work simultaneously (the HDMI output uses a separate TCON unit, and the DE documentation indicates that dual-output functionality is intended). Sadly, the current version of Armbian doesn't seem to run the framebuffer on mine, though it does get video briefly in uboot. I'm going on holiday for two weeks starting next week, but I'm hoping to get a little hacking done on it when I get back. I already built a device tree entry for the Mali device which conforms to the newer driver requirements for the H3 on my OPi One, though I haven't finished tweaking the driver to build with 4.11 sources (lots of VM stuff has changed), but I'm hoping to see if we can get some Mali support on a mainline kernel soon because the interaction with HDMI displays is so much nicer on mainline builds.
  7. In any case, if you want a patch, I'll be happy to supply it, since I have no idea how long it'll be until it's mainlined. It's only of interest if you're using multiple interfaces, though, which is low-likelihood for your particular use case.
  8. Well, in good news, after a few days of thinking on it (because I haven't had time to actually work on it), it ended up being just a two line addition. When finding the correct socket to deliver to, if the destination address is broadcast net and node, the Linux implementation just delivers to the first socket it finds open with the correct port. This is, obviously, problematic for routers, since they have a bunch of sockets open (one for each interface) on specific ports. Thus I was getting all sorts of weird AppleTalk errors because the initial probes were only getting responded to half the time (when they weren't broadcast messages). A little bit of extra checking to make sure that the socket net is within the range of the receiving interface's network range takes care of the problem and now my multi-zone, routed network is happy again. :-) The Linux AppleTalk layer really is messy, inefficient garbage, though. Fortunately, barely anyone is likely to be using it for more than a few Mbps at a time these days (I'd be really surprised if anyone is managing whole campus AppleTalk backbones now), so that's unlikely to be a roadblock to anyone. But I'll still submit my pull request upstream, see what happens.
  9. Interestingly, it looks like the AppleTalk routing issue is actually an issue in the kernel AppleTalk layer; at some point, it stopped finding the correct socket for broadcast packets received and just went with the first socket with a matching port (ignoring the receive interface's address ranges). Working on fixing that now... no idea how long that's been in the kernel, though I suspect it's been quite a while. Even if it doesn't involve a new patch, I'll probably still suggest a 2.2.6 release because the latest post-2.2.5 patches are critical to anyone using real AppleTalk. One of these days, I want to make a userland daemon that just runs on BPF for platforms which no longer support AppleTalk natively, especially if it can be made to share metadata with netatalk 3.x. Alas, I'm short on round tuits...
  10. No, I don't think he does; I'm mostly planning on submitting it as an SF pull request, which should be easiest to integrate. Given the other patches (which address serious issues with running an AppleTalk server, which is the only reason one would use 2.x anymore) are from 2014, I have to imagine a 2.2.6 release would be useful just as an intended-final release of 2.x. Now that I think about it, I may have conversed with you on the netatalk-devel lists before; I never put the names together. :-)
  11. I don't know of any extant, no. It woudn't be the hardest thing in the world, though doing the DPLL for the serial decoding isn't the most pleasant thing in the world. The PSoC is probably easier to get started on and has easier tools, but the CPLD/FPGA is the "right" way. It's also worth noting that most small micros are way more than powerful enough to do AppleTalk routing at a scale that could handle reasonably large networks. You might find the ESP32 with something tied on to do the LocalTalk decoding to be an ideal platform; it's well more powerful than most AppleTalk routers that existed out in the world short of the high end Cisco multiprotocol routers and such (and even then, it's only smaller RAM, still a faster CPU). But you'd have to write the AppleTalk stack from scratch, most likely. It's something I have way back on my queue whenever I plow through the pile of projects currently on my plate.
  12. I'm also active on (more interested in the low-level stuff the cover, and can't keep up with the forum traffic on 68kmla). I'm actually working on fixing some of the routing stuff in netatalk 2.2.5+ (several important patches in git from 2014 that never made it into a release, wonder if they'll ever do a 2.2.6); the routing is broken and it's screwing up my home network, which also encompasses a VAX and an Alpha running VMS (with Pathworks for Mac). FWIW, while I like the idea of small ARM boards as AppleTalk routers/MacIP gateways, I wish there was a better way to get LocalTalk signals through. The rather high-speed serial decoding must be super ugly to do on the Linux GPIO layer, but a small CPLD/FPGA or a PSoC or similar might do the trick connected over SPI. Relying on something like an Asante bridge seems just about as problematic. :-)
  13. Ah, that makes sense, the CHIP's HDMI and VGA output adaptors use the LCD output bus and external ICs to drive their respective interfaces. Isn't the A31 a PowerVR SGX GPU, though? Last I checked there wasn't a great Linux driver for that that was reasonably portable among kernels. I never did dig too far on that, though. I have a Banana Pi M2 that I'd love to get some sort of 3D working on, but oh well... I'll check to see if I can find the experimental branches where, I assume, they have attempts at DRM drivers for HDMI.
  14. Meanwhile, if anyone needs any ACTUAL AppleTalk equipment, I have a few machines to spare... you will make my wife happier. :-)
  15. It's interesting, though the (working) CHIP Mali drivers are running on kernel 4.x. Perhaps I skipped over where it was explained here, but what's blocking it from working here in the nightlies? Just no one's moved those patches over from the CHIP project? If I find some spare time, I'd be glad to help, though that tends to come at a premium these days.
  16. Hey, that's really good work! I actually have some AppleTalk related plans for some Orange Pi related boards, so this is really good timing. I have some experience with low-level AppleTalk work (and I own the dead-tree version of Inside AppleTalk), so if you need further assistance I'll be glad to help as much as I'm able (my free time is limited these days, though). These days, though, AppleTalk kernel modules are becoming a bit long in the tooth; I had to submit some patches to NetBSD to fix their AppleTalk stack a few years ago, and no one had even noticed it was broken. OpenBSD removed it a number of versions ago, and the Solaris module is broken enough that it crashes my Sparc machines. I'm beginning to wonder if it makes sense to build a new userland AppleTalk library that uses BPF or DLPI (on Solaris) like the HECNet router for DECNet does and fork Netatalk 2.x to work with that. It would make things a lot more portable, at least for file servers and any new applications you might want for AppleTalk (which are, um, rather sparse on the ground).