As we get closer to shipping production units, we have some Embedded Linux development to complete before we can take advantage of the full capabilities of the devices. If you are an Embedded Linux developer, we are offering free hardware to anyone who can successfully mainline code to the Linux kernel that supports our hardware. A proven track record of submitting code patches or equivalent experience is required.
Not to be overly negative, but should this make me worried? I seem to remember the ship date being set for August when I pre-ordered, and based on some media I can find on the web it was as early as May at one point. Looks like the website now show November.
Have you considered hiring someone to do this development work? Sure, it might cost more than a ‘free’ device, but depending on the amount of development you’re looking for it might be worth more than the $200 you’re essentially offering.
Hi Tamagotchi, welcome to the comunity! I hope your right about the timeline… the up-streaming should not delay the delivery but it would be a pain in the ass if we need a custom kernel…
Hi @BenW sorry because of my curiosity but are you part of the core team of the project?
If so, have you checked about the broken link of the Google Doc? will you get fixed it? also are you planning to staff someone else to develop the Embedded Linux stuff?
I’m definitely not a member of the project or in anyway affiliated with them except for the device that I pre-ordered and hopefully you did to!
On the forum I just try to ask and answer some questions ever now and then to my best knowledge and I hope someone will correct me if my answers are wrong. I have backed some other current and past crowdfunded projects on the interwebs and there usually are 2 constants:
1 there will be a delay and then some more delay’s
2 there will be a chance to ask questions and they wont be answered.
by my reckoning this project is halfway on item 1! as for item nr 2… I think they are performing well above average but tickling them a-bit on the forum will definitely can’t hurt
cant wait for this device, my Librem 5 and the delivery of the Pine phone. it’s the year of the Linux phone
@benw I appreciate your kindly answer and yes, I have already ordered my Pocketpc too and am eagger to know more about its current progress… BTW I have backed up other projects such as Arduboy from Kickstarter’s back on 2019, but Kevin Bates used to provide more frequent updates than popcorn does…
Thanks for the clarifications and I think you are doing really good with your posts!!
We are fully aware of the costs involved in creating custom code for new embedded devices. We are also aware that quite often once that code has been written and submitted for review it is not always immediately accepted into the mainline kernel. There is not always one solution to a problem. While we have our own contract developers, the purpose of this post was to inquire if anyone has experience mainlining software then we would provide free hardware to propose solutions, review and test software. If they are so inclined they may want to write software to support our devices. In some cases, developers we have interacted with have wanted to create solutions in order to submit to mainline kernel because if their solution is accepted they can use the submission to further their career and declined payment.
We want to support a community of developers who use our devices. In our original post, we requested that developers email us and never said that they wouldn’t be paid.
Our ultimate goal is to have fully mainline supported hardware. We won’t be able to achieve that goal with a few contract developers, it takes a big effort with many people involved to get there.
We are doing whatever it takes to ship as soon as we can without sacrificing quality despite the global pandemic which set us and an entire industry back a few months.
We mentioned in another thread that we have begun to separate the batches as of this week. All future orders will ship in November. We still plan on shipping the first batch sooner than that. We will be sending out a newsletter update this upcoming week to update everyone with the current status of Pocket P.C.
Just so I’m clear this thing will be Allwinner A64 based (already mainline) right? We’re just talking about a new devicetree right? Or are there parts (power management, wifi, etc) that aren’t mainline?
I’ve helped port/mainline a few routers for OpenWRT and created a few custom kernels for the original pocketchip, for what it’s worth.
Hi @macromorgan
Thanks for responding. Original Popcorn and Pocket P.C. have a unique power system as they both can run off of battery. We use the GPIO on the USB Power Delivery Controller to control this functionality and on Original Popcorn for the XIO pins. We also added power protection ICs that report fault conditions and over-current events.
We hope to mainline the GPIO control mechanism and kernel drivers for the protection ICs.
We already have working device tree for Original Popcorn and will need assistance testing it before we mainline it.
More details are in the Google Doc. Pocket P.C. is in fact using an A64 processor.
Where are your kernel sources? I can try to build a dkms package for the WiFi drivers. I’m not nearly expert enough to actually mainline the drivers, but I might be able to attempt a dkms at least.
Now that we sent out the DVT2 PCB into production, we have posted the schematic on GitHub.
Please have a look.
We use the TUSB320 for the top left USB-C port. This is a USB Host only port but also the analog audio over USB is on this port. Apparently, the device will automatically enable the analog switch for the audio without being programmed but it would be nice if the system was aware that headphones were connected.
Assuming I’m right (massive IF considering I’m out of my league here) the schematics tell me that the TUSB320 will be exposed as an i2c controlled chip at address 0x47. So it looks like to detect an audio device is present, all you need to do is check register 0x08 at i2c address 0x47 for the bitmask of xxxx10xx and if that’s the case then an audio device is present (01 is reserved, and 11 means debug, so it’s necessary to look at both bits). I’m starting to wonder if this can all be done in devicetree though. It looks like the driver for hd3ss3220 is in the mainline kernel and is the same functionality wise as the tusb320 (at least the datasheets show the i2c registers operate the same between the two chips), so I’m wondering if that driver can just be used.
No not yet. We will soon be working with a software development partner to work on another aspect of the USB-C PD circuitry and will request that they post a repository with the kernel sources as one of their first tasks.
as for item nr 2… I think they are performing well above average 
but tickling them a-bit on the forum will definitely can’t hurt 
