Author Topic: Punix (Read 43224 times)

TC01 · « **Reply #15 on:** March 01, 2011, 07:31:02 am »

Nice to see that Punix is still in development! I remember reading about it a while ago and thinking it was dead.

Good luck with this project.

christop · « **Reply #16 on:** March 02, 2011, 09:07:22 pm »

Quote from: DJ_O on February 28, 2011, 07:55:10 pm

Will betas and the final version be available in binary form too? It might be a bit too much to recompile it everytime a new build comes out, but a lot of less tech-savy calculator/computer users tend to have troubles compiling softwares, as we could see with Ndless 2.0 with the flood of questions asking for help on how to compile Ndless due to errors.

Yes, I will definitely release compiled binaries for betas and release versions. Up to this point I haven't felt that it was ready to call it a beta (I still consider it to be alpha), but now I do have a semi-usable shell and a somewhat functional kernel, so maybe I ought to release a beta to let people try it out easily in an emulator. Let me commit my recent changes (mostly to the userspace shell) and then I will release a binary soon.

christop · « **Reply #17 on:** March 03, 2011, 03:38:02 am »

I'm pleased to announce the first Beta release of Punix! Download the compiled TIB file here from SourceForge. This is a ROM for the TI-92+.

Open that file in TiEmu (or another TI-92+ emulator) and boot it up. DO NOT SEND IT TO A REAL CALCULATOR! DON'T BLAME ME FOR BRICKING YOUR CALCULATOR IF YOU DO ANYWAY!

You can read the full release notes (including some tips and things to do with it) here.

Let me know if you have any questions or find any bugs (besides regarding the overall incompleteness of the system). I already know a few bugs cropped up somehow during this release that weren't there before... Strange how that happens.

DJ Omnimaga · « **Reply #18 on:** March 03, 2011, 05:04:11 am »

GLad to hear

. I cannot test right now but I'll see if I can get TiEmu installed later. Someone should make an animated screenshot

Lionel Debroux · « **Reply #19 on:** March 03, 2011, 05:15:38 am »

Good

Jim Bauwens · « **Reply #20 on:** March 03, 2011, 07:38:37 am »

I just tried it! It's just awesome, and it even include top,cat,date and uname.
(But for some reason cat doesn't work)
*me is a happy person

TC01 · « **Reply #21 on:** March 03, 2011, 08:28:41 am »

When you release the final version, could you make a .9xu of it and sign it using the 92+'s OS key, instead of using TIB?

I understand that TIB is just a good as a real OS file for TiEmu (and as this is a beta it's not really a good idea to try it out on a calc, as you say), but when it's actually intended to run on a calc, it'd be nice to have the signed version too.

christop · « **Reply #22 on:** March 03, 2011, 01:29:28 pm »

Quote from: jimbauwens on March 03, 2011, 07:38:37 am

(But for some reason cat doesn't work)

I hate to put it this way, but it Works For Me(tm). The shell doesn't pass any arguments to the applets, so without arguments, cat only echoes (echos?) each line that you type. Type Control-D to exit cat. This is how cat works on a "real" *nix too.

Note: I don't think I mentioned this anywhere yet (besides inside the source code), but the diamond key is Control, 2nd key is Alt, and MODE is Compose (similar to the Compose or "Multi" key in X11). Type MODE plus two characters to type a single "special" character. For example, MODE c / types a cent symbol, and MODE i " types i with an umlaut. The full list of combinations is in keyscan.c.

Quote from: TC01 on March 03, 2011, 08:28:41 am

When you release the final version, could you make a .9xu of it and sign it using the 92+'s OS key, instead of using TIB?

To be honest, I haven't been following all of the developments in the TI calculator world very closely. Is there actually a key to sign the OS now? Yes, if I can sign it with a key to make a .9xu file instead of a .tib file, I would, at least for "production" versions (I hope there isn't a "final" version, since that implies to me that the project is unmaintained or dead).

christop · « **Reply #23 on:** March 03, 2011, 03:47:35 pm »

I just uploaded Beta 2. This release adds support for command arguments in the shell, including support for quoting (both double and single quotes) and character escaping (using the backslash \ character), almost exactly like a real shell.

I also added the "echo" command, and "cat" can now open files and write them to standard output. Punix only understands only a few built-in filenames at the moment: /dev/{vt,link,audio,random}. You can try cat'ing any of those files but you might not like the results! You might have to reset the calculator afterwards too.

Download beta 2

DJ Omnimaga · « **Reply #24 on:** March 03, 2011, 03:50:36 pm »

Nice to see a new update

Quote from: christop on March 03, 2011, 01:29:28 pm

Quote from: TC01 on March 03, 2011, 08:28:41 am
When you release the final version, could you make a .9xu of it and sign it using the 92+'s OS key, instead of using TIB?
To be honest, I haven't been following all of the developments in the TI calculator world very closely. Is there actually a key to sign the OS now? Yes, if I can sign it with a key to make a .9xu file instead of a .tib file, I would, at least for "production" versions (I hope there isn't a "final" version, since that implies to me that the project is unmaintained or dead).

Yeah the keys were all factored 1.5 years ago: http://www.ticalc.org/archives/news/articles/14/145/145273.html

TI responded with a DMCA notice, but the TI community won with the help of the EFF.

christop · « **Reply #25 on:** March 03, 2011, 04:19:31 pm »

Quote from: DJ_O on March 03, 2011, 03:50:36 pm

Nice to see a new update
Quote from: christop on March 03, 2011, 01:29:28 pm
Quote from: TC01 on March 03, 2011, 08:28:41 am
When you release the final version, could you make a .9xu of it and sign it using the 92+'s OS key, instead of using TIB?
To be honest, I haven't been following all of the developments in the TI calculator world very closely. Is there actually a key to sign the OS now? Yes, if I can sign it with a key to make a .9xu file instead of a .tib file, I would, at least for "production" versions (I hope there isn't a "final" version, since that implies to me that the project is unmaintained or dead).
Yeah the keys were all factored 1.5 years ago: http://www.ticalc.org/archives/news/articles/14/145/145273.html

