Jump to content

What about Google Home


gounthar

Recommended Posts

42 minutes ago, chrisf said:

What about porting Google Home to an ARM linux distro

have fun to find a dev who is willing to do that... :lol: Isn't it enough to have google on your phone, browser, mailaccount etc.? :D 

 

I was interested in googles AIY vision kit.. for the first 2-3 months googles definition of sources was to release an image...  And now you can look into this mess: https://github.com/google/aiyprojects-raspbian/tree/aiyprojects So I don't spend much time with google 'opensource' projects as long as I've other options. 

 

1 hour ago, gounthar said:

Armada 1500 SoC.

mainline support for the SoC is there... never checked how good it is.. And if it makes sense to step into it.. I don't see an use-case except the microphone array they have built into it.. And IMO google has enough microphones in my rooms they don't need another one.. :lol:

Link to comment
Share on other sites

Sorry for not being clear. I want to know if it could be possible to exorcize Google out of a Google Home and put a virgin Linux instead...

It's not a serious project, just a "what if???". :D

Link to comment
Share on other sites

11 hours ago, chwe said:

mainline support for the SoC is there... never checked how good it is..

 

The Armada 1500 family consists of totally different SoCs, the '1500 Mini Plus' is pretty uninteresting, the whole business unit is now part of Synaptics who locked everything away and this is the status of upstream support: https://github.com/torvalds/linux/tree/master/arch/arm/mach-berlin

 

Good luck.

Link to comment
Share on other sites

4 hours ago, gounthar said:

Sorry for not being clear.

