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
Haiku already has operational WIP 32 bit process support for 64 bit system: https://review.haiku-os.org/c/haiku/+/427.
Test image: https://keybase.pub/korli/haiku.image.xz.
2 Likes
Thank you for checking! yes, you’re right: apparantly I need to explicitly add my username, and also it turns out I had to prevent ‘others’ from seeing my private key…
Yes. I’m in. Super.
1 Like
Thanks for the link, something we could check out
Update: can’t seem to mount the image in VirtualBox, need to write it to a usb-stick?
You need to convert image to format that is recognized by VirtualBox. It can be done with VBoxManage convertdd haiku.image haiku.vdi --format VDI. VBoxManage is located in VirtualBox installation folder.
In the meantime checking out haiku and tools succeeded. I could build the entire thing. So to keep a reference I just installed the haiku.hpkg, but that could only be done if I first uninstall ilmbase -2.2.1-2 (no clue what that is yet). Also I had to uninstall haiku-devel.
That last part then blocks previously compiled lazarus software to run, but also newly compiled does not run.
Since I built the whole thing, I installed haiku-devel 54095 (Same revision since compiled together ).
After that I still could not run the previously compiled Lazarus target program executable.
Recompiling it once more solved the problem: my software runs again, and I just confirmed it suffers from the same problem. Good.
Next up, the patch…
ilmbase package was a dependency of haiku.hpkg which was removed a week ago. BTW, you can build both packages in one go with jam -j2q haiku.hpkg haiku_devel.hpkg.
Ah thanks, that clears that up
BTW: The icons are misplaced on the bootscreen since I did this update: the activated ones are drawn above the inactive ones, instead of replacing them. Strange side-effect
Anyhow: we have a green light: the patch makes my app work without having to disable the SynaSer purge command. I still need to doublecheck to see if it’s normal that a protocol change takes this much time to succeed (could be the command does not really work yet, though it nolonger reports an error). I’ll compare behaviour on a Pi2 with Raspbian, where the app also runs nicely…
Anyhow, the current behaviour is already a nice improvement!
Update: the protocol change being slow is my own fault: I should switch with a small random timer in there to break-out of sync-distorted loops between client and server that might occur if the timing is very good. And it is, on Linux and Haiku compared to windows: that’s why I see it being slower than usual
This is most likely because you have two haiku_loader packages (this is where splash screen lives) and both of them are active. One was built with branding and includes Haiku logo and another was built without branding enabled. You can fix this but running ./configure --distro-compatibility official
See more here Configure Options | Haiku Project
Yep,
ARM Linux behaves same protocol switching wise. So I think the haiku tty update is enough for the app.
I’d say +2
BTW In SynaSer the commented out line for the ‘Purge’ command on haiku can be re-enabled again after the tty driver is patched. The line in the download I posted is not correct, it should read:
SerialCheck(TCFlush(FHandle, TCIOFLUSH));
Thanks!
Ah thank you, I’ll try that.
It’s not exactly that.
What happens is, depending on the distro compatibility, the Haiku logo is or is not shown. The icons are shifted up or down accordingly.
However, the grey icons are set up by the bootloader (which is in haiku_loader) while the colored ones are shown by kernel as it boots up. Both independently store the icon offset, so if you mix versions (haiku_loader with logo, haiku without, or the opposite) you get this effect.
There are no other side-effects to this. You can fix as suggested by Diver by adding the logo to your own-built haiku.hpkg, or do the opposite, update haiku_loader with one you built yourself that doesn’t include the logo.
1 Like