TI responded with a DMCA notice, but the TI community won with the help of the EFF.

Yup, I remember the DMCA notice, but I forgot that it was about the OS keys. Go EFF!

I'll have to add signing the OS to my Makefile sometime between now and an actual release.

Jim Bauwens · « **Reply #26 on:** March 03, 2011, 04:26:41 pm »

@christop, I checked it, and you are correct (of course). It was stupid from me not to try that.
I tried both beta's, and they really look neat! Can't wait to put this on on of my calcs

christop · « **Reply #27 on:** March 04, 2011, 03:46:52 am »

So... one of the bugs in the betas is in the /dev/audio test. When you run "tests" and get to that test it just basically freezes the whole system, and you have to reset the calc. Turns out I was allocating a 4K stack for the user process, but the audio test tried to use 12K of stack for its own audio buffers. The stack is located near the bottom of memory, right above the kernel variables, so the process was overwriting many (if not all) of the kernel variables. Ouch!

I fixed that already in my working copy, but I'm still scratching my head over another really tough bug. See this tracker page for as many details about the bug as I can think of: https://sourceforge.net/tracker/?func=detail&aid=3199268&group_id=184747&atid=910492

In all the years of working on Punix I've never had this happen before, and I just cannot figure out what is causing it. It's difficult to solve because I can't make TiEmu break on the offending address (0x0000002f) before the address exception triggers. If I could I would at least be able to see what is on the supervisor stack before it is overwritten by the address exception handler. Since it happens only after many hundreds or thousands of times calling the same system call over and over (it happens seemingly at random), I can't really step through the code in the debugger and find what is causing it.

I'd like to fix this bug for good and not just sweep it under the rug, since it'll pop back up when I least expect it.

If any of you can crack this bug, I would be most grateful! Good luck!

Lionel Debroux · « **Reply #28 on:** March 04, 2011, 04:59:21 am »

In the general case, such low addresses might be NULL dereferences... but I don't think you have any struct with a misaligned word/long field (unless you're using the packed attribute, and not using the struct type directly, otherwise the compiler should figure on its own that it needs to make multiple byte accesses)...
Judging by the values of the a2 and a3 registers you posted in the bug tracker entry on SF, it could also be a (normally aligned) word/long read at offset 0x2e from the 0x1 address (which is getting misaligned for some reason).

TIEmu does enable you to break upon address error, although after overwriting several bytes at the bottom of the execution stack. By reading those overwritten bytes, you can at least get the address of the offending instruction (minus a couple bytes, IIRC). That might enable you seeing which part of the code triggers the address error.

christop · « **Reply #29 on:** March 04, 2011, 01:27:49 pm »

Quote from: Lionel Debroux on March 04, 2011, 04:59:21 am

In the general case, such low addresses might be NULL dereferences... but I don't think you have any struct with a misaligned word/long field (unless you're using the packed attribute, and not using the struct type directly, otherwise the compiler should figure on its own that it needs to make multiple byte accesses)...

Just to check, I'm using the packed attribute only once for struct flashblock in flash.h:

Code: [Select]

struct flashblock {
        long blockno;
        char data[BLOCKSIZE];
} __attribute__((packed));

I'm pretty sure both members are word-aligned (BLOCKSIZE is an even value), and besides that, I'm not currently using the only functions that use that structure. Even in assembly code I'm pretty careful to keep addresses word-aligned, unless they point to byte/character buffers.

Quote

Judging by the values of the a2 and a3 registers you posted in the bug tracker entry on SF, it could also be a (normally aligned) word/long read at offset 0x2e from the 0x1 address (which is getting misaligned for some reason).

That's possible, and I'll look around for any jumps to an offset of 0x2e from %a2 or %a3. I can't think of any assembly code that I wrote that does a jmp 0x2e(%a2), so if that's what happened it must be compiled code.

Quote

TIEmu does enable you to break upon address error, although after overwriting several bytes at the bottom of the execution stack. By reading those overwritten bytes, you can at least get the address of the offending instruction (minus a couple bytes, IIRC). That might enable you seeing which part of the code triggers the address error.

I do have a breakpoint on the address error exception, but I want to see the contents of the supervisor stack before the exception to see if the kernel returned to address 0x2f, or if this was caused by userspace (which I doubt).

Now that I think of it, the top of the kernel stack is located at 0x4c00, and it's possible that I wrote just below the screen address during a system call, and that trashed the kernel stack. I'll see if I can move the kernel stack somewhere else and then try to replicate this bug.

Author Topic: Punix (Read 43224 times)

TC01

Re: Punix

christop

Re: Punix

christop

Re: Punix

DJ Omnimaga

Re: Punix

Lionel Debroux

Re: Punix

Jim Bauwens

Re: Punix

TC01

Re: Punix

christop

Re: Punix

christop

Re: Punix

DJ Omnimaga

Re: Punix

christop

Re: Punix

Jim Bauwens

Re: Punix

christop

Re: Punix

Lionel Debroux

Re: Punix

christop

Re: Punix