Announcement

Collapse
No announcement yet.

Aopen Chromebase Mini with Alpine Linux, Squeezelite and Jivelite

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Below are the scripts I am currently using which allowed for:

    - boot to Alpine login
    - ts_calibrate init script runs and automatically runs the ts_calibrate application if there's no /etc/pointercal file, it also creates an /etc/ts.dev file with the touchscreen device path in it.
    - jivelite init script runs to start jivelite

    So basically boot all the way to jivelite with the only interaction being the first time through the touchscreen calibration, after that it's all the way to jivelite. I have these packaged up for easier installation but it's really not ready to post quite yet. But you should just be able to put jivelite and ts_calibrate into /etc/init.d/ and jivelite-sp into /usr/bin/ and then:

    Code:
    rc-update add ts_calibrate
    rc-update add squeezelite
    rc-update add jivelite
    rc-update add alsa
    Code:
    cbox01:~/repo/alps$ cat jivelite
    #!/sbin/openrc-run
    # Copyright 1999-2015 Gentoo Foundation
    # Distributed under the terms of the GNU General Public License v2
    
    depend() {
        after squeezelite sshd
    }
    
    start() {
        ebegin "Starting Jivelite"
        if [ -e /etc/ts.dev ]; then
           export SDL_MOUSEDEV=$(head -n1 /etc/ts.dev)
           export SDL_MOUSEDRV=TSLIB
           export JIVE_NOCURSOR=1
        fi
    
        start-stop-daemon \
        --start \
        --background \
        --exec /usr/bin/jivelite-sp \
        --pidfile /run/jivelite.pid \
        --make-pidfile
        eend $?
    }
    
    stop() {
        ebegin "Stopping Jivelite"
        start-stop-daemon \
        --stop \
        --exec /usr/bin/jivelite-sp \
        --pidfile /run/jivelite.pid
        eend $?
    }
    Code:
    cbox01:~/repo/alps$ cat ts_calibrate 
    #!/sbin/openrc-run
    
    export HOME=/root
    TSDEFAULT=/etc/ts.default
    TSDEV=
    
    depend() {
    	after bootmisc hwdrivers modules
    	before jivelite
    }
    
    # Given an event name, find it in the /dev tree.
    # This accounts for differences between mdev and udev
    scan_dev ()
    {
        SHORTDEV=$1
    
        if [ -z "$SHORTDEV" ]; then
           TSDEV=
           return 1
        elif [ -e /dev/$SHORTDEV ]; then
           TSDEV=/dev/$SHORTDEV
        elif [ -e /dev/input/$SHORTDEV ]; then
           TSDEV=/dev/input/$SHORTDEV
        else
           TSDEV=
           return 1
        fi
    
        return 0
    }
    
    default_ts ()
    {
        # Gets the filename from the first line of the config file.
        SHORTDEV=`head -1 $TSDEFAULT`
    
        # If the specified file exists, use it with no questions asked.
        if [ -e $SHORTDEV ]; then
           TSDEV=$SHORTDEV
        else
           return 1
        fi
    
        return 0
    }
    
    find_ts_legacy ()
    {
        # Legacy method - fallback if capabilities are broken
        SHORTDEV=`dmesg | grep -i "ts \|input: ts\|tsc\| touch[ ]*screen" | grep -o input[0-9] \
        | sed s/input/event/`
    
        scan_dev $SHORTDEV
        return $?
    }
    
    find_device ()
    {
        if [ -e $TSDEFAULT ]; then
           default_ts
        fi
    
        if [ -z $TSDEV ]; then
           find_ts_legacy
        fi
    
        if [ $TSDEV ]; then
          echo $TSDEV > /etc/ts.dev
        else
          rm -f /etc/ts.dev
          exit 1
        fi
    }
    
    run_calibration ()
    {
        if [ ! -s /etc/pointercal ]; then
          ts_calibrate > /tmp/`basename $0`.log 2>&1
        fi
    }
    
    start() {
    	ebegin "Configuring touchscreen"
    	find_device
            run_calibration
    	eend $?
    }
    
    stop() {
    	return 0
    }
    Code:
    cbox01:~/repo/alps$ cat jivelite-sp 
    #!/bin/sh
    
    export LOG=/var/log/jivelite.log
    
    if [ ! -z ${JL_FRAME_BUFFER} ]; then
        export SDL_FBDEV=$JL_FRAME_BUFFER
        echo "Using $SDL_FBDEV as frame buffer device." >> $LOG
    fi
    
    if [ -z ${JL_FRAME_RATE} ]; then
        JL_FRAME_RATE=22
    fi
    
    export JIVE_FRAMERATE=$JL_FRAME_RATE
    
    echo "Frame rate set to $JIVE_FRAMERATE frames per second." >> $LOG
    
    if [ -z ${JL_FRAME_DEPTH} ]; then
        JL_FRAME_DEPTH=32
    fi
    
    /usr/sbin/fbset -depth $JL_FRAME_DEPTH >> $LOG
     
    echo "Frame buffer color bit depth set to $JL_FRAME_DEPTH." >> $LOG
    
    #while true; do
     #   sleep 3
        /usr/bin/jivelite >> $LOG 2>&1
    #done
    // I guess I should note that I modified the ts_calibrate script from here:
    Last edited by sodface; 2021-05-09, 13:39.

    Comment


      #17
      One other thing, full disclosure on the squeezelite package I have in my repo, on the most recent builds I added a small patch to go along with an LMS plugin I'm ever so slowly working on which would allow you to make changes to player settings (including OS level changes with a companion script on the player) from the LMS side.

      All the below patch does is catch a message from LMS when you click the apply button in the plugin, then sends a SIGUSR1 signal to the alps script/daemon running on the player to process whatever changes were made. As you wouldn't have the plugin on the LMS side or the alps daemon on the player side, that extra bit of code will never do anything.

      Code:
      cbox01:/srv/aports/repo/squeezelite$ cat alps-slimproto.c.patch 
      --- a/slimproto.c.orig
      +++ b/slimproto.c
      @@ -469,6 +469,9 @@
       				}
       			}
       		}
      +	} else if (setd->id == 9) {
      +		LOG_INFO("alps settings change id: %u", setd->id);                                    
      +		system("pkill -SIGUSR1 -x alps");
       	}
       }

      Comment


        #18
        I just bought a set of Neumi BS5P bookshelf speakers that were (re)reviewed here and discussed on Audio Science Review here.

        I like them! The bar is pretty low with me though, I've been using lamp cord for speaker wire for so long that the nice, smooth, flexible, silicone cable they provided to tie the speakers together sold me before I'd even powered them on
        Attached Files

        Comment


          #19
          I updated the USB boot image to Alpine 3.14.0 with Kernel 5.13. I also made a couple updates to the Alpine wiki page, besides the new download info I finally realized that there's no hardware rtc on this, or there is but there's no battery to maintain it if unplugged?

          I see this in dmesg:
          Code:
          [    0.338576] rk808-rtc rk808-rtc: registered as rtc0
          [    0.339051] rk808-rtc rk808-rtc: setting system clock to 2013-01-18T08:52:05 UTC (1358499125)
          I added the openrc swclock service to start at boot so the system clock is initially set to last shutdown time and then ntp makes it correct.

          Here's the wiki page with download link at the top:


          I originally thought the flash was not write protected but when I recently tried to set the gbb flags to shorten the dev screen delay, flashrom kept reporting that write protect was enabled. Oddly, when I used the flashrom command to disable it, it reported Success!, but checking status immediately after that still reported enabled. I ended up taking the back panel off and using my chip reader and clip to read the flash, delete the vpd "stable_device_secret_DO_NOT_SHARE" and then write back. After that flashrom reported that write protect was disabled.

          I then updated the gbb flags to shorten the boot delay, disable the annoying beep, and added a simple Alpine bitmap for the boot screen. I can't get a good pic of it in action, but here's a jpg of the source bmp and blurry boot pic:
          Attached Files
          Last edited by sodface; 2021-07-02, 23:19.

          Comment


            #20
            I figured out that I needed to enable CONFIG_DRM_PANFROST in the kernel config to get hardware video decode working, which it now seems to be. I updated the wiki and download there. Terrible pic again, but this is Alpine with xorg, bspwm tiling window manager and 4 instances of mpv playing .mp4 DVD rips from an NFS mount on my file server over wifi.

            What does this have to do with this forum? Not much I guess, but I was thinking rather that having fullscreen jivelite on the framebuffer, install a basic x windows environment and divide the screen up with jivelite in one part and, well, other things in the other parts?? Clock, audio visualizer, weather etc. Nothing new here but nice to know that these Aopen devices have the horsepower to experiment and do different things with.
            Attached Files

            Comment


              #21
              How to "Unstick" from Enterprise Enrollment?

              [QUOTE=sodface;1018774]I got the two that were stuck in Enterprise Enrollment... unstuck So those have been wiped and reloaded with Alpine tonight. There's a (harmless?) warning on boot


              I've obtained one of these devices, but it's indeed "stuck" in Enterprise Enrollment. How did you fix this issue in your case?

              Comment


                #22
                Originally posted by Themistocles View Post
                I've obtained one of these devices, but it's indeed "stuck" in Enterprise Enrollment. How did you fix this issue in your case?
                I had to buy a chip programmer and clip. Open it up and read the VPD off the flash to a file, delete a couple of keys from the file, zero out the serial number, and write it back.

                This is where I started:


                But it doesn't really cover our situation specifically. Let me know if you need more detailed instruction or PM me and I'll send you my cell number.

                Comment


                  #23
                  "Unbricking" AOPEN Chromebase Mini

                  Greetings Sodface!

                  Thanks a ton for your quick reply. This Forum never ceases to amaze me for having many more helpful and conscientious members than it has trolls... Quite a rarity these days!

                  As a new Forum member, this is only my second post. As I understand it, I need one more post to be allowed to PM you. So I will post one more message in this chain before I contact you that way (that will probably be tomorrow at the earliest -- I'm in the Pacific Time Zone and I'm guessing you're probably not, so it's probably much later in the evening where you are).

                  I really appreciate your willingness to share your cell phone number and to walk me through this. Stay tuned for that PM eventually!

                  Cheers from a fellow Squeezebox enthusiast.

                  Comment


                    #24
                    More on "Unbricking" the AOPEN Chromebase Mini

                    Howdy Sodface!

                    The web site you graciously provided has recommended this kit on Amazon for $15: "ACEIRMC SOIC8 SOP8 Test Clip For EEPROM 93CXX / 25CXX / 24CXX + CH341A 24 25 Series EEPROM Flash BIOS USB +1.8V Adapter + Soic8 Adapter Programmer Module Kit (1 sets)" So this is what you used and what I need to get? I just want to confirm before I place any order...

                    I'm reasonably comfortable as a hobbyist tinkerer and I don't mind opening the Chromebase up. Once upon a time in a galaxy far away, I installed Linux on an old Chromebook -- an early model, before manufacturers added all these protections and before ChromeOS TPM chips existed -- and that was fun and not too hard. So I figured this AOPEN device would be similar. Boy, was I wrong!

                    Sadly, I'm not skilled enough to recognize interior components on sight when I open up a strange device unless they are very obvious, so I have no idea where to find the appropriate EMMC or EEPROM flash chip specifically -- or where to connect the SOIC8 programmer if/when I buy it. I found some interior photos of the Chromebase online from "CERPASS TECHNOLOGY CORP. Report No.: 1701078," but nothing's labeled in those photos and I have no idea where I'd start.

                    I can't expect you to post a detailed procedure for your hack, that's asking too much. Sure, if you had an iFixIt-style guide with captioned and highlighted photos with all the key points circled, I could follow it... but I will content myself to receiving any guidance you'd like to offer by cell or by this message thread.

                    Again, please accept my heartfelt gratitude for any assistance you are willing to give. Just knowing there is light at the end of this tunnel is very encouraging, all by itself!

                    Catch you later.

                    Comment


                      #25
                      Originally posted by Themistocles View Post
                      The web site you graciously provided has recommended this kit on Amazon for $15: "ACEIRMC SOIC8 SOP8 Test Clip For EEPROM 93CXX / 25CXX / 24CXX + CH341A 24 25 Series EEPROM Flash BIOS USB +1.8V Adapter + Soic8 Adapter Programmer Module Kit (1 sets)" So this is what you used and what I need to get? I just want to confirm before I place any order...
                      I ordered that same kit and ignored some of the comments there that say the clip is not good. eg. "Works fine but the clip is garbage. Does not clip, don't think its you." He was right, the clip in the kit was infuriating. I had to go back and order this one for another $25:


                      Which did indeed work and I've used it several times since so worth the extra money (I guess!).

                      I'm reasonably comfortable as a hobbyist tinkerer and I don't mind opening the Chromebase up. Once upon a time in a galaxy far away, I installed Linux on an old Chromebook -- an early model, before manufacturers added all these protections and before ChromeOS TPM chips existed -- and that was fun and not too hard. So I figured this AOPEN device would be similar. Boy, was I wrong!
                      We are on the same trajectory, I did the same on an older Toshiba Chromebook and then nothing since until these Chromebases. I'm just glad the first one I bought wasn't stuck in enrollment or I may have given up before I began.

                      Sadly, I'm not skilled enough to recognize interior components on sight when I open up a strange device unless they are very obvious, so I have no idea where to find the appropriate EMMC or EEPROM flash chip specifically -- or where to connect the SOIC8 programmer if/when I buy it. I found some interior photos of the Chromebase online from "CERPASS TECHNOLOGY CORP. Report No.: 1701078," but nothing's labeled in those photos and I have no idea where I'd start.

                      I can't expect you to post a detailed procedure for your hack, that's asking too much. Sure, if you had an iFixIt-style guide with captioned and highlighted photos with all the key points circled, I could follow it... but I will content myself to receiving any guidance you'd like to offer by cell or by this message thread.
                      See pic below. The crappy black clip in the kit also bumped into the side of the heat sink, preventing it from going on straight so I ended up removing the heat sink but it didn't really help the clip grip, it still would just pop off or just not read at all when I did manage to get it to stay in place long enough to run flashrom. The blue replacement clip works without removing the heat sink.

                      Note though that the blue clip does not come with a cable harness attached. I cut off the one from the black clip and soldered it to the blue clip. I have a decent soldering setup and heat shrink tubing etc. so that wasn't an additional cost for me. Not sure how you are setup in that area?

                      You could roll the dice and see if you can get the black clip to work. In theory, it only has to clip and read/write one time unless you plan on using it for more of these or other projects.

                      Again, please accept my heartfelt gratitude for any assistance you are willing to give. Just knowing there is light at the end of this tunnel is very encouraging, all by itself!

                      Catch you later.
                      No problem, happy to have the reply and conversation! Another option would be to send it to me for me to do and then return. Shipping might end up costing more than buying the bits though, and certainly wouldn't be as much fun.
                      Attached Files
                      Last edited by sodface; 2021-07-08, 14:50.

                      Comment


                        #26
                        Many Thanks! This Info Really Helps!

                        Thank you for the photo with the chip highlighted, I think that's enough to get me started on my way... I might not need to PM you after all, unless I get stuck. There's certainly no need for me to bother you further if I can get this under control, using the info you've already provided as a great start! I'll start reading the MrChromebox Wiki more closely now.

                        I take it once the clip and programmer are properly attached, I'll find that there's nothing frustrating about how the AOPEN folks programmed their chip? MrChromebox mentions using particular ROM file names for specific devices and motherboards, but then seems to go more generic when describing VPD files. Is there some obscure and hard-to-find filename for the AOPEN ROM that I need to know?

                        Some Amazon reviewers spoke of finding Windows drivers for the SOIC8 USB programmer after an extensive search -- but MrChromebox recommends using a Linux box with his "flashrom" package instead. I'm OK with Linux (though I'm no guru on the CLI), so I can make that work, but I'm wondering what you recommend. Do you think it matters much whether my "diagnostic repair box" runs Windows 10 or Linux (assuming Windows software akin to "flashrom" can be found)? Or is 64-bit Windows just incompatible with this kind of repair? I'm assuming you used Linux for its "driverless simplicity" and had no issues.

                        Since I'm a retired tinkerer, I have a decent Hakko soldering kit (although it's a lot better than my rudimentary soldering skills deserve), so I believe I could perform the clip surgery you describe. I might try trimming some plastic off the black clip in the Amazon kit (with sandpaper, a Dremel, or a razor blade) to make it fit better in tight spots (although your experience leads me to believe that's probably fruitless).

                        However, before I buy anything and then destroy the black clip to solder the blue clip, I'll look a bit deeper first for a better pre-wired clip on Amazon, just in case. If I can find one at a decent price with exposed contacts like your blue clip example, then I might buy that. At first glance, I wouldn't have guessed that a more exposed pin design would be superior to the more enclosed black clip in the cheap Amazon kit (those exposed pins on the blue clip won't bend under spring pressure?), but other Amazon reviewers agree with you. I'm definitely taking your advice to find a clip that will maintain good contact. I think this SOIC8 device could be something I'd use again in the future on other projects...

                        I very much appreciate the offer for you to do the repair if I ship it to you... but I'm not sure I could afford your services! Seriously, though, that's really above and beyond -- so all I can say is that you're too kind and "I'm not worthy."

                        I'm going to give this a shot on my own and see how it goes. I'm all in for "fun!"

                        Eventually, I'll report back in this thread and let you know how it goes.

                        Comment


                          #27
                          Originally posted by Themistocles View Post
                          I take it once the clip and programmer are properly attached, I'll find that there's nothing frustrating about how the AOPEN folks programmed their chip? MrChromebox mentions using particular ROM file names for specific devices and motherboards, but then seems to go more generic when describing VPD files. Is there some obscure and hard-to-find filename for the AOPEN ROM that I need to know?
                          No, I think the implementation on the Chromebase is pretty standard and consistent with instructions I've found on the net.

                          Some Amazon reviewers spoke of finding Windows drivers for the SOIC8 USB programmer after an extensive search -- but MrChromebox recommends using a Linux box with his "flashrom" package instead. I'm OK with Linux (though I'm no guru on the CLI), so I can make that work, but I'm wondering what you recommend. Do you think it matters much whether my "diagnostic repair box" runs Windows 10 or Linux (assuming Windows software akin to "flashrom" can be found)? Or is 64-bit Windows just incompatible with this kind of repair? I'm assuming you used Linux for its "driverless simplicity" and had no issues.
                          I used Alpine Linux and compiled several tools that weren't in the Alpine repos, for instance the Alpine version of flashrom doesn't have all the options that the ChromeOS version does so I made a different package, all those are in my x86_64 repo at sodface.com. I really can't speak to what problems you'd run into working with Windows, maybe none? I did not use the Mr. Chromebox utilities he has listed but compiled my own for Alpine (but I repeat myself).

                          I'm going to give this a shot on my own and see how it goes. I'm all in for "fun!"

                          Eventually, I'll report back in this thread and let you know how it goes.
                          Seems like you have a good plan, I'm just not sure how to advise on the Windows part. Looking forward to hear about your progress as you go! Let me know if I can help.

                          Comment


                            #28
                            SOIC8 Programmer Ordered!

                            I've just ordered my programmer kit from Amazon, it should arrive next week.

                            I've decided against trying Windows -- I'll be using this chip programmer kit with Linux on a laptop. I don't currently have a Linux machine with Alpine, but I've got Mint (based on Ubuntu). This old laptop of mine is a repurposed "throwaway" workbench PC with no data on it that I care about -- so if I really need Alpine and the Sodface repos, I could just wipe Mint and install Alpine on it, to see if I like it. If using Alpine makes this repair go more smoothly, then it's worth it.

                            It'll be good to get accustomed to Alpine anyway, I guess, since that's what ultimately will be installed on the AOPEN Chromebase Mini when all is said and done.

                            I'm looking forward to using all of Sodface's Alpine and Squeezelite install procedures (as well as his deep-dive flashrom fix for my "stuck" Chromebase Mini) to get this AOPEN beast working in a week or two as a "Squeezebox-Touch-on-Steroids" (with either a Dragonfly or Topping E30 external DAC, eventually). I'm assuming that the nominal headphone audio output of the AOPEN machine wouldn't match the Touch for resolution or quality, but I do love this bigger AOPEN screen and its heavy duty metal shell! It seems to be a quality piece of equipment. I can let an external DAC do all the heavy lifting for audio, if necessary.

                            All credit to Sodface for discovering this machine, cracking open its guts, and devising an elegant way to get Squeezelite working on it! Outstanding!

                            The saga continues in the coming weeks...

                            Comment


                              #29
                              No Joy...



                              I hope sodface sees this report...

                              My low-cost SOIC8 kit arrived from Amazon this week -- but whatever I try, it gives no result. I can't get past first base, so I'm not sure if it even works. My CH341A programmer looks exactly like the one pictured on the MrChromebox web site, but it does NOT respond the way he describes, at least not with my set up. I'm not sure what is going wrong here -- it's almost as if the flashrom software cannot recognize the CH341A hardware.

                              As sodface warned, the spring clip in the original kit was poor, it barely made contact because of the AOPEN heat sink being in the way. I purchased the better blue clip that sodface recommended, soldered the wire harness from the old clip to the new blue clip, and yes, the blue clip seems to provide more stable pin contact. However, the blue clip made no difference otherwise -- I still get the same result using the CH341A programmer: that is, nothing happens except errors being thrown...

                              I tried using the kit on Linux Mint first with my "throwaway laptop" (an old plastic white MacBook that initially had Linux Mint 18 on it), but when that failed, I punted and wiped it to install Alpine.

                              Sadly, that install failed and Alpine wouldn't boot -- probably something to do with UEFI boot params on the MacBook, so I put it aside and turned back to Linux Mint 17 on an older mini-laptop PC. I tried the Ubuntu repository version of flashrom, but no joy. I used MrChromebox's version of flashrom (supposedly compatible with Ubuntu flavors of Linux, like Mint), still no joy. Ultimately, I even tried the 'chmod +x flashrom' command to be sure that the flashrom script was executable. Still, I always get the same results regardless of which flashrom version, Linux computer, or programmer clip that I use. Yes, I wanted to try sodface's version of flashrom, but I couldn't get Alpine installed and I'm not sure it would have changed the results anyway.

                              Bottom line: whenever I use the command "sudo ./flashrom -p ch341a_sp1" as directed by MrChromebox, this is the inevitable response (screenshot):

                              Click image for larger version

Name:	Screenshot.jpg
Views:	1
Size:	20.6 KB
ID:	1572877

                              As for the hardware itself, upon insertion into a USB slot, the red "power" light comes on and stays steady on the programmer, but the CH341A gets quite warm if left plugged into USB for more than 30 minutes. If I take care to notice, the "run" light occasionally blinks for a nanosecond when the CH314A is initially plugged into USB, but otherwise it never lights up. Could the programmer be bad? On his web site, MrChromebox mentions a "1.8V adapter" is sometimes required -- so do I need an extra voltage source here? I see no power socket on the CH341A other than the USB plug, so where would that extra 1.8V even go...?

                              If you're reading this, sodface, you're my only hope.

                              Comment


                                #30
                                Themistocles - sorry to see you are having issues, I know it's frustrating but I think we can get it sorted. Unfortunately I'm in bed already so I won't be able to actually open one up until tomorrow but I've been meaning to because I need to disable the write protection on a few of them that I have.

                                I don't understand the syntax error you are seeing, makes me think the format of your command line is incorrect but I can't tell for sure from your post. Almost looks like the flashrom binary you are using is compiled for a different architecture?? Going back through my command history, here's a few that might help:

                                Just doing:
                                Code:
                                sudo flashrom -p ch341a_spi
                                Should report back the chip type it's discovered indicating you have a good connection.

                                This is reading the original flash contents to a file named chromebase.orig.bin:
                                Code:
                                sudo flashrom -p ch341a_spi -r chromebase.orig.bin
                                The basic process I did was to read the original flash off to a file, as above, make a copy of the file and then edit it with vpd, like this to zero out the serial and delete a couple of keys:
                                Code:
                                vpd -i "RO_VPD" -f chromebase.new.bin -s "serial_number"="00000000000000000000000"
                                vpd -f chromebase.new.bin -i "RO_VPD" -d "stable_device_secret_DO_NOT_SHARE"
                                vpd -f chromebase.new.bin -i "RO_VPD" -d "mlb_serial_number"
                                Then write it back with:
                                Code:
                                sudo flashrom -p ch341a_spi -w chromebase.new.bin
                                Something like that. I hate writing stuff up without actually doing it at the same time for verification. I'll hook up to one tomorrow and try to make it more clear.

                                As far as Alpine goes, you _should_ be able to boot the extended iso from USB and just use it running out of RAM without installing to disk, so you could do that with a newer machine without much risk of borking your normal OS install.
                                Last edited by sodface; 2021-07-17, 04:57.

                                Comment

                                Working...
                                X