Jump to content
jedimatt42

TIPI Usage and Support

Recommended Posts

The buster upgrade process is uploaded. TIPICFG will report that 1.65 is available, but if you have buster, you'll end up at 2.0, if you are on stretch, you'll be dead-ended at 1.65.

 

When I ran, it worked, but my TIPICFG / 4A crashed pretty early on, as my 4A is want to do. It completed the upgrade successfully. 

 

I'll have to start again back at 1.43 to find out if that is isolated or not... 

Share this post


Link to post
Share on other sites

upgrade process is working now... It can take you all the way from buster based TIPI 1.43 upto 2.1

 

The 2.0 has a defect the prevents upgrade from happening. To work around that, and pick up the fix, just ssh into the PI, and:

touch /tmp/tipiupgrade

Upgrade will begin, and the mechanism will be fixed for futures... This also fixes the mechanism for detecting when upgrade or reBoot are complete.

 

I will release an updated 2.1 SD card image. And re-issue an emulation bundle.

  • Like 4

Share this post


Link to post
Share on other sites

Oh, and I totally forgot about the things that use @ElectricLab 's TIPI NetVariables.py  instead of TCP to access myti99.com... 

Those are reportedly - totally broken - by the python3 upgrade. 

 

Maybe I can fix them.. maybe not... how they work is undocumented.

Share this post


Link to post
Share on other sites

Matt,

 

One very minor issue I’ve encountered both before and after 2.0:  TIPICFG doesn’t like my WiFi SSID because it has spaces in it.  It will let me type it in, but it truncates it after the first space.  I was able to get around this by editing PI.CONFIG from TI BASIC and it displays fine on TIPICFG after that and it works fine with the SSID with the spaces.  I just can’t input it in TIPICFG successfully.  

 

For everyone else so inclined, I did attempt to upgrade my Raspbian stretch to buster in place, mainly just to see if it would work at all.  I had saved off all my disk images from the TIPI prior to doing so just in case I bricked my install.  The upgrade worked, but the TIPI was not happy after I did that (any access to the TIPI just caused the TI to hand with the TIPI access light stuck on).  I then re-flashed my SD card with the 2.0 image and all is well.  I was able to upgrade to 2.1 using the touch command provided above, so all seems ok.

 

Thanks!!

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, Casey said:

Matt,

 

One very minor issue I’ve encountered both before and after 2.0:  TIPICFG doesn’t like my WiFi SSID because it has spaces in it.  It will let me type it in, but it truncates it after the first space.  I was able to get around this by editing PI.CONFIG from TI BASIC and it displays fine on TIPICFG after that and it works fine with the SSID with the spaces.  I just can’t input it in TIPICFG successfully.  

 

For everyone else so inclined, I did attempt to upgrade my Raspbian stretch to buster in place, mainly just to see if it would work at all.  I had saved off all my disk images from the TIPI prior to doing so just in case I bricked my install.  The upgrade worked, but the TIPI was not happy after I did that (any access to the TIPI just caused the TI to hand with the TIPI access light stuck on).  I then re-flashed my SD card with the 2.0 image and all is well.  I was able to upgrade to 2.1 using the touch command provided above, so all seems ok.

 

Thanks!!

The 'stretch' stream doesn't provide a sufficiently updated version of python3. So that's not going to work. 

 

TIPICFG should probably just let you fully edit the wpa_supplicant.conf --- I'll add an issue to github, that it is behind the times... :)  https://github.com/jedimatt42/tipi/issues/131

Share this post


Link to post
Share on other sites
Posted (edited)

I guess i'll wait for the 2.1 sd image to be uploaded before i try this upgrade.

16 hours ago, jedimatt42 said:

upgrade process is working now... It can take you all the way from buster based TIPI 1.43 upto 2.1

 

The 2.0 has a defect the prevents upgrade from happening. To work around that, and pick up the fix, just ssh into the PI, and:

touch /tmp/tipiupgrade

Upgrade will begin, and the mechanism will be fixed for futures... This also fixes the mechanism for detecting when upgrade or reBoot are complete.

 

I will release an updated 2.1 SD card image. And re-issue an emulation bundle.

 

Edited by jrhodes
  • Thanks 1

Share this post


Link to post
Share on other sites

There are no real features included in this major update, it is mostly ground work for future development. So no one needs to hurry... 

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

Hmm, i know sd cards can be partitioned with the right tools.

Maybe i'll install grub, and dual boot between 1.65 stretch and 2.1 buster releases? ;-)

J/K ... (or am i?)

Edited by jrhodes

Share this post


Link to post
Share on other sites
13 minutes ago, jrhodes said:

