Linux Port
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Glen Walker (2585) 469 posts |
You could always have a VNC server running on Raspbian and access it that way from within RISC OS, then set up a Samba share to share files. I do that when I need to browse a website that NetSurf wont handle, edit ODT/DOC files or do my e-mail (currently in a webmail interface that NetSurf refuses to use and the firefox port to RISC OS displays in a weird way). My Debian server is usually headless and I access it all via VNC from RISC OS now… Much more interested in this if it can get RISC OS running on a netbook/chromebook device and then maybe a bit of software bridging to get WiFi on there too…? That would be awesome! |
Tristan M. (2946) 1039 posts |
I just did a completely unscientific comparison. I have a copy of my H3 port source tree on both the OPiPC2 and the RPi3. So I set both building at the same time. Doing a build without doing the clean steps first resulted in this: I didn’t clean first because my attention span is only so long. They were both in the same initial state anyway. The difference could be media based, but I’d be surprised if a backup spinner was faster than a thumb drive. |
Jeffrey Lee (213) 6048 posts |
Linux will aggressively cache filesystem contents, RISC OS will not. So it wouldn’t surprise me if a fair amount of the performance difference was the result of that. e.g. apart from the final link stage, each build pass will involve invoking amu ~100 times. RISC OS will read the binary from disc each time, Linux will likely just use a cached copy. |
Rick Murray (539) 13806 posts |
Not to mention objasm, cc, a billion header files, etc etc. It’s a shame a full installation of RISC OS (built) is ~590MB, otherwise one could try building it entirely on RAMdisc to see how much difference that would make [RAMFS can’t cope with “big” discs, so we’re limited to the half-gigabyte maximum].
I wouldn’t. I don’t buy thumb drives any more. The majority of them can’t keep up with the MPEG stream coming out of my satellite receiver, unless I’m watching some really low bandwidth channel like horror or True Movies (about 840MB/hour MPEG-2), though some thumb drives can’t even manage to cope with that reliably. You’ll notice, perhaps, that harddiscs often quote seek times and data speeds; while SD cards often quote data speeds and burst speeds (those are the “10000x!!!” markings in bold, useless for sustained writing, mind you); but thumb drives? Just tell you their capacity. I believe that thumb drives are built to recycle all the crappy slow flash chips that won’t cut it in SD/CF/etc cards these days…
So…
|
Colin (478) 2433 posts |
It’s about 305MB when compiled – about 117MB clean. It compiles ok on a ram disc. On an ArmX6 recompiling an already compiled rom on a ram disc takes 22secs and on an SSD it takes 39secs I find the quickest way to download the sources and have a working copy is to download via CVS. |
Chris Mahoney (1684) 2165 posts |
Bear in mind that this is the same NHK that began HD broadcasting way back in 1991! |
Rick Murray (539) 13806 posts |
Uh, they’re Japanese… at 5:3 aspect, they had a 1125 line 60 Hz system in 1972. Apparently their HD recording of the ‘84 Olympics gave Reagan a kick in the ass when he saw the difference between that and America’s NTSC. Having HD in the early ‘90s wasn’t that big a deal. Remember D2-MAC on satellite? 1152 lines, 50Hz, 16:9. Oh, by the way, back in the ’70s NHK also created a monochrome HD format that ran at 50Hz and gave a staggering 2125 lines at 4:3 aspect. But people in general preferred to trade off resolution for colour. |
Chris Mahoney (1684) 2165 posts |
Wow, 1972?! I hadn’t heard of that one. Research time! :) |
Rick Murray (539) 13806 posts |
Reference from 1981 – https://books.google.fr/books?id=czq6dx0uvBYC&pg=PA40&lpg=PA40&source=bl&ots=5cvzxA-wQd#v=onepage&q&f=false Popular Electronics magazine. Starts at the bottom right of the page. Let me know if you find anything further that isn’t just copied from Wikipedia or NHK. |
Rick Murray (539) 13806 posts |
Yeah. I just realised. When I did a count of the directory… Uh… It would have included the source archive and the tar file…
It would be nice to have regular updates instead of periodically rebuilding from scratch, but CVS never seemed to want to work for me… It’s a shame the update archives (daily/weekly/monthly) are in CVS form and not just a nice draggy-droppy bunch of files. |
Colin Ferris (399) 1809 posts |
Just a Test msg from WebsterXL |
Colin (478) 2433 posts |
CVS is handy for fetching parts of the riscos source tree. For example to ensure I was using the latest LanManFS for the test module I made, I downloaded the sources for it with:
which downloaded to the current directory. The If you use ‘checkout’ instead of ‘export’ then the directories have the CVS directories in them. If the current directory is changed to a directory containing a CVS directory then you only need use the ‘cvs’ command as it will use the repository named in the CVS directory. So in your own repository you would ‘checkout’ a project with ‘mycvs’ change the current directory to inside the checked out directory and then just use ‘cvs’ to manipulate the repository and ‘checkin’ your changes. |
Dave Higton (1515) 3497 posts |
A blast from the past! |
Timothy Baldwin (184) 242 posts |
I have hacked parallel build support into srcbuild, using Linux fork system call. I needed to work around a number of assumptions of sequential builds in the RISC OS source. |
Timothy Baldwin (184) 242 posts |
I have add an insecure mode to the Linux2 branch so you can use it if Bubblewrap doesn’t work. For example:
Tristan, please can you test this? I have joined up the history of the Linux and Linux2 branches, using replace refs. You can fetch them with:
You can then use git bisect on it, for example automatically:
|
RonM (387) 60 posts |
I have bought my first Chromebook, an Asus C201PA (RK3288 4MB/16MB) If all else fails, it will still be a great portable internet machine, and I have ordered a car charger. My Blackberry Z30 does an effortless mobile hotspot and can possibly relay gps position via gpslink. I will be installing a dual boot debian for veyron speedy by the looks of things so far. |
Timothy Baldwin (184) 242 posts |
You can override the decision to use QEMU by setting the QEMU make variable to /usr/bin/env:
|
Tristan M. (2946) 1039 posts |
I’ll test it as soon as I can. Any preference regarding what I test it with? |
Tristan M. (2946) 1039 posts |
I’ve had a couple of edge case failures. Not surprising but I might as well list them. The old VIA chipset tablet couldn’t build because its old kernel doesn’t support SYS_renameat2 (I think that’s what it was) in comma2attr. The OPiZero (H2+) could build it mostly. It just fell over because RDP doesn’t seem to support xrandr. So again, not the code’s fault. It did essentially build though. Success on OPiPC2, I think. Running via just “run_RISC_OS” or the desktop script results in a failure. “Can’t remount readonly on /newroot/: Invalid Argument”. However it does boot fine with “RISC_OS__INSECURE=YES ./run_RISC_OS”. This is after building with “make INSECURE=YES”. |
Timothy Baldwin (184) 242 posts |
That’s now fixed, if |
Tristan M. (2946) 1039 posts |
I’ll bring the tablet out again probably tomorrow and test it. I just finished doing a quick test on the OPiPC2 by doing a ROM build. Nothing seemed to break. It’s running kernel 4.14.70-sunxi64 e: Bonus content. I tried !Doom on the OPiPC2. Last time I tried it it didn’t work. I still have to run !RunImage directly, because of a missing sound SWI IIRC, but it runs, and well at that. e again: SOmething has bothered me for a while. in run_RISC_OS line 77 is it supposed to be eval “bwrap_extra=($RISC_OS__BWARP_EXTRA)” |
Timothy Baldwin (184) 242 posts |
Fixed. I was inadvertently relying on Bubblewrap 0.3.0 behaviour.
Was “INSECURE=YES” required? Or is “QEMU=/usr/bin/env” sufficent? Delete the “Built” directory to reset the detection logic. |
Tristan M. (2946) 1039 posts |
Which order would you like me to try things in? I didn’t try “QEMU=/usr/bin/env” at all. The bubblewrap failure tended to flow through to QEMU, so I tried INSECURE=YES first. I just noticed something. There is a “build” and a “Build” directory in the “RISC_OS_Dev” root. “Build” being new. I think I’ll completely delete the repository and re clone it before trying again. |
Timothy Baldwin (184) 242 posts |
To completely clean a Git work tree and reset to current branch it is sufficient to:
And to rest to the upstream Linux2 branch:
You could do the tests in order from most likely to work to most features:
I suspect your problem is that you did not have a working copy of Bubblewrap and that this lead an earlier version to try to use QEMU and it remembered that decision. I have now fixed that bug and it will fail if Bubblewrap is not present unless you use INSECURE mode. Due to the error message you quoted I believe you now have a working version of Bubblewrap and it will now work correctly. |
Tristan M. (2946) 1039 posts |
It’s late so I just tested “RISC_OS__INSECURE=YES ./run_RISC_OS” on the OPiPC2. Builds and runs with no errors that I could see. I’ll try the other two tomorrow. That was by far the best result to date. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20