Hello there, i am curious about the new GSOC this year, did nt see anything.
Hi,
Well, someone decided to unplug my DSL line yesterday to connect another one apparently… so I’ve been a bit offline and no one replaced me to send the announcements. Currently I’m using my phone as a backup connection.
Anyway, 4 students are accepted:
- Preetpal will continue her work on the Input preferences started last year: tablets and joysticks support, integration of keymap and keymapswitcher, integration of padblocker, and maybe more
- Leorize will rework the HTTP API to make it faster and with less bugs,
- Cruxbox will work on XFS filesystem which is used by several Haiku devs when they run Linux because of its good attributes support, allowing us to more easily exchange files with Linux in that case,
- Suhel will work on UFS2, to allow file exchange with FreeBSD and also as it is required for the SPARC port to boot from disk (similar to how FAT is used for UEFI systems).
10 Likes
Sparc doesn’t require UFS2… it just requires a bootloader that can read whatever FS, for instance SILO can boot straight off ext1/2/3 iso9660 FFS and ROMFS. Not saying booting off UFS2 is bad, just a technicality. Also anyone implementing this should be aware that there are maximum boot FS limitations for where the BootPROM can read from, higher on 64but but as low as 1GB on old 32bit systems (sun4c mostly =1GB, sun4m mostly = 2GB). Anything 64bit I think can read at least 4GB.
Perhaps we should just reuse SILO as first stage bootloader adding BFS support and then chain into the Haiku portion… https://wiki.osdev.org/SILO , I seem to recall you were originally basing your boot code off of one of the BSDs perhaps those could be extended to directly support BFS without UFS at all also.
OpenBoot loads the bootloader from an UFS2 filesystem. So yes, some UFS2 support is required to put it there in our disk images. Of course once you have loaded the bootloader you can do whatever you want and Haiku will run from BFS as usual.
We also don’t plan to support 32bit sparc at all.
Why would we bother with SILO? The bootloader is already running on SPARC, complete with boot menu. I just looked at FreeBSD code for some details of the intrfacing with OpenBoot that are not very clear from the docs alone. Most of the work is in fact based on the code for the PowerPC/OpenFirmware version of Haiku, as OpenBoot and OpenFirmware are largely the same thing.
How does SILO work then… as it does not require UFS AT ALL. I have several sparc machines with no UFS partitions on them anywhere sun4m and sun4u and sun4v. All I’m saying is that the statement that OpenBoot requires UFS is dead wrong… as it doesn’t require it on any Sun system I have ever seen and I have a lot and a wild variety of sun machines at my disposal that is a function of whatever boot sector you are using. And… I’m saying why not having a BFS boot sector.
We also don’t plan to support 32bit sparc at all.
I dislike this… while you may only implement 64bit support please don’t put up roadblocks to implementing 32bit support for no reason. I would be more appropriate if you said “I have no intention of implementing 32bit support” and that’s fine.
1 Like
Indeed, SILO comes with a custom boot block so it doesn’t need UFS: https://web.archive.org/web/20080308233350/http://www.sparc-boot.org/how.html
However it seems easier for me to load the bootloader from an UFS partition instead. No need to write a 1st stage bootloader in assembler to fit in 512 bytes in that case, we can go straight to stage 2.
As for 32bit sparc, you can complain all you want, if no one works on it, it won’t happen. And I certainly don’t plan to work on it. I won’t put roadblocks “for fun” but I wouldn’t care about it particularly. Sparc is 64bit since 1998, and I don’t see a point in adding support for more 32bit architectures to Haiku at this point.
1 Like
Yes that sounds right… and if using the built in UFS support works best, by all means.
Also the advantage of SILO is it also supports ISO_9660… so you wouldn’t need to build funky isos with multiple filesystems like Solaris has. I will also point out that Sparc is an area where there aren’t a whole lot of eyes on the code for things, so the more sharing that can be done with other active projects the better, for Haiku and Linux… in this case as it is obviously a niche architecture no matter which way you slice and dice it.
Also Sparc continues to be backwards compatible with 32bit so you can run 32bit userlands with slightly higher performance in some cases http://temlib.org/pub/SparcStation/Standards/V8plus.pdf This is why much of Solaris software has historically shipped as 32bit, with only 64bit things where large memory support was needed (this is exacerbated by the fact that Sparc/Risc in general is not very memory dense so suffers from memory bandwidth bottle necking so you may as well help it every litle bit you can). And yes that bit is a bit ricey… modern solaris is in fact moving to ship as much as 64bit as possible.
Also 32bit embedded sparc hasn’t gone anywhere and is basically the only place Sparc exists outside of Oracle and perhaps Fujitsu still that is publicly known (used to be used in some set top boxes also). So for a BeIA like device… 32bit would make sense using a Leon Sparc or FPGA based Sparc CPU.
Anyway I do not expect that to fire you up to pursue anything… just my view.
not for arguing, just adding to the discussion - I went through “IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices”, IEEE 1275, aka “OpenFirmware”, it doesn’t require support any specific FS.
but, on the other hand, there is so much left “up to the implementer”, “to augment” so maybe some OF/OB systems make that particular FS a requirement.
I don’t think embedded devices are a target for Haiku. And for a BeIA thing today, what would be the reference? Probably Android smartphones and tablets. These all run 64bit too, now. Who wants to be limited to 4GB of RAM? (remember that if we go 32bit on SPARC, there isn’t a trick like PAE on x86 to still use more physical memory).
Yes, that’s what the standard says. We’ll see when we get there anyway, and the UFS2 support will still be (mainly) useful for people running Haiku and *BSD or Solaris on the same machine. The bootloader thing is only an extra.
SuperSparc actually had 36bit physical addressing in the CPUs.
More then 4GB of ram in the system is possible trivially on Sparc v8… CS6400 16GB of ram as a historical example, the next largest machine though I think was the SS2000 with 5GB of ram… its literally just extending the physical addressing while logically you are still limited to 4GB of course. Lets not argue about thus further thanks. As I already stated the point was not to argue but just to show that I have a differing viewpoint don’t think of this as something that needs to be argued about.