Hmm, i know sd cards can be partitioned with the right tools.

Maybe i'll install grub, and dual boot between 1.65 stretch and 2.1 buster releases? ;-)

J/K ... (or am i?)

I guess I don't understand how people use this... if you want to have 1.65, just stay there. 2.1 will add no value to you. 

Share this post


Link to post
Share on other sites
Posted (edited)

I was (jokingly) suggesting that as a solution for if you can not get the NetVariables.py issue resolved.

When needed, i could boot back into 1.65 where it still works in stretch and use it, then reboot back into 2.1 buster for more normal use.

Edited by jrhodes

Share this post


Link to post
Share on other sites
1 hour ago, adamantyr said:

How do we upgrade by SSH'ing into the TIPI? The usual upgrade path won't go beyond 1.65.

 

Yep, bugs happened. . . I will have to fix that and provide a 1.66 that warps you over as the changes in 1.65 didn't quite cut it.

 

Nothing but 'upgrade' should be broken by 1.65, so when I have a solution, I'll send it... 

 

Things were broken on 2.0 and 2.1 and 2.2 , but I think I've got them sound no on 2.3  :)  

 

The 2.0 SD card isn't worth going to if you haven't already... it also has an upgrade bug.

Share this post


Link to post
Share on other sites

@adamantyr So, the path from 1.65 is pretty messed up.. :) Here is what I believe will get you straightened out:

 

SSH in to the PI as user 'tipi':

$ sudo /home/tipi/tipi/setup/upgrade.sh
Current Version: 1.65
Latest Version: 2.3
$ sudo /home/tipi/tipi/setup/upgrade.sh --upgrade
...

This will get you to the correct branch, but errors out early before performing the actual upgrade... 

 

$ cat /home/tipi/tipi/version.txt
version=2.3
reldate=2020-07-02
$ cat /home/tipi/tipi/branch.txt
branch=buster_release
$ sudo /home/tipi/tipi/setup/post-upgrade.sh
...

This should now run all the working, latest 2.3 upgrade code. and finish with restarted services

 

It takes a while. lots of lines, 139 for me, like this:

Get:101 http://mirror.web-ster.com/raspbian/raspbian buster/main armhf libncursesw5 armhf 6.1+20181013-2+deb10u2 [94.3 kB]

then it will move on to upacking the packages,

then 'setting up' all those packages... 

then a couple rounds of virtualenv / requirements.txt stuff...

then the php stuff for TidBit...

then this happened:

modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.19.75-v7+/modules.dep.bin'
modprobe: FATAL: Module i2c-dev not found in directory /lib/modules/4.19.75-v7+

May or may not for you... I'm not supporting the sometimes attached i2c OLED display anymore, so this is probably not a problem... 

 

It should all end in: 

upgrade complete

 

Services are running... ( I rebooted for good measure since I saw kernel update, and this above issue: sudo reboot now ) 
 

----------

It has been my experience so far that updating directly in TIPICFG from 1.43 to 2.2+ works. 

  • Like 1

Share this post


Link to post
Share on other sites
23 hours ago, jedimatt42 said:

Oh, and I totally forgot about the things that use @ElectricLab 's TIPI NetVariables.py  instead of TCP to access myti99.com... 

Those are reportedly - totally broken - by the python3 upgrade. 

 

Maybe I can fix them.. maybe not... how they work is undocumented.

For the record: 'NetVariables' were designed to do two things: Have persistent local variables (my initial use-case was for storing a login session cookie), and to allow data transfer to/from remote hosts - things that were not yet supported by the TIPI code when I wrote them. I'd have continued developing them had I not been discouraged from making further commits.

Share this post


Link to post
Share on other sites
55 minutes ago, jrhodes said:

@jedimatt42 i don't suppose there is a directory of old tipi sd images?

I like having older versions, just in case.

 

Then you should have backed them up.

  • Like 1

Share this post


Link to post
Share on other sites

True, that is my mistake.

Still putting the request out there though, if any has older sd images for tipi, please pm me.

Share this post


Link to post
Share on other sites
47 minutes ago, jrhodes said:

True, that is my mistake.

Still putting the request out there though, if any has older sd images for tipi, please pm me.

The SD card images that I published weren't always the best ones to run... I was pretty lazy about it... usually only after some large upgrade process, and then usually the SD card image isn't the working version, but a few updates after that are what were useful... 

 

The entire thing has been under source control though... so you all can fork, and follow the instructions to build a new old version... 

I deleted 1.43 from my machine and aws last night.. Or I would have pointed you at it.. 

 

As the author, I actually have the opposite desire.. I want everyone to be forced to help make the current version better by reporting issues, instead of working around things by reverting to an old version.

  • Like 1

