We're on Discord! Please join our server now if you don't want to miss anything! (More info) | Join the UCC4 contest! (More info)

* WalrusIRC (More rooms available on our Discord server)

Author Topic: Hardest platforms to program/work for ?  (Read 1667 times)

0 Members and 1 Guest are viewing this topic.

Offline Jean-Baptiste Boric

  • Full User
  • Join Date: Jan 2016
  • Location:
  • Posts: 39
  • Post Rating Ratio: +2/-0
Re: Hardest platforms to program/work for ?
« on: December 06, 2018, 07:56:49 pm »
Ah, interesting. I've heard a lot of talk about the GS processor on the PS2 but not a hell lot about the CPU. I guess most people assumed it was just a boring old MIPS cpu. I mean in theory it should be possible to tell GCC to target some of the CPU's features right ? (or even create a new target but i think you guys went with the safe route C:)
The toolchain situation for the Emotion Engine is a tad complicated. Back in the day, Sony released the sources of a patched GCC version alongside their Linux port, but it did not end up being merged upstream for reasons I do not know. You can treat it as a MIPS-III from the userland's point of view and get away with it (which NetBSD users did for a while), but that won't work for the kernel. Someone did add basic support for the EE to GCC without the proprietary insane bits shortly before I started to work on the resurrection, which was enough for me to reach the point where the kernel panicked because it did not found a root disk to mount, with almost no hexadecimal-coded instructions in the assembly source files.

Anyway, all of this is moot now as any interest in this port resurrection promptly died when Imagination Technologies announced the CI20. Which really was for the best, because the PlayStation 2's architecture is a bad fit for general-purpose computing and the MIPS world really needed an official Raspberry Pi-like equivalent.

Hopefully the G2 will not be such a pain in the ass to work with
Isn't  the G2 going to be more locked down though ? It's a shame that neither the Linux or NetBSD ports went anywhere.But touchscreen isn't that important on a calculator one could argue.
It gained the ability to enforce a lockdown with a signed bootcode at the SoC level and the official HP firmware appears to enforce an effective chain of trust. However, from what scant tips I've gathered, the bootcode should be unlocked and we should be able to run homebrew firmwares (patching the original firmware will be far harder and we should definitively not risk invoking the wrath of HP). I intend to explore the G2 once mine gets delivered during this Christmas.

The touchscreen itself is not needed for a Linux port, but there's only one USB port available. Having the ability to have a mouse/touchscreen without requiring an USB mouse (and possibly an USB hub to plug in more things) has its upsides.

That reminds me, some time ago I've managed to come up with a theoretical way to effectively lock-down the NumWorks calculator with a simple software update, at the cost of fusing off the debugging interface. The "nice" thing about it is that I also found a theoretical way to allow unofficial firmwares to still run unhindered yet still prevent them from compromising the root of trust and from operating the LEDs. So if it ever comes to that, there will be a glimmer of hope besides desoldering the SoC and soldering an unlocked one.

I saw some articles about Fushia but it's as early stages as Haiku OS it seems. At least they got rid of Java it seems.I don't really care for the microkernel design but as long as it is POSIX compliant and performs decently, it's all good.But then again, it might end up like Tizen and stay on smartwatches and all. (which kind of died because the license was not truly open source among other things)
Fuchsia is not POSIX compliant (but does offer a limited level of POSIX compatibility) and frankly I think the POSIX API has accumulated a lot of rust over the decades when directly used as the native kernel ABI of an operating system. However, crostini's approach to bring Linux containers to Chrome OS (which I am impatiently waiting for it to leave the dev channel for my Acer R13) decouples the host kernel from the Linux kernel running containers inside a VM, so Chrome OS switching from Linux to Fuchsia in the future would be completely transparent to the end-user (as long as they migrate Android support to crostini too).

On the other hand, I am not sure what will be the consequences of switching Android from Linux to Fuchsia will be in practice, beyond that upgrades at the lowest layers of the OS stack should be much easier to perform. I am however tepidly sure that Fuchsia won't disappear overnight (if anything, it should make for a wicked embedded OS).
« Last Edit: December 06, 2018, 07:59:29 pm by Jean-Baptiste Boric »


You can also use the following HTML or bulletin board code to share it on your page or forum signature!

Also do not forget to check our affiliates below.
Planet Casio TI-Planet Calc.news BroniesQC BosaikNet Velocity Games