Yes, that should work too. If you are working on parts of haiku itself, the shortest way is to run “jam -q haiku.hpkg” from haiku buildsystem, and then you can install the generated package with pkgman. If things break, you can just boot an older state from the boot menu to get your working OS back.
1 Like
I was able to extract-modify-create the fpc source package with my modifications. Installing works, files are in correct place. Searching in pascal sourcecode indeed shows me the modified files. Still, can’t compile with them, I guess (?) because fpc binary has to be recompiled from the modified sources, and repackaged, and installed also.
Now I run into trouble: I am unable to compile the new fpc. I can try from a terminal, but I get a message the fpc3.0.4 ‘starting compiler’ is needed to create 3.2.0. While a 3.0.4 x86 binary version exists, I cannot find or create a x64 version unfortunately.
Update:
Compiling fpc 3.3.1 is possible when you have fpc 3.2.0 installed, they have apparantly updated that ‘bootstrap’ compiler thing: and since version 3.2.0 is available this will work: that is, you need to probably patch for the IsManagedType() compile error, at least I had to. (just fallback to the old behaviour: return True always).
Looks like compiling succeeded but it won’t run…
So: still kind of stuck. Oh, I just grabbed the sources directly (trunk) with subversion so I’m more in control.
I also grabbed the Lazarus IDE sources that way (trunk), and with fpc 3.2.0 it is no problem to build it. I just saw Lazarus 2.1.0 running on Haiku x64 with my project: of course I am still stuck on the termios thing because I cannot create FPC still…
Another update: all in all it turns out compiling succeeded indeed. I could even create packages, install them, and use the 3.3.1 compiler to compile Lazarus 2.1.0. Now I’m stuck because I have no clue how to create correct /etc/settings stuff for FPC, and apparantly the structure of the FPC build is not correct or completely different from how the 3.2.0 looks like. So, I just quit on this, to try another, hopefully simpler approach:
- extract existing 3.2.0 source package, patch it, tell it it should use the 3.2.0 as bootstrap compiler, and compile itself again. While I am typing I see this succeeds. So I’ll be trying a bit more on this road instead…
For completeness sake I created a bugreport at FPC with the termios fix as I was able to test succesfully in the meantime with updated compiler and compiler source:
https://bugs.freepascal.org/view.php?id=36958
Please note that serial port ‘purge’ ( at least on USB adapters) fails always: doesn’t matter if I call the old beos specific method, or the newer FPIOCtl method, same result: I expect that Haiku simply misses support for this feature inside the kernel drivers. For my projects I disable calling this function inside SynaSer now so I can work decently with serial connections outside of that one function.
If someone feels something should be different about that patch I created, feel free to comment and such 
1 Like
I can have a look at the serial port drivers, but I’m not sure which function you refer to exactly. “flush” would be waiting for all bytes to be sent, which seems not possible in BSerialPort, while “purge” would be dropping all pending data and never sending it (ClearInput/ClearOutput).
And of course I don’t know much about FPIOCtl.
Please look at both if you can. So in SynaSer you have a ‘Purge’ function, which calls ‘Flush’ below. Nice name mixup… anyway, this is the same in Linux and I’d expect it to work there 
If I call the Synaser Purge function, it normally directly does:
SerialCheck(fpioctl(FHandle, TCFLSH, Pointer(PtrInt(TCIOFLUSH))));
I can route it though termios by changing that line in:
SerialCheck(TCFlush(FHandle, TCIOFLUSH));
If the implementation is the old one we had in termios, or if it’s the new one (which is same as first mentioned call in SynaSer), in all cases SerialCheck (asks for result status) will report failure on Haiku.
On Linux it succeeds though.
Thanks in advance for looking!
BTW: SerialCheck:
function TBlockSerial.SerialCheck(SerialResult: integer): integer;
begin
if SerialResult = integer(INVALID_HANDLE_VALUE) then
{$IFDEF MSWINDOWS}
result := GetLastError
{$ELSE}
{$IFNDEF FPC}
result := GetLastError
{$ELSE}
result := fpGetErrno
{$ENDIF}
{$ENDIF}
else
result := sOK;
FLastError := result;
FLastErrorDesc := GetErrorDesc(FLastError);
end;
AND: (BaseUnix)
function fpgeterrno:longint; external name ‘FPC_SYS_GETERRNO’;
I was able to create FPC3.1.1 source and executable packages for packagemanager, and also Lazarus 2.1.0 as executable package. I installed them and my program works OK with that. I have included the updated termios in the FPC packages.
I have to say without copying the file structures s40in has inside his packages I would not have been able to pull this off. He’s very knowlegdeable in my eyes Thanks!
I only did the 64bit versions, and I’ll leave it at that for now.
I also updated FPC 3.2.0 source and executable packages that work with the already existing Lazarus 2.0.2 package, also with updated termios.
Update:
Just uploaded it all in two zip files:
http://www.rudolfs-place.nl/Haiku/Downloads/FPC_320_Lazarus_202-x86_64.zip
and
http://www.rudolfs-place.nl/Haiku/Downloads/FPC_331_Lazarus_210-x86_64.zip
Both these files contain the mentioned versions of:
- FPC sources + termios,
- FPC binaries + termios,
- Lazarus binaries,
- LibQt5Pas pascal bindings,
- multiplatform version of SynaSer.
Update: please note that in Synaser the commented out ‘Purge’ command contains a mistake which of course is not active as it’s commented out. Anway, when the tty driver in Haiku is updated you can enable the purge command again, but the line should read:
SerialCheck(TCFlush(FHandle, TCIOFLUSH));
In my app it’s working OK that way
For the tty driver update status see: https://review.haiku-os.org/c/haiku/+/2516
Hopefully I did it right (enough) so it indeed works on everyone’s recent 64-bit Haiku installations…
5 Likes
Thankyou very much Rudolf 
1 Like
Is there a way (or some guidance) to check if these build for 32bit also?
Patch for implementing TCFLSH: https://review.haiku-os.org/c/haiku/+/2516
I don’t know if this is working, or if it is complete (see the commit message for my questions).
Nice, Thanks!
So, Synaser has online documentation here:
http://synapse.ararat.cz/doc/help/synaser.TBlockSerial.html
For it’s Purge command we are talking about the doc says:
‘Unconditionally empty all buffers. It is good when you need to interrupt communication and for cleanups.’
So I’d say this goes for RX and TX buffers. TX should be interrupted and re-initialized therefore I would expect. The next time the serial port user sends data it should be transmitted normally: the port’s settings should be unchanged (baud and such).
Ah: you can specify which buffers are affected I see (https://linux.die.net/man/3/termios):
tcflush () discards data written to the object referred to by fd but not transmitted, or data received but not read, depending on the value of queue_selector :
TCIFLUSH
flushes data received but not read.
TCOFLUSH
flushes data written but not transmitted.
TCIOFLUSH (this is used by synaser, I see btw I introduced a (commented out) fault there :-/ )
flushes both data received but not read, and data written but not transmitted.
====
Please note that the Synaser.Flush command is non-intrusive: it says:
‘Waits until all data to is sent and buffers are emptied. Warning: On Windows systems is this method returns when all buffers are flushed to the serial port controller, before the last byte is sent!’
The difference between SynaSer’s Flush and Purge commands is clear I’d say.
To give you more pointers on the driver’s exact implementation expectations by Synaser:
On our Haiku Synaser will call termiosproc.inc routine ‘Function TCDrain(fd:cint):cint;’, which calls:
fpIoCtl(fd,TCSBRK, @arg);
Sounds a bit strange though that we’d call it break.
(see: https://linux.die.net/man/4/tty_ioctl for pointers on this i.e.)
I copied this from our termios.c file: but that’s wrong here I see now I would say… But then again: In linux it’s also done this way (within lazarus/fpc at least: just switch target OS and search )
The manpage says:
’ waits until all output written to the object referred to by fd has been transmitted. ’
Last update (5th? hmm, I should probably read more before I respond… sorry…)
Anyhow, it’s clear to me now that the ‘1’ argument for the break routine actually means that it’s a ‘custom’ implementation that’s called. if it were ‘0’ then indeed it would be used to start, or stop, a break command.
So our custom implementation is executing a flush (non-intrusive). On the manpages I saw:
’ Sending a break
TCSBRK
int arg
Equivalent to tcsendbreak(fd, arg) .
If the terminal is using asynchronous serial data transmission, and arg is zero, then send a break (a stream of zero bits) for between 0.25 and 0.5 seconds. If the terminal is not using asynchronous serial data transmission, then either a break is sent, or the function returns without doing anything. When arg is nonzero, nobody knows what will happen.
(SVr4, UnixWare, Solaris, Linux treat tcsendbreak(fd,arg) with nonzero arg like tcdrain(fd) . SunOS treats arg as a multiplier, and sends a stream of bits arg times as long as done for zero arg . DG/UX and AIX treat arg (when nonzero) as a time interval measured in milliseconds. HP-UX ignores arg .)’
So with Haiku the meaning of ‘nobody knows what will happen’ is translated to ‘wait untill the TX buffer is sent-out into the world and then return’).
Hopefully that is indeed what happens then
I guess that if you have it in place (as a patch or otherwise) I should clone into Haiku, do the patch, compile the driver and place it in the ‘non-packaged’ folder for kerneldrivers?
I guess I could do some tests with it (maybe even connect a oscilloscope to track the hardware behaviour…)
I started out to write a readme, but in the end I didn’t really complete it since I determined that I find it too complex: the best way for me turned out to just analyze s40in’s packages and copy it’s structure.
The source package is not so complex, but the structure copying I did were for the Lazarus and FPC build versions.
Tricky things are:
- the lazarus executables lazarus, buildlazarus and startlazarus (I think I remember): I manually set their signature’s to what s40 in has done. Also I manually added the icons to them.
- you need to create several shortcuts i.e. for app-menu entries in Haiku’s menus, to link to where the binaries are installed by you in the read-only ‘target’ filespace. Only, at the moment you are building this all, you probably do it in a subfolder structure in your home folder. So make sure you always create relative shortcuts, not absolute ones. (holding the shift key when making a shortcut makes them go created in relative mode).
I’ll look once again at the readme’s and post links to them attached to this message (I’ll edit it again ).
Hopefully that will give you enough pointers. And yes, I would expect it to work without trouble. Though I am no expect in gcc mangling (but then again I read somewhere that for this specific item we don’t suffer from that stuff as we do Pascal )
Update: the readme files:
FPC3.3.1 and Lazarus 2.1.0
1 Like
I’d like to see 32bit as my haiku box is atom based and only does 32bit. I did a lot of Delphi prior to 2007 and would like to play about with it again. As I’m trying to do more with Haiku, it would be great to be able to use it.
Actually I don’t really know how the Haiku users are divided between 32bit and 64bit builds. I was a big fan of 32bit myself, as all my driver works was done that way (coming from the BeOS). But since in the meantime all systems/OSses we work with at my job are going 64bit (and I would prevent some 32bit complexity in Haiku concerning gcc versions and such) I decided to test this time with 64 bit.
Let’s put it this way: if Begasus can manage to create 32bit packages that would be cool. If not, I guess I can give it a try. I do need to format my Haiku partition for that though and start ‘from scratch’ with it…
You do realize there’s no debugger yet I hope. I didn’t look into it, nor did s40in AFAICT…
You can download the patch I linked from review.haiku-os.org. It is actually in the tty module, not in the serial port driver where I initially expected this would be done. For now it only clears the software buffers, not the hardware ones, as I think would be needed for a correct implementation of this. For testing, it may be simpler to build a new haiku.hpkg (jam -q haiku.hpkg) and installing that (using pkgman install). building just the module and setting it up in non-packaged is also possible, but I find it less convenient. And it’s quite likely that the serial drivers would also need to be adjusted.
I think sending a break is an indirect way to do a write that sends no data. So it blocks until all buffers have been emptied, and then sends something that isn’t a valid data byte and won’t be received as such. But that’s only a guess, I could be missing something.
Thanks for the pointers, I’ll try that. So sending a break is not what’s done. The call argument is not zero, but one: indicating that the driver should just wait for sending to complete. In my experience you can simply read the fifo and wait until it reports empty to get the behaviour as it is on windows (so last byte in transmission is still going on (just started) when fifo reports empty.
Call argument zero starts or end a break signal level. I can imagine this too would wait for the fifo to be empty, and preferably also until the shift register is empty before setting that line level, but just executing it that way is a mistake when argument given is ‘1’. (Unless maybe if you execute it as ‘end break condition’)
Anyhow, I’ll report back what happens with the patch the way you suggested. Thanks again!
Update: looking at the tty.cpp source file it’s indeed done via the ‘end break condition’ AFAICT. Looking good.
So far I see more users (developers or even students for GCI/GSoC) switching to 64 bit leaving 32 bit a bit on the side line, still many users are using it (I use both in virtual install on a W7 laptop which works fine for me, not the fastest, but I can check both systems there), that being said, I will try to see when I get around to it to check on the 32 bit progress, if need be I’ll call for help here
We need 32bit support in 64bit system like Windows
1 Like
It’s in the works, but not yet, maybe in time, but that doesn’t change the fact that you can’t run a 64bit OS on a 32bit system, gcc2h for me is the best to check things out for both compilers …
Pulkomandy,
Can you check if my git access to the haiku sources have been revoked or not? I’m trying to clone using my private/public keys (gerrit still has the correct public key I just checked), but doesn’t work. Could be I have the setup wrong here, or access has been revoked. I did get a message from kallisti back in march to which I responded, but he never seems to get my mails, or at least, I see no responses. Thanks!
Access through ssh is never revoked (it is also used for non-committers to submit their changes).
Your account is also still in the contributor list, allowing you to vote +2 or -2 on changes, as well as push to master (you can check here: https://review.haiku-os.org/admin/groups/3,members)
So I’d say it is a problem on your side.
Things to check:
- ssh public key is in https://review.haiku-os.org/settings/#SSHKeys
- matching ssh private key is in your ~/.ssh/id_rsa on Linux or ~/config/ssh/id_rsa on Haiku
- your git clone is set up with the correct remote url: ssh://username@git.haiku-os.org/haiku , the username must match the one listed in https://review.haiku-os.org/settings/#Profile
To check the setup you can ssh to the server:
~/opensource/haiku$ ssh -l pulkomandy git.haiku-os.org
**** Welcome to Gerrit Code Review ****
Hi Adrien Destugues, you have successfully connected over SSH.
Unfortunately, interactive shells are disabled.
To clone a hosted Git repository, use:
git clone ssh://pulkomandy@git.haiku-os.org:22/REPOSITORY_NAME.git
(then control+C to exit)
1 Like