It was clear enough.. ;) I just see it more from a use-case side. Those 'google home boards' have IMO one interesting feature, microphone arrays. The interesting feature of a microphone array is voice to text applications. From what I know, such voice to text stuff is a way harder than things like image detection stuff. Mozilla has an opensource project (https://voice.mozilla.org/en and https://github.com/mozilla/DeepSpeech/) in this field but most others are closed. IMO, I don't see a reason to support google by buying their thingie just to put something opensource on it. But everyone is free to decide if it's worth or not. We don't live in an opinion dictatorship. 

4 hours ago, gounthar said:

It's not a serious project, just a "what if???". :D

If you see it as a learning experience, why not? It can be fun (and pain) to get things working on a new platform. You learn a lot of stuff during such a 'pet project'. But as @tkaiser said, the Armada 1500 family is spread on a bunch of different SoCs, so the next problem you'll run into it will be to educate 'your testers/users' on which google thingie your Image will work and on which it doesn't. And the same that Armbian suffers from: why does *random feature* not work properly? Try it, write about your progress and your questions. I'm sure there are people here who will give you some hints when you fail. :) 

 

Link to comment
Share on other sites

49 minutes ago, chwe said:

It can be fun (and pain) to get things working on a new platform.

 

We're not talking about a development board that makes accessing the hardware and especially the boot process easy but a rather expensive surveillance device people buy for whatever bizarre reasons. The technical details are so f*cking boring that everyone who disassembles the spy tool to get access to this boring PCB IMO must be mad. :) 

 

If someone wants to waste a lot of time please contribute to Armbian in a more sensible way instead of wasting your time on hardware not worth a look with a target audience (for Linux on this thing) that does not exist.

 

Link to comment
Share on other sites

I agree that the board is boring.. Most thingies with only one dedicated job are boring. They need to do one job good but not more. In this case, get more information from the user for googles databases.. :rolleyes::lol:

 

I partly disagree on your second point due the following reasons:

  • Starting motivation is mostly driven by personal needs/abilities. I want to achieve something or I have this hardware and want to step into this 'low level stuff'. Starting with a boring board may save you from 'pressure to deliver'. Nobody cares when you fail with a 'boring board' whereas people can be really annoying when it's a board of interest. Why, why, why does *random feature* not work. From my own experience: The BPi R2 was/is mostly fun cause nobody cares.  The tinkercam was/is annoying cause people ask on a monthly base why this shitty thing doesn't work (in fact it would work but it breaks to much stuff to implement it at the moment). 
  • 'We' horrible fail in giving 'easy tasks' to beginners. There's a bunch of stuff which can be enhanced in armbian but a beginner may need some 'guidance' either to identify such a task nor guide/help them during this problem solving of such a task. I think this is mostly related to lack of time. Guide someone in the beginning will cost more time than do it on your own. Sometimes it's worth the efforts cause the one you guide will contribute after its on his own, sometimes it's not worth the efforts cause she/he will disappear after one 'sub-project' and you have to deal with code you've only reviewed, not written on your own. 
  • Funnily we help a lot of people building their own 'pet project' or solve issues they have 'on top of Armbian'. But in the gray area between maintainers and end-users we somehow suck in supporting those people which may contribute more than one PR in the future. That's why I encourage people to try things even on 'boring board'. It may not help armbian in the beginning but hopefully the one or the other will learn some stuff to contribute after its to more interesting boards and/or more important tasks. Will it work? Is it worth? I've no idea... :lol: Fact is, we support to many platforms/SoCs/boards for the current 'team of devs'. So we can either step down and support less boards or we try to encourage more people to contribute to the project. I'm not sure if this approach will work, but at least @JMCC could benefit from my experience with u-boot when he started to play with the renegade, wasn't IMO that a bad deal for the armbian project to help him with some basics in the beginning (u-boot is painful when you deal with it the first time). 
Link to comment
Share on other sites

In fact, there was a very thin chance that I could win this device today... and I won it (at a conference, where I talked about SBCs, HypriotOs, Armbian, and so on). :D

So I have this device now, and I really don't want to plug it in and use it with Google soft. I will contribute to Armbian in a way or another, and already run it on several of my devices.

Thanks a lot for your feedback.

 

As some of my colleagues seem to be very interested by that "thing", I may also resell it and buy a SBC that needs some testing for Armbian... Any suggestion?

Edited by gounthar
New ideas
Link to comment
Share on other sites

19 hours ago, gounthar said:

As some of my colleagues seem to be very interested by that "thing", I may also resell it and buy a SBC that needs some testing for Armbian... Any suggestion?

Now you've to decide which 'pet project' you choose. :P 

Personally, I don't think you should buy the SBC which needs most testing.. You should buy one in which you're interested. Debug & testing can be boring so at least the product you test should be interesting (for you). Therefore I don't recommend a specific SBC, maybe SoCs which (I think) are interesting makes more sense.

  • RK3399, a bunch of boards are coming up, armbian just starts to support those boards. The 'overall' sources situation seems to be good in terms of documentation for the SoC and kernel sources. I'm not fully familiar how evolved u-boot (e.g. ram initialization, spl etc.) is. Drawback, they aren't that cheap (you've probably add a bit of money to the money you get from your colleague).
  • RK3328, relatively cheap and powerful IO (e.g. USB3). Overall more evolved as the rk3399 but for sure still work to do.
  • Just for fun: MT7623 - only cause I'm working on it :lol:. Only me works (sometimes) on this SoC, at the moment, only one board is widely available (BPi-R2) rumors are ongoing that other boards will show up, but I don't have much information here. Kernel is pure mainline and u-boot is very outdated (v2014). But as @tkaiser pointed out, this might also be one of these boards which don 't make that much sense, mostly cause there's only one board with the SoC available at the moment. In case more boards show up, it might get more interesting due to its decent mainline support. 
  • Allwinner H6. Bloody edge, seems that after @Igors first commits there aren't many people interested in contribute to the related boards (I don't follow it close enough for a proper statement here).

 

It probably makes more sense when a developer presents one of his ideas/projects for armbian and you decide if this is interesting for you and if you want to join it. Some of these projects might be hardware depended others might be more generic. Your skills and/or topics you might want to dive in should also be considered (when I started with the MT7623 I had neither 'much' knowledge in the buildscript, kernel and u-boot but you'll learn things partly on the fly as long as you've a high frustration barrier :lol: don't expect that you make everything right in the beginning :P).

Not to forget, documentation and/or tutorials are also always welcome. Show one of your project you deployed on top of armbian. 

Link to comment
Share on other sites

Thanks a lot for your detailed answer, lots of food for thought.
I already own a board with H6, the OrangePi One Plus. I don't know how I could help with this one...

As for the RK3399, there are quite a lot of very interesting (to me) cards... 96boards, OrangePi, FriendlyElec, Firefly... Difficult choice.

Regarding the RK3328, lots of cards looks nice: ROCK64, Renegade, ROC-RK3328-CC, SwiftBoard Data...

And for the MT7623, it looks interesting, but I see almost only routers with this SOC... which could be a good thing for one of my use if I understood well network bonding with Linux (I could have lots of data to send (video from phone screens), and splitting it on 6 differents Ethernet plugs could help).

Link to comment
Share on other sites

16 hours ago, gounthar said:

And for the MT7623, it looks interesting, but I see almost only routers with this SOC...

the router is still questionable..  Due to shitty performance. There are some ideas to 'solve it' but all of them seems to be hacky... and not really wanted. But when you're driven by a need, this board might be fun.. 

 

16 hours ago, gounthar said:

I already own a board with H6, the OrangePi One Plus. I don't know how I could help with this one...

Why not? The board is basically here: https://github.com/armbian/build/blob/master/config/boards/orangepioneplus.wip

E.g. The OPi One Plus has the same RTL8211E PHY attached as the PineH64. @Icenowy added support for this PHY for the pineH64: https://github.com/Icenowy/linux/commit/66ae9ca01bd3d7f111952ff60f8eef782e6151c1

I'm not sure if just adding the DT-Nodes in 'sun50i-h6-orangepi-one-plus.dts' is sufficient to get it working.. But could be fun to get Ethernet working on this board, would make the board a way more usable.  :)

 

FYI: this patch was added for the pine H64, but I don't know if and how well it works there (as said, I don't follow H6 development close enough): https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/board-pine-h6-pine-h6-0035-arm64-allwinner-h6-add-support-for-the-Ethernet-on-P.patch

 

 

 

Link to comment
Share on other sites

So the easiest way for me (others might do it differently) is:

  1. Fork the project on github
  2. clone your fork
  3. create a new branch on top of master for the stuff you want change
  4. switch to your branch in config-default.conf e.g. for my BPi R2 development 
    LIB_TAG="bpi"

     

  5. Set create patches to yes: 
    CREATE_PATCHES="yes" 

     

  6. During build the buildscript says you when you've to make the changes.
  7. Test your new image and when it works as expected copy the generated patch to the corresponding patchfolder and rename it meaningful
  8. Test if it still works there and doesn't break any other patch (for your patch this will be unlikely but just make sure to follow 'good practices' from the beginning, it saves you and the maintainers time as soon as you create patches which may have the potential to break something).
  9. Push your new branch to your fork and create a Pullrequest against Armbians master branch where you describe what your patch does, the output of armbianmonitor -u (they may see stuff errors which came up with your patch which you didn't recognize).

Why do I create branches on top of master and don't change things directly in master?

Simply due to lazyness... In case my PR doesn't get accepted I don't have to play the git-ninja :ph34r: I just remove the branch and sync my masters branch with armbians repo. As long as my master doesn't have any changes to armbians, sync is everytime fast forward means I don't create useless 'sync commits' which then confuse the armbian maintainers when I create a PR. For sure, when I'need longer for patching something (e.g. the BPi branch), I may have some sync commits in it but not for 'the short ones'.

 

Why test two times?

Just to make sure it doesn't break things. Armbian for sunxi has a bunch of patches this enhances the chance that your patch can break something, so better try your best to avoid it. You can't test everything, but test what you can test.

 

Why use "create patch"?:

You could also create patches in a different way.. But this way is known to work mostly without issues. Armbians current patches are applied before yours get applied so you work 'on top' of armbians patched kernel. So if you've to find a proper name for your patch you might check which patches touch the files you touch with your patch and make sure that your patch gets applied after them. Sometimes it also works the other way around but it's IMO not 'good practices'. 

 

FYI: You may also switch to EXPERT="yes"  in default-config cause you'll build a dev image.  It may be also worth to just build an image without any changes before you start. Just to ensure that the build works as expected on the board. Saves you some headache if your changes don't boot anymore and you realize after its that the build was anyway broken at the moment... 

Link to comment
Share on other sites

I have some problems with the network when working from work because of that damn proxy...

[ o.k. ] Downloading sources
[ o.k. ] Checking git sources [ u-boot h6-dram ]
[ .... ] Checking out
[ o.k. ] Checking git sources [ linux-mainline linux-4.17.y ]
fatal: unable to connect to git.kernel.org:
git.kernel.org[0: 147.75.44.153]: errno=Connection timed out
git.kernel.org[1: 2604:1380:4090:1700::1]: errno=Network is unreachable

[ .... ] Fetching updates

and I have some problems anyway at home...

69.7MiB [ 9.9MiB/s] [=====================================================================================================================================================================] 102%
cp: cannot stat 'COPYING': No such file or directory
[ o.k. ] Compiling next kernel [ 0 ]
[ o.k. ] Compiler version [ aarch64-linux-gnu-gcc 7.2.1 ]
[ o.k. ] Using kernel config file [ config/kernel/linux-sunxi64-next.config ]
make: *** No rule to make target 'olddefconfig'.  Stop.
make: *** No rule to make target 'Image'.  Stop.
[ error ] ERROR in function compile_kernel [ compilation.sh:365 ]
[ error ] Kernel was not built [ @host ]
[ o.k. ] Process terminated

 

Link to comment
Share on other sites

I now can build the image,

dpkg-deb: building package 'linux-source-4.17.11-next-sunxi64' in '/home/vagrant/armbian/.tmp/linux-source-next-sunxi64_5.54_all.deb'.
[ o.k. ] Creating board support package [ orangepioneplus next ]
[ .... ] Fingerprinting
[ o.k. ] Building package [ linux-stretch-root-next-orangepioneplus ]
[ o.k. ] Building desktop package [ armbian-stretch-desktop_5.54_all ]
[ o.k. ] Kernel build done [ @host ]
[ o.k. ] Target directory [ /home/vagrant/armbian/output/debs/ ]
[ o.k. ] File name [ linux-image-next-sunxi64_5.54_arm64.deb ]
[ o.k. ] Runtime [ 61 min ]

but I still have some issues with the branches or kernel version...

dpkg-genchanges: binary-only upload (no source code included)
 dpkg-source --after-build linux-4.17.y
dpkg-buildpackage: binary-only upload (no source included)
dpkg-deb: building package 'linux-source-4.17.11-next-sunxi64' in '/home/vagrant/armbian/.tmp/linux-source-next-sunxi64_5.54_all.deb'.
[ o.k. ] Creating board support package [ orangepioneplus next ]
[ .... ] Fingerprinting
[ o.k. ] Building package [ linux-stretch-root-next-orangepioneplus ]
[ o.k. ] Building desktop package [ armbian-stretch-desktop_5.54_all ]
[ o.k. ] Kernel build done [ @host ]
[ o.k. ] Target directory [ /home/vagrant/armbian/output/debs/ ]
[ o.k. ] File name [ linux-image-next-sunxi64_5.54_arm64.deb ]
[ o.k. ] Runtime [ 15 min ]

I used

LIB_TAG="sunxi-4.18"                    # change to "branchname" to use any branch currently available.

in the config file, and I still get

error: pathspec 'sunxi-4.18' did not match any file(s) known to git.
[...]
dpkg-deb: building package 'linux-source-4.17.11-next-sunxi64' in '/home/vagrant/armbian/.tmp/linux-source-next-sunxi64_5.54_all.deb'.

Anyway, it's building now, which is way better than what I had beforehands...

Link to comment
Share on other sites

There is what chwe said as the Armada 1500 is pretty mewh but I think it does have a zilog audio dsp and could make a good hack for a network speaker/mic image.
I wonder if you could hack an image as embedded soundcards with dsp especially AEC are still far from cheap.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines