Shop Learn P1 Docs P2 Docs Events
Linux on P2 — Parallax Forums

Linux on P2

Linux is not running directly on the P2. It is "inside" a riscv emulator. I used this one: https://github.com/cnlohr/mini-rv32ima

You'll need a P2-EC32MB.

flexcc -2 rv32demo2.c 
loadp2 -t -b 2000000 rv32demo2.binary -9 . 

It can also load the kernel from SD card, perhaps with some slight modifications.

Boot up time is about 5 minutes. But that is quite good compared to this arm emulator on atmega. https://hackaday.com/2012/03/28/building-the-worst-linux-pc-ever/

I did some simple profiling and found that the PSRAM access uses about 1/6 of the cpu time. That is after adding a simple instruction cache. It seems that any PSRAM operation takes over 600 cycles. This is terrible latency. But fixing it might only improve the emulator by 10% or so. There is still some optimizations that could be done like using SIGNX and other P2 instructions. Even with 50% improvement, we are still looking at a 2 minute boot time. I see 2 paths to do anything practical with Linux on P2.

  1. Perhaps riscvp2 could be adapted to run Linux. It would need 2 modifications. XMM mode. and interrupts.

  2. Try to run Linux native on the P2. The compiler would need an XMM mode for using the PSRAM. The lack of MMU seems to not be a problem. The emulator tested here does not have an MMU and the kernel does not need it.

Comments

  • RaymanRayman Posts: 12,972

    Neat!
    I think @ersmith has a just in time risc V thing, are you using that?

  • Sweet! I was wondering how long before someone put a Penguin on the P2. I just didn't expect it to be ran on top of an emulation layer!

  • pik33pik33 Posts: 1,845

    It seems that any PSRAM operation takes over 600 cycles.

    PSRAM needs to be cached. If this is emulated CPU, the cache subsystem will be simpler to do. Also, the RISC-V emulator is a good starting point, because there is already a linux kernel for it, but a "cached XMM" P2 virtual machine using native P2 instruction set where possible should perform better.

    The main question is now: what for? The simple answer is: to prove it can. A Linux kernel and drivers are a huge bloat of abstraction layers that slow things down. I escape from the operating system even on a Raspberry, using bare metal environment where I can use the hardware and memory in the way I want.

    Another answer can be this "caching PSRAM XMM" that doesn't exist yet. Such an machine with a complier using this mode can extend P2 possibilities

  • RossHRossH Posts: 4,972

    Another answer can be this "caching PSRAM XMM" that doesn't exist yet.

    Yes it does. Catalina already has it, making it realistic to execute real-world programs on the Propeller 2 using PSRAM as XMM.

    And such programs can be loaded and run using Catalyst in seconds - no 5 minute boot time needed.

    And more to come soon :)

    Ross.

  • TubularTubular Posts: 4,496

    Nice work Saucy

  • The reason your PSRAM ends up slow is that Roger's driver is not optimized for low latency small accesses. Especially not if you go through too many layers of high-level wrapper.

    For my console emulators I rolled my own optimized PSRAM code. I don't think I ever cycle counted it, but it's a lot faster than 600 cycles.

  • roglohrogloh Posts: 4,688
    edited 2023-01-11 04:38

    Yeah, what Wuerfel_21 said. My original PSRAM driver is not really intended for top emulator performance, but instead for applications using COG sharing and doing larger transfers (therefore it's more suited for video and general use). For single COG use with small sized accesses you can do better if you talk directly to the device in your own code as this removes the service polling time. But even then some inherent latency still persists and the improvement is bounded. You can probably do a little better with an I-cache added on top.

    In some case the real-world latency may in fact be better with HyperRAM because the 16 bit PSRAM architecture on P2-EDGE is rather problematic for writes and the driver needs to do read-modify-writes in cases where individual bytes or words are written, which gets really slow. However the 8 bit HyperRAM is going to be slower to transfer than 16 bit PSRAM unless you try sysclk/1 operation which gets flaky timing wise over some frequencies. When latency dominates and small transfers are done the reduced HyperRAM bandwidth isn't that significant.

    When I last tested, from memory I think my driver's latency should be more like ~300 cycles of latency. It was in the order of 1us at 300MHz IIRC. If you are encountering 600 clocks it might be due to the need to perform read/modify/writes kicking in. Try writing aligned longs where possible.

  • pik33pik33 Posts: 1,845

    That's why a cache is needed. The "CPU cog" cannot use the PSRAM exclusively, you need a framebuffer, a memory for audio samples, etc. So this multi-cog driver is still needed in such a system.

    In my "Paula style" audio driver I also implemented a very simple cache to avoid single transfers for every sample. Instead, every audio channel has its own 256-byte cache, which is read when missed.

  • hinvhinv Posts: 1,215

    @rogloh said:

    In some case the real-world latency may in fact be better with HyperRAM because the 16 bit PSRAM architecture on P2-EDGE is rather problematic for writes and the driver needs to do read-modify-writes in cases where individual bytes or words are written, which gets really slow. However the 8 bit HyperRAM is going to be slower to transfer than 16 bit PSRAM unless you try sysclk/1 operation which gets flaky timing wise over some frequencies. When latency dominates and small transfers are done the reduced HyperRAM bandwidth isn't that significant.

    Did directly attached HyperRAM, as in not going through connectors, ever get tested for top performance?

  • hinvhinv Posts: 1,215

    Kudos! @SaucySoliton
    I really like linux, and with libraries and better drivers, it could be quite a nice platform to port to.
    Yeah, it comes with some bloat, but it sure is nice to be able to run your favorite open source tools

  • ElectrodudeElectrodude Posts: 1,549
    edited 2023-01-12 04:03

    @hinv said:
    Kudos! @SaucySoliton
    I really like linux, and with libraries and better drivers, it could be quite a nice platform to port to.
    Yeah, it comes with some bloat, but it sure is nice to be able to run your favorite open source tools

    What Linux distro are you using? Better drivers? Bloat? Huh?

    Except for well-known GPU and WiFi driver problems, which can generally be blamed on uncooperative manufacturers, or unless you're using some special piece of overpriced equipment whose developers couldn't afford to write Linux drivers and whose lawyers were too afraid to allow the release enough info for someone else to do so, I find Linux to have better driver support than Windows (I never have to bother with installing drivers - it all just works right out of the box!) and practically no bloat, while on Windows it has to install a driver for every little thing and there's nothing but bloat.

    I use Linux every day both at home and at work and rarely run into true driver problems, of the kind where either nobody wrote a Linux driver for the piece of hardware in question or the only one available is too buggy to use. Linux's driver situation isn't quite the same as it was 10-15 years ago. On the other hand, Windows's driver situation has only gotten worse, with all the draconian driver signing rules in place nowadays.

    It's pretty amazing that @SaucySoliton has gotten Linux running on the P2, but I'm quite certain that no other mainstream OS will ever run on the P2 - they're all orders of magnitude more bloated. I hope with some caching this can be made to be of practical use.

  • roglohrogloh Posts: 4,688
    edited 2023-01-12 05:17

    @hinv said:
    Did directly attached HyperRAM, as in not going through connectors, ever get tested for top performance?

    Unfortunately I don't have a setup with directly attached HyperRAM to test. But @evanh and I did test sysclk/1 performance using the connectors with the Parallax HyperRAM breakout board and test results are available if you want to wade through the long HyperRAM thread. From memory it typically topped out somewhere around 300-320MHz or so depending on the settings to use registered clocks and I/O. But there were some gaps in the frequency range where sampling happened at transitions and data errors occurred. A better setup may be able to more finely tweak clock and data signal separation and not combine HyperRAM and HyperFlash on the same bus but the V1 RAM itself was being significantly overclocked from 133MHz with DDR. V2 HyperRAM promised better performance up to 200MHz but I think it was still typically rated for that speed at 1.8V (maybe one manufacturer did have 3V 200MHz or 166MHz rated operation, can't recall offhand)

  • evanhevanh Posts: 14,038
    edited 2023-01-12 07:07

    There is only one existing Prop2 module containing such RAM suitable for high speed sysclock/1 performance - https://forums.parallax.com/discussion/comment/1544576/#Comment_1544576

Sign In or Register to comment.