Closed knghtbrd closed 6 years ago
I don't have an update on the baudrate bug and an effective workaround for it, but the way to detect a Pi 3's serial port is shown in raspi-config around line 740:
if [ -e /proc/device-tree/aliases/serial0 ]; then
sed -i /boot/cmdline.txt -e "s/root=/console=serial0,115200 root=/"
else
sed -i /boot/cmdline.txt -e "s/root=/console=ttyAMA0,115200 root=/"
fi
I'm still waiting for my replacement pi3, so I don't know if /dev/serial0 exists on that machine. I know /dev/ttyS0 does. Still, this is the officially supported way to detect whether or not the GPIO serial port is ttyAMA0 or not on the Pi. I think I can deal with that.
As long as we're prepared to handle either one being in cmdline.txt, we'll be okay for the time being. But we'll want to have support for assigning the Pi's GPIO serial for A2Pi when we do that.
Additional information about the problem and potential solutions is here:
http://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3
Choices seem to be:
Maybe David has some thoughts?
Tagging @RasppleII/apple-ii-pi
I would suggest that the Pi3 only be supported with an external USB->serial port dongle on the Pi3 and a SSC on the Apple II. This is a fully compatible setup. Two reasons this makes sense: The GPIO UART on the Pi3 obviously has some issues. They might be worked out with additional system settings, but the other issue involves power draw from the A2Pi card. The Pi3 far exceeds what should be plugged into an Apple II slot. The Pi2 is probably on the edge, but I haven’t had any issues with my bench machine.
On Oct 29, 2016, at 2:30 AM, Joseph Carter notifications@github.com wrote:
Additional information about the problem and potential solutions is here:
http://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3 http://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3 Choices seem to be:
Use the reduced-capability UART for A2Pi See above why this probably isn’t a solution. Disable bluetooth on the Pi 3 I don’t see what this solves. Reduce bluetooth's capabilities using the mini-UART Still don’t see what this solves. Maybe David has some thoughts?
Again, I have a //c and //e connected to Pi3’s over USB->dongles. This should be the supported configuration. Tagging @RasppleII/apple-ii-pi https://github.com/orgs/RasppleII/teams/apple-ii-pi — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RasppleII/a2cloud/issues/26#issuecomment-257081503, or mute the thread https://github.com/notifications/unsubscribe-auth/AELjJtwr27UAdxS0OCG1WT8AviFHRHEZks5q4xJCgaJpZM4H-Z7_.
What disabling Bluetooth on the Pi 3 does is let you use the full-function UART for the GPIO serial port. I'd agree though that the Pi 3 with A2Pi Card is really reaching the point of diminishing returns.
We removed A2Pi from A2CLOUD for the jessie release for several reasons:
This will create some conflict between your A2Pi repository and A2CLOUD because we're going to be installing our GSport (which I was working on this morning actually), but I'm actually thinking the emulators should also be spun out into a top tier project at some point because they just don't seem to belong as part of A2CLOUD either. That's going to have to wait because pace is slow enough as it is.
I do intend to properly package it--we have a reprepro archive on blocksfree that I just need to automate an incoming directory for. I plan to work with your package scripts as a base for that. I should remember to ask though, did you have any patches to the SF codebase we should try and preserve? We'll be applying one to rename config.txt to something more useful, but otherwise I don't have any plans to patch the existing GSport beyond what's needed to compile it.
The sort of stuff I'd want to do I believe Dagen's already working on anyway.
On Oct 29, 2016, at 2:45 PM, Joseph Carter notifications@github.com wrote:
What disabling Bluetooth on the Pi 3 does is let you use the full-function UART for the GPIO serial port. I'd agree though that the Pi 3 with A2Pi Card is really reaching the point of diminishing returns.
We removed A2Pi from A2CLOUD for the jessie release for several reasons:
At least parts of the setup we had for it weren't jessie-compatible Our setup was hard-wired to use GPIO serial, which didn't work on the Pi 3 at the time. We did not want to delay a release for jessie to solve these problems. A2Pi deserves to be its own top-tier project parallel to A2CLOUD, not shoehorned in to part of it. This will create some conflict between your A2Pi repository and A2CLOUD because we're going to be installing our GSport (which I was working on this morning actually), but I'm actually thinking the emulators should also be spun out into a top tier project at some point because they just don't seem to belong as part of A2CLOUD either. That's going to have to wait because pace is slow enough as it is.
I do intend to properly package it--we have a reprepro archive on blocksfree that I just need to automate an incoming directory for. I plan to work with your package scripts as a base for that. I should remember to ask though, did you have any patches to the SF codebase we should try and preserve? We'll be applying one to rename config.txt to something more useful, but otherwise I don't have any plans to patch the existing GSport beyond what's needed to compile it.
The sort of stuff I'd want to do I believe Dagen's already working on anyway.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RasppleII/a2cloud/issues/26#issuecomment-257117821, or mute the thread https://github.com/notifications/unsubscribe-auth/AELjJuUpVEtMZGQxwCybrGHYnt9PO1_Bks5q475hgaJpZM4H-Z7_.
All my patches were fed back into the GSport repository. As long as Dagen started from a fairly recent branch, his SDL work should supersede my hacked script to run full screen vs windowed. I definitely think keeping the projects top tier is a good idea. You can always create an umbrella .deb that brings in all the components.
@dschmenk resolved any issues with a2pi on newer boards ages ago, and we no longer install it as part of a2cloud. I think it's safe to suggest this issue is effectively resolved. I wouldn't mind giving folks access to the a2pi stuff on Raspple II systems in the future but as part of a2cloud it was always feeping creaturism. It isn't a little component in a2cloud, it's a first class project of its own.
There are a couple of problems using Apple II Pi with the Raspberry Pi model 3B.
I think A2Pi is important for Raspple II and it needs to work well. The use of the A2Pi card is perhaps less critical at this stage because you can't get them presently and they work just fine with the boards that were on sale at the time you could. But I think we should get @dschmenk involved with the discussion of what maybe we can do about it. :)