Share this post


Link to post
Share on other sites

On a separate note... I do apologize for how messy that update ended up... This was thousands of lines of change due to python 3 white space rules, and changes around string and bytearray encoding which is pretty much what 95% of the functions in TIPI do.. Plus the merger of the emulation support path.  I am happy today with the outcome. 

 

I think everyone has a path forward. 

 

One user stuck on stretch has made it forward by following online instructions to first perform a distribution upgrade. After that the manual upgrade steps posted earlier finished the job.  This did prove to take longer than flashing the new image + backup + restore of TIFILES... but maybe you have other changes I don't want to know about that you want to preserve... It has at least proven possible.

 

And you should find that more types of disk images unpack when placed in the TIPI share directly or through the web-ui.

And we have TIPI emulation that should be able to keep up naturally. 

 

  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)

Are there QI (non-V2.2) compatibility issues?

Backstory:

I've spent the better part of two weeks, time permitting with my new https://github.com/jgparker/tipi/wiki.

The micro-SDHC image never worked OOTB, so I located Etcher and put tipi-sdimage-buster-1.43.zip on it.

That install worked long enough to get my SSID/PSK entered (took a wpa_supplicant change to find my hidden router); finally pulled an IP.

Grew the file system per https://github.com/jgparker/tipi/wiki/tipi-32k-installation.

Backed up the 8 GB SDHC via Win32DiskImager (7,761,920 KB) so I didn't have to go through that all over again.

When I got back to it a few days later, next (U)pgrade offered was V1.63. A tad more stable for slightly longer periods.

Also backed up the entire image again so I didn't have to go through the V1.43>V1.63 all over again.

 

Next several attempts over days through tonight have yielded (photo) when offered the (U)pgrade to V1.65.

Longest run so far is just over an hour upgrade time in progress between QI lockups.

>>> PI green light shows no activity after first minute and TIPI led does a 360 Hz busy flash like it is doing something.

QI console is locked again. I've cleaned sideport contacts and all the normal stuff to give it the best chance of success

 

Any help would be appreciated.

 

Doug

 

 

EDIT:

Configuration B

Having no luck with the above setup, I moved on to tipi-sdimage-buster-2.3.zip from https://www.jedimatt42.com/downloads.html.

CALL TIPI from TI Basic immediately locked up the console (photo2) with version, DSR build blank, and a few other screen differences noted.

CRU is now 2000?

 

I'm open to troubleshooting either or all of these configurations if the herd has moved on to V2.3, but I'm certainly getting less far on this build.

 

 

TipiSetup.JPG

TipiSetup2.JPG

Edited by helocast
More information

Share this post


Link to post
Share on other sites

This sounds like a hardware issue. 

 

Intermittent lock ups usually mean problem with the connection between the PI and the TIPI board.   However, there isn't much room for error there given @J-Data's design.

 

If the PEB is connected and powered on, you'll need to make sure only one memory card is active, and that the crubase of the TIPI is not in conflict with the floppy controller. Either of those could cause the same issues. 

  • Like 1

Share this post


Link to post
Share on other sites

I can see from your screen shots, that in one run you show a crubase of >1000 and in another a crubase of >2000. ( You pointed this out, and I failed to read well ) 

 

There is no physical way to set the crubase to >2000, so this points at hardware problem again. I highly doubt any of your trouble has had anything to do with the sd card image versions.

 

Loading TIPICFG requires successful transfer of about 16k between the TIPI and PI. If that works, usually everything about it works... Before the version info can load, it does try to read data off of github.com to see if there is a new version. 

 

Are you able to run the cartridge bin: https://github.com/jedimatt42/ti994a-32kmemtest/releases - Bad ram can cause any issue... your problems are so 'all over the place' that I would think a RAM problem or a bridge on one of the data lines... although the crubase magic change, might indicate a bridge around the address pins. Odd though since 0x2000 and 0x1000 don't share bits. 

 

The direct answer to the QI compatibility question is: I don't know.  If a PEB works with a QI system, I would expect a sideport TIPI to also work. But, you might be the first person trying it.   

  • Like 1

Share this post


Link to post
Share on other sites

I was noticing the same thing with my setup (tipi in PEB) when I tried 2.0 and up ... lock ups, CRU randomly changes to 2000. I could still SSH into the PI, but I couldn’t access it from the ti anymore. The only thing that would temporarily fix it was reflashing, but I kept having problems so now I am back at 1.43 for now. It crashed in the middle of a multiple hour update to 1.6, and I haven’t had time to try updating it again. I have a pi zero and a SAMS card. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...