September 24, 2017, 09:40:54 pm
News:
Pages: 1 [2]
Print
Author Topic: The continuing saga of pfft and his OSD(s)...  (Read 6946 times)
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #15 on: January 31, 2011, 08:54:03 am »

So, my first question is: How can I turn off this weekly check?  (I've been living with it for years now - and have found it annoying  - but after today's adventure, it is more than annoying).  I'm pretty sure I've seen a setting in the menus somewhere to turn it off - but I couldn't find it just now.  So, if someone could inform me where it is,  that'd be nice.

Main menu -> Settings -> Firmware upgrade -> set "Frequency" to "Off".

Ba-ding. Wink


On my system (OSDng), it is Tools/FirmwareUpgrade  (There is no "Settings" on the home menu).

Anyway, thanks.  As I said, I knew it was there, just didn't see it when I was composing my previous post.

Edit: And, indeed, that line (with id=1) is now gone from the SQL database!
« Last Edit: January 31, 2011, 08:55:40 am by pfft2001 » Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 340



View Profile WWW
« Reply #16 on: January 31, 2011, 09:00:29 am »

On my system (OSDng), it is Tools/FirmwareUpgrade  (There is no "Settings" on the home menu).

Anyway, thanks.  As I said, I knew it was there, just didn't see it when I was composing my previous post.

Edit: And, indeed, that line (with id=1) is now gone from the SQL database!

Yup. You're right. I'll go stick my head in a bucket. Had to get up early for some girl to read the electricity meter (flip side: stayed up half the night watching animé)...

Best wishes,

Rick.
Logged
greyback
Administrator
Hero Member
*****
Posts: 1639


View Profile
« Reply #17 on: January 31, 2011, 01:32:20 pm »

G - liking the idea of a better build system. I can't for the life of me figure out the current one, and given I'm using a slowish emulation, anything that can build without attempting to rebuild EVERYTHING can only be a good thing!

Yes Neuros' build system is a (being nice) esoteric collection of Makefiles and shell scripts. It took me a long time to figure out what's going on. But yeah, it's infuriating that everything is rebuilt with ./build-helper.sh. No intelligence applied there sadly.

New build system is nicer, well more friendly. I'm fighting to get it build a basic image right now. Not having a TV, and missing my serial cable, means testing will be fun.

Quote
Re. performance, would this change make much difference? Most of the hard work takes place in the codecs/DSP. It seems to me that finding ways to trim Qt may make the biggest difference? But that would seem to be a mammoth job. What was Torfu based upon? Perhaps QtLite (or whatever it is called) is the step forward? How compatible is it with what we already have?
Only by trying it will we see if things improve. Floating point arithmetic is a lot slower with OABI than EABI, so that could improve GUI stuff. Yeah Qt is huge, and it's hard to shrink it much, so its performance can only be seen. I'm hoping to get a simple QtQuick app running on the OSD, to gauge the graphics performance. If it's better, then I'll try Neuros' UI again.

Torfu's GUI was all Neuros-written stuff on top of NanoX, a basic embedded-device X server. It is lighter than the Qt stuff, but trying to code it was a nightmare. What took 2 years to code with NanoX took 3 months in Qt.

So these are the things I want to explore. If anything comes to fruition I'll not keep it to myself Smiley
-G
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 340



View Profile WWW
« Reply #18 on: January 31, 2011, 05:15:41 pm »

It took me a long time to figure out what's going on.

Could you give me a nutshell version?

Quote
But yeah, it's infuriating that everything is rebuilt with ./build-helper.sh. No intelligence applied there sadly.

I think the first thing to do is work out where everything gets deleted, and remove that. My old RISC OS compiler, and TurboC used to only rebuild if the source was newer than the object file, I hope the Neuros way is capable of doing likewise...

Quote
Not having a TV, and missing my serial cable, means testing will be fun.

Ah, light on, light off. Mine is hooked to a USB capture device on the laptop.


Quote
Floating point arithmetic is a lot slower with OABI than EABI, so that could improve GUI stuff.

You've lost me here... FP is not performed in hardware? I remember Acorn, for some reason, never wanted on-board FP (and this crippled things like ray tracing), but I thought ARM mostly decided otherwise when they split from Acorn? Or does the TI chip work with some unholy logic like "why d'you need FP when you have a DSP?".

Quote
Yeah Qt is huge, and it's hard to shrink it much,

Mmm, that's one of the drawbacks of a mainstream GUI system. It has to be all things to all people, and as such gets unwieldly.

Quote
What took 2 years to code with NanoX took 3 months in Qt.

Sounds like it needed better libraries and such. Ideally a GUI should be abstract enough that you can say "open a window that looks like so here, and call me when something happens". For extra Brownie Points, a filter system so you can specify events you do/don't want to know about...


Quote
So these are the things I want to explore.

And I, as said, some of the niggles in the apps. At least we won't be duplicating the same thing. Wink Was it you who mentioned an "app store"? I was thinking of an idea where the base firmware is record/play, and pretty much everything else is optionally added in from a repository, with support for individual app updates. These things, obviously, being installed on CF.

Don't need Lighttpd? Don't need Samba support? Just untick them and save the space/time/resources...

However, this is but an idea. I'll start by breaking some currently-working code. Smiley


Quote
If anything comes to fruition I'll not keep it to myself Smiley

Likewise. I think we could learn a lesson from OSDng, for it was a good step forward, but what good is that when the work can't be carried on? My initial work might only work on OSDng - the system apps, scheduler, youtube, etc. Are they read-only under Arizona? They are read/write for me (and as such can be arbitrarily replaced).

Okay, time for a cuppa and a think.


Best wishes,

Rick.
Logged
greyback
Administrator
Hero Member
*****
Posts: 1639


View Profile
« Reply #19 on: February 01, 2011, 02:17:12 pm »

Could you give me a nutshell version?
Look for the "Makefile"-s. They do the actual work. build-helper.sh is a wrapper script around them. Makefiles call Makefiles in other directories, and so on. Figure out the Makefile syntax & you'll understand what's going on.

Most of the build work happens in Neuros-Cooler/external-libs/ and in linux-r3-main-app/

In the SVN repo/tarball that you download, nearly all the libraries in Neuros-Cooler/external-libs/ are pre-built in the binaries folder, so the build process just copies them over. Nearly everything else is compiled (save the closed stuff, and cifs - which is a bitch to cross-compile I've heard)

Lots of little things happen all over the place, it's hard for me to put words to them, sorry Sad

Quote
But yeah, it's infuriating that everything is rebuilt with ./build-helper.sh.
I think the first thing to do is work out where everything gets deleted, and remove that. My old RISC OS compiler, and TurboC used to only rebuild if the source was newer than the object file, I hope the Neuros way is capable of doing likewise...
It's just the "build-helper.sh all" script that deletes everything. If you step through the build-helper commands "bsp, external-libs...." it doesn't delete things (in the Makefile lingo - clean)

The Makefile system is much smarter. But the build-helper is there to ensure everything is built in the right order. This matters. The Makefiles don't monitor the status of files installed in the rootfs (neuros-bsp/fs/rootfs) - so this can cause problems if you're not careful to do everything in the right order.

Quote
Floating point arithmetic is a lot slower with OABI than EABI, so that could improve GUI stuff.
You've lost me here... FP is not performed in hardware? I remember Acorn, for some reason, never wanted on-board FP (and this crippled things like ray tracing), but I thought ARM mostly decided otherwise when they split from Acorn? Or does the TI chip work with some unholy logic like "why d'you need FP when you have a DSP?".
The ARM chip has no FPU, so all floating point arithmetic is emulated by the kernel. With OABI, when a binary tries to do FP, it throws an exception, which the kernel catches, performs the arithmetic, and returns it to the binary. With EABI, it just makes the kernel to do it straight away. Throwing an exception is costly speed-wise (so I've read!)

Quote
What took 2 years to code with NanoX took 3 months in Qt.
Sounds like it needed better libraries and such. Ideally a GUI should be abstract enough that you can say "open a window that looks like so here, and call me when something happens". For extra Brownie Points, a filter system so you can specify events you do/don't want to know about...
Yep, but GUI libs are hard things to engineer from scratch. Qt does a lot of it right.

I was thinking of an idea where the base firmware is record/play, and pretty much everything else is optionally added in from a repository, with support for individual app updates. These things, obviously, being installed on CF.

Don't need Lighttpd? Don't need Samba support? Just untick them and save the space/time/resources...
Nice idea. You'll need a packaging system. They can be tricky to set up. Ipkg is nice for embedded stuff.

Arizona had / as read-only, and /media/ext as read-write. OSDng had all read-write, using an overlay filesystem called "mini_fo". Build this kernel module, insmod it and configure things right, and you'll get Arizona with read-write everywhere.
-G
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 340



View Profile WWW
« Reply #20 on: February 02, 2011, 05:21:22 pm »

Can you suggest a way to get the uImage file (without going the whole route of downloading and building the source).

Offhand, I think your best bet would be to pull apart a UPK file. Looks easy enough, a little bit of code ought to split them.

Mmm... Draggy-selecty is a bit of a case of hit and miss with Android. But can't complain, my older phone couldn't do this at all.

Anyway, I don't like to mention projects before I have working code, but in this case I thought it might be prudent to mention I am working on a little program called "deupk". No ETA, but of course I'll post something when...


Best wishes,

Rick.
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #21 on: November 17, 2012, 09:29:23 am »

So, my first question is: How can I turn off this weekly check?  (I've been living with it for years now - and have found it annoying  - but after today's adventure, it is more than annoying).  I'm pretty sure I've seen a setting in the menus somewhere to turn it off - but I couldn't find it just now.  So, if someone could inform me where it is,  that'd be nice.

Main menu -> Settings -> Firmware upgrade -> set "Frequency" to "Off".

(Another old thread necro-ing.  It even warned me that I should start a new thread instead)

Anyway, a few (semi-) interesting points about the firmware upgrade functionality:

1) It is Main menu -> Tools -> Firmware upgrade (i.e., Tools, not Settings)
2) There can be a mismatch between what it says onscreen and what is in the scheduler.sql database.  I found that on both of my machines, there was an entry in the SQL database even though the onscreen said "Off".  But, when I clicked "OK" on the onscreen, the record in the SQL database was removed.  The point being that you may have to do that - to ensure that the two views are "in sync".  Incidentally, changing the onscreen to something other than "Off" - and OK'ing out - causes the SQL database record to be re-created.  Setting it back to "Off" causes it once again to be removed.
3) Curiously, on one of the machines, even though the onscreen said "Off", it was still periodically going out and looking for updates (in, it seems, all the wrong places [*]).  I was getting an error message that it could not contact the updates server and that I should check my network settings.  I'm guessing that that server is no longer running.

[*] A reference to an old US country music song - a reference probably lost on non-US readers.

P.S.  Anyway, now both scheduler.sql databases are empty - so, presumably, no more looking for updates (in all the wrong places) will be occurring...
« Last Edit: November 17, 2012, 09:34:29 am by pfft2001 » Logged
Pages: 1 [2]
Print
Jump to: