Re: [Arm-netbook] Status update
On Thursday, 24 November 2022 01:55:28 CET Christopher Havel wrote: > > Luke has the talking-stick at this point, and when he's done, I'll have it > back. I will be entirely ignoring the rest of you lot. It's a sad day when > I'm just about the only adult in the room, I find this insulting and condescending. I only initiated this thread to ask for some kind of indication of progress, given that there has been no news for almost two years. I know that some people have given up on this project entirely and are resigned to the idea that they put up non-trivial amounts of money and will have nothing to show for it. Few people contributing to this effort will be so "loaded" that they will not miss that money. I also find Luke's assertions that I have not read his updates insulting and condescending. While I do not have the details of all of them at the front of my mind for instant analysis, I have read every last one of them, right up to the point where they ceased and left everyone wondering what was going on. I have always tried to encourage further progress in this project, even during the period when nothing was evidently happening. And here, the point I made about a lack of communication is entirely pertinent. If you want to see what happens when a crowdfunding campaign "succeeds" and then the updates stop coming, take a look at this one: https://www.indiegogo.com/projects/roundcube-next--2#/ Some of you may even recognise a name or two amongst those involved. While the money in that campaign may have effectively evaporated for all we know, which is not the case here, just look at the updates to see what the effect is when the campaign initiators cease to engage. Are those people not being adults either? I understand the sentiment that having no news to report would make any campaign update rather lacking in substance, but then I have to ask what was stopping anyone issuing updates saying that Luke was still waiting to hear from Chris? There is a middle ground between saying nothing and screaming allegations of criminality at someone: a periodic reminder that no communication has been received would have been enough to communicate the state of the effort. But had such updates been issued, I understand that it would have given a negative impression of the project status. And such negative impressions would tarnish the crowdfunding platform, suggesting that not all is well, that maybe there are widespread problems with project completion on the platform. So, everyone was left with the impression that one of the creators was merely busy doing what the other had asked him to do. People might expect to read angry messages on platforms such as Kickstarter and Indiegogo about a failed campaign, as new projects are promoted underneath with their funding levels ticking upwards: the unhappy customers ejected via the back door as new punters are welcomed in via the front door. But Crowd Supply is supposed to be better than that. Certainly, the emergence of corporate-sponsored campaigns from the likes of AMD and Microchip seems to indicate a level of confidence in the platform. Then again, those corporations might actually be the ones providing the guarantee that the people involved are able to complete their projects, that one of them won't be advocating vigilante justice (but not too severe, of course) against the other, or anything similarly absurd. I presume that Crowd Supply's vision is that when people click on "Back This Project", they expect it to be rather more like "Place Your Order" than a ticket into some kind of unhinged participative theatre performance. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Status update
On Wednesday, 23 November 2022 23:19:01 CET Luke Kenneth Casson Leighton wrote: > > what i am *very* pissed off about and will not tolerate is > people assuming that i can and am going to do everything for > them. this attitude is completely unacceptable. Nobody asked you "to do everything for them". But they probably didn't appreciate the experience of being offered things and then being told "oh, that's your job" along with detailed instructions on how they should be doing it. > you - all of you - have no fucking idea how much my life > has been absolute hell, to bring this campaign to fruition. > subsistence living, moving 15 times, zero holidays, no > health insurance and degraded quality of life due to severe > debilitating illness, for TEN YEARS. Well, I am sincerely sorry that this has brought you hardship. It is not merely hindsight in saying that I could see that you were risking burning yourself out in the way you were pursuing this effort. > and i'm being told i'm a "scammer" and should deliver what > you DEMAND?? fuck off!! I don't demand anything, really, haven't called you a scammer, nor do I believe that you are one, either. But it seems to me that you have spread yourself too thin, quite possibly to maximise the appeal of the campaign. However, none of that was done at our request. I will return to remarks about "community" since you brought that up. In a community, it doesn't all fall to one person to do everything, but in a situation where someone has made themselves the central individual who decides and facilitates everything, it becomes very difficult to distribute the burden because there is no genuine delegation of anything. Why else do you think people have been wanting answers from you personally rather than from a selection of other people? [...] > above. would you write something publicly that resulted in > someone losing their livelihood after they'd given you money > to feed yourself and your family for over two years? > > could you do that to someone? > > have a look at some of the news coming out of Keene, NH. > Chris has been through some pretty rough shit. he doesn't > need to be treated any rougher. I don't follow "the news coming out of Keene, NH", but you still seem to be advocating for the public shaming of the guy, so I might well wonder what the real deal is here, because this really doesn't add up at all. Are we supposed to act as your proxies in this matter as well? I actually wouldn't mind some answers about how this situation was able to get to this rather unhappy point. The money seems to have flowed freely enough, and yet the only recourse being suggested appears to be a form of mob justice, despite the involvement of numerous commercial entities. I can hardly find that credible at all. In fact, I find it all rather distasteful. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Status update
On Tuesday, 22 November 2022 00:01:25 CET Luke Kenneth Casson Leighton wrote: > On Monday, November 21, 2022, Paul Boddie wrote: > > > > OK, when someone is asked by Crowd Supply to contact the creators > > directly, you (as creator #1) are evidently too busy > > no, this is wrong. or, factually misleading. > the 93 Cards are at *Think Penguin's premises*. From a message in March 2021: "hiya Felix, yes doing well, very busy with LibreSOC tape-out is soon. Chris received the other 90 of the Cards, for testing before the remaining 900 are done." People asked again during 2021 and got no further replies. So, yes, we get it: you are busy with your other project. > i have spent 18 months persistently attempting > communication to recover those Cards. Well, I am sorry that you have been persistently attempting communication, but probably one of the things that we have collectively learned in recent years is that without continuous communication with those who have supported a crowdfunding campaign, confidence in that campaign evaporates rapidly. Sadly, campaigns that have suffered from insurmountable setbacks tend to demotivate their creators, diminish their willingness to communicate, and then people start to question the motivations of those creators. I can think of at least one other campaign in which I have had some interest where this has probably happened. Most of us here do not question your motivations, but I know of at least one other project which I follow (but have no direct interest in) where the creator has suffered from numerous setbacks and yet has continually kept their supporters informed, even if the news has been negative. Apart from a couple of provocateurs, most of the people who are involved seem sympathetic to the creator and their situation. I know that you do not like your actions being reviewed and questioned, so let these be some more general observations for posterity, for those willing to take something away from this effort. On such matters, more in a moment. [...] > > Personally, I find it all a bit perplexing. Although I know that you > > brought Mr Waid into the effort with there apparently being some > > particular interest from him in the laptop, I would imagine that most > > people following this project would have expected you to bring the effort > > to completion yourself: > > fuck no, you must be absolutely kidding. you cannot possibly be serious. > > if you genuinely believe that then you cannot possibly have > been reading the updates where i specifically request assistance > and remind everyone systematically that this is and always > has been a COMMUNITY project where it lives and dies on what > people help out with. I wasn't going to bother replying to your message at all until I read this. After all, there is not much to say about some kind of communications failure between two business associates supposedly under the supervision of an online commerce platform (to take the most charitable interpretation and ignoring the exhortations to name and shame or for a manhunt to take place). But where I take great exception is the way you address and otherwise communicate with other people. Six or so years ago, you launched a crowdfunding campaign on the basis of working prototypes of a computer card and depictions of products that were claimed to be in the advanced stages of development. This whole endeavour was framed in terms of your expertise, connections and abilities to go and get things made. When appearances proved to be deceptive, as in the instance of the microdesktop case that had apparently been specially made to illustrate the product, people were told that it was their job to pitch in and design the actual product. So, although there was a portrayal of finished items on offer, when the absence of such finished items was revealed, it suddenly became the job of the "community" to remedy the situation. And when somebody did offer their assistance, they inadvertently transgressed with respect to your personal choice of collaboration tools, and you treated them appallingly. I completely regret not speaking out forcefully about this at the time. A genuine community project should be a democracy and participants should be treated with respect. Instead, you seem to think that a community involves you deciding how things should be done and then telling everyone that you "need" them to do it, as if they are your employees. > examples include writing documentation, wiki pages, developing > linux kernel support, u-boot patches and getting OS Support > up and running. none of which i can possibly be expected to > handle alone. In fact, some of us have attempted to engage with the supposed community aspects of this effort. But again, if the role of the community is merel
Re: [Arm-netbook] Status update
On Monday, 21 November 2022 22:38:48 CET Luke Kenneth Casson Leighton wrote: > paul, apologies, i misread. let me start again. > > On Monday, November 21, 2022, Paul Boddie wrote: > > > One is too busy and directs us to the other who is incommunicative. > > this is the bit that is ambiguous and caused me to misunderstand. > whom is "one" and whom is "the other" when there are *three* > potential parties involved? OK, when someone is asked by Crowd Supply to contact the creators directly, you (as creator #1) are evidently too busy and have directed us to Christopher Waid (as creator #2) who is incommunicative. Personally, I find it all a bit perplexing. Although I know that you brought Mr Waid into the effort with there apparently being some particular interest from him in the laptop, I would imagine that most people following this project would have expected you to bring the effort to completion yourself: your own capabilities and plans being much more of a known quantity than those of someone that few of us have had any dealings with. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Status update
On Monday, 21 November 2022 22:27:48 CET Luke Kenneth Casson Leighton wrote: > > On Mon, Nov 21, 2022 at 9:02 PM Paul Boddie wrote: > > > > I have never communicated with Christopher Waid. > > ah as Thinkpenguin is only 2.5 people, one of whom does not > answer the support email, the probability that you were answered > *by* Christopher Waid (without realising it) is very high. apologies > for not making that clear. I have never communicated with ThinkPenguin, either. My remarks about ThinkPenguin's policy on commerce with the European Union, or lack thereof, was purely based on looking at their Web site. > > I think I made that pretty clear in my previous messages, > > Thinkpenguin is not a sole trader, but there is only Bob (internal-only > technical R&D), Chris (main frontline support), and *one* part-time > helper. > > > so I don't know why you believe otherwise. > > it's a reasonable (but unclear) logical deduction. Well, I haven't communicated with Christopher Waid or ThinkPenguin. > > Maybe quote me the text that isn't clear so that I will know to avoid such > > misunderstandings in the future. For the record, I only ever sent a > > general question to Crowd Supply asking what their policy was on failing > > projects. > > hang on - you sent a message to *Crowdsupply* and got a response from > *Crowdsupply* saying "contact the project creators directly"? > > that being the case, that was the correct response. Yes, I got a message from Crowd Supply after having sent a message to Crowd Supply, although my own message was not about this project specifically, but I know that messages that were about this project have been met with "contact the project creators directly". > > And perhaps, instead of chasing up Mr Waid, with whom I have no > > contractual relationship, Crowd Supply might exercise their expertise in > > ensuring that this project will not fail, given that they are so proud of > > their perfect record and of "carefully vetting and working with our > > projects". > > it's just not their responsibility to do that. > > it turns out that Joshua has in fact gone out of his way to help, at > no obligation. You're saying that Crowd Supply has no obligation to those who used its platform to fund projects. If so, that makes them barely any better than Kickstarter or Indiegogo and rather puts a different light on the various claims made about their capabilities and reputation. Whether they genuinely believe they have no obligation or not, I would recommend caution on their part: people have successfully sought legal recourse for failed crowdfunding efforts in the past, regardless of what the small print claimed. > Joshua has - *PERSONALLY* - offered to carry out the testing of all > Cards, which was what i transferred 0.8 BTC to Chris for him to > do [which Chris appears, as best can be discerned based on current > behaviour and complete lack of responses, to have embezzled]. It is kind of anyone to go beyond any actual obligation they have, but all of this sounds like a dispute between people on the other side of the fence. So, although you have given us a status update in a way, I think that the only way forward is for those involved to resolve the dispute amongst themselves, not to drag in 1000 or so other people to do it for them. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Status update
On Monday, 21 November 2022 19:21:41 CET Luke Kenneth Casson Leighton wrote: > > Paul: it really is very important for you to do the same, > because in over 18 months you are literally the only > person ever to have received a response of any kind. I have never communicated with Christopher Waid. I think I made that pretty clear in my previous messages, so I don't know why you believe otherwise. Maybe quote me the text that isn't clear so that I will know to avoid such misunderstandings in the future. For the record, I only ever sent a general question to Crowd Supply asking what their policy was on failing projects. And perhaps, instead of chasing up Mr Waid, with whom I have no contractual relationship, Crowd Supply might exercise their expertise in ensuring that this project will not fail, given that they are so proud of their perfect record and of "carefully vetting and working with our projects". Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Status update
On Monday, 21 November 2022 16:32:51 CET Luke Kenneth Casson Leighton wrote: > On Monday, November 21, 2022, Paul Boddie wrote: > > > Apparently, asking Crowd Supply about project status tends to elicit a > > response directing inquirers to the project creators. > > Chris *is* one of the project creators. Indeed, which is why I noted that Crowd Supply direct inquirers to you and Chris. Admittedly, you are the only one who seems to read this list and reply to messages. As far as I am concerned, this list is the venue to contact the project creators. > this response is evasion by Chris. > > he is in possession of 95 Cards and he is evading responding > as to their whereabouts. > > you need to *specifically* request him to answer solely and > specifically "where are the 95 Cards sent to him in March 2020". > > please PUBLISH the response, in full, here on the mailing list. > we need a public audit trail. Sorry, but why do I need to chase him up? The people who need to do that are Crowd Supply, instead of claiming that every project is either a success or a success still waiting to happen, which was effectively their response to me when I asked them what they do when projects are failing. Or maybe it is Mouser who have to get involved since they acquired Crowd Supply. > > One is too busy and directs us to the other who is incommunicative. > > wrong. Well, that's what you've been doing. See above. > i have been refraining from speaking publicly in order to > protect Chris, who sponsored me with USD 50,000 of his company's > money. > > now that *you* have raised this publicly (not me) i can respond > and correct mistakes that you make above. > > over the past 2 years over 40 email messages have been sent, > even Joshua Lifton has requested a phone call to be returned. > multiple people have raised tickets on their support system. > > in 20+ months we have not received ONE response. > > you are literally the first person to have even confirmed that > there is even two-way communication (even though it is evasion) That is two-way communication with Crowd Supply not Chris. As in: people ask Crowd Supply about the status of this project and Crowd Supply tell the inquirer to talk to you and Chris about it. So, people post to this list and get told to ask Chris where the cards are. It is as if Crowd Supply had nothing to do with taking people's money. > can you please try again, this time VERY SPECIFICALLY and ONLY > asking "where are the 95 Cards sent to your premises, Mar 2020" > nothing more. it is critically important NOT to ask anything else > > the next logical followup question can then be sent but only > AFTER that first question has been answered. > > if you are unsuccessful (ignored like everyone else) then at that > point i will have no other alternative but to publish the > Crowdsupply Update that i have INTENTIONALLY not been publishing > which informs 2,500 people that, effectively, Chris, despite > being a project creator and financial sponsor, is in possession > of 95 Production Cards that are legally the property of 95 of the > Backers, and that he is refusing to say where they are currently > located. the reasons why i have refrained from publishing such > an update should be pretty damn obvious. We all know that he has 95 cards because you posted an update saying so two years ago. Sending a mail to him that he probably will not respond to isn't going to help. Besides, the backers have an agreement with Crowd Supply, who in turn have agreements with you and Chris, and so it is up to Crowd Supply to sort this out. So, maybe it might be more productive for people to ask Crowd Supply what they are doing about this situation. If everyone gets fobbed off with the success- in-waiting, "contact the creators" canned response, maybe it is worth escalating to a more senior level in Mouser. Of course, Mouser might know full well what they bought and don't care, either. There are other projects on Crowd Supply that supposedly delivered, but where the community ended up picking up the pieces (thinking of the GnuBee devices that receive support via a Google Group). Claims such as "every project that has ever received funds through Crowd Supply has delivered to their backers (or is on track to do so)" [*] look pretty flimsy from the perspective of quite a few backers, I would say. From my own perspective, one of the most disappointing aspects of all of this is that an opportunity has been squandered. Looking back six or seven years ago, there was a lot of enthusiasm for a project that had the potential to really change things, but all that enthusiasm seems to have evaporated along with any kind of meaningful discourse.
Re: [Arm-netbook] Status update
On Tuesday, 21 December 2021 09:27:21 CET Felix wrote: > As alway, hope you are doing well, but I can't avoid to ask :P Any follow > up? Coming up on a year after this last message and two years after the last Crowd Supply update, I wonder if there is any news at all. I also notice that ThinkPenguin no longer does business with anyone based in Europe supposedly due to GDPR legislation. Apparently, asking Crowd Supply about project status tends to elicit a response directing inquirers to the project creators. One is too busy and directs us to the other who is incommunicative. It all seems like a lost opportunity, really. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] Various projects somewhat related to the EOMA initiative
Hello, There doesn't seem to be much EOMA68 news any more, but I was reminded of some of the ideas brought up in the context of the initiative by a few products or projects that came to my attention recently. One interesting product is the Mixtile Blade 3 which just about met its funding goal on Crowd Supply: https://www.crowdsupply.com/mixtile-limited/mixtile-blade-3 The interesting idea that this implements is the ability to daisy-chain the boards using PCI Express, and there is also a cluster box that provides a switched PCI Express bus. In the context of EOMA68 or similar efforts there was this idea: https://rhombus-tech.net/community_ideas/cluster_server/ The Mixtile Blade 3 uses the Rockchip RK3588, which has also been introduced in products from PINE64: https://www.pine64.org/2022/03/15/march-update-introducing-the-quartzpro64/ Another notable development from PINE64 is an impending introduction of a RISC-V-based product (these having started to emerge from various other places, often based on the Allwinner D1): https://www.pine64.org/2022/06/28/june-update-who-likes-risc-v/ From the choice of GPU technology, it seems like this might be the basis of the SoC being used: https://www.imaginationtech.com/news/imagination-and-andes-jointly-validate-gpu-with-risc-v-cpu-ip/ ImgTec have now started to work on Free Software drivers for various products, as I understand it, although I doubt that older products will be supported, and the firmware will most likely remain non-free. I would love to be proved wrong, though. It's a shame ImgTec didn't have the same level of ambition and pragmatism when they owned MIPS. On that topic, David posted news of an interesting project on the Tinkerphones mailing list: https://lists.goldelico.com/pipermail/community/2022-June/002206.html To summarise, someone has been pursuing the development of a featurephone using the Ingenic X1000E: http://www.ingenic.com.cn/en/?product/id/9.html That SoC has a relatively small amount of on-board RAM (64MB, which counts as small these days), but it could run a very modest Linux distribution. Unlike earlier Ingenic SoCs, but like the JZ4780, it has a hardware floating-point arithmetic unit. And it also has the different on-chip peripherals for easy integration into portable devices. Relevant EOMA-related ideas include the following: https://rhombus-tech.net/community_ideas/games_console/ https://rhombus-tech.net/community_ideas/hybrid_phone/ https://rhombus-tech.net/community_ideas/pocket_qwerty_computer/ https://rhombus-tech.net/community_ideas/zipit_refit/ I haven't spent or pledged any money towards any of these initiatives, but for anyone wondering whether some of the EOMA-related ideas were ever taken up in some sense, I thought they might be of interest. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Site updates (was Re: Schematic and PCB layout CAD files)
On Sunday, 30 January 2022 23:38:04 CET Luke Kenneth Casson Leighton wrote: > On Sun, Jan 30, 2022 at 10:29 PM Philip Hands wrote: > > If you notice any oddities, please mention them, as I may have missed > > something in the move. > > brilliant, thanks for sorting this Phil, really appreciated you're keeping > things running. Thanks once again to Phil! Did you ever hear anything more from Chris about the boards that were sent to him? Or did you get an opportunity to look at the ones that were sent your way? https://www.crowdsupply.com/eoma68/micro-desktop/updates/100-a20-computer-cards-ready-for-testing Obviously, Pablo did look at one board back in June/July 2020, prior to the above update, but he didn't get very far, unfortunately. It seems that of the 100 cards that were manufactured, Chris ended up with at least 90 of them: http://lists.phcomp.co.uk/pipermail/arm-netbook/2021-March/016421.html He was apparently busy getting a wireless networking dongle RYF certified in June of last year: http://lists.phcomp.co.uk/pipermail/arm-netbook/2021-June/016427.html So, I wonder if anything happened since then. Paul P.S. While I wasn't looking, Intel followed on from its Compute Card... https://www.intel.com/content/dam/www/public/us/en/documents/guides/compute-card-brief.pdf ...with a range of NUC Elements products: https://www.intel.com/content/www/us/en/products/details/nuc/elements.html https://www.intel.com/content/dam/www/public/us/en/documents/brochures/nuc-element-u-series-brochure.pdf They even have a laptop product using the NUC Compute Element: https://www.intel.com/content/dam/www/central-libraries/us/en/documents/intel-nuc-p14e-laptop-product-brief.pdf The Compute Element being a more conservative evolution of the Compute Card, I suppose. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] Site updates (was Re: Schematic and PCB layout CAD files)
On Monday, 17 June 2019 13:15:18 CET Paul Boddie wrote: > On Monday 17. June 2019 08.40.22 Luke Kenneth Casson Leighton wrote: > > > > repo that i started 6 years ago: > > http://git.rhombus-tech.net/?p=eoma.git;a=summary > > I'll send you that, trying to remember the preferred form of the exported > key this time. ;-) Currently, the above repository is only available securely via the following address: https://git.hands.com/?p=eoma.git;a=summary Meanwhile, I updated the wiki page describing PCMCIA/CardBus component details: https://rhombus-tech.net/pcmcia_sources/ (Thanks for Phil for fixing the wiki!) One interesting thing that came up, given the conversation that was had over two years ago, was this product and corresponding brochure about PC Card casings and tooling: https://www.ittcannon.com/products/starcard-snappy/ https://www.ittcannon.com/Core/medialibrary/ITTCannon/website/Literature/ Catalogs-Brochures/PC_Card_Final.pdf?ext=.pdf On page 37 of the brochure, there are some pictures of the tools that would be used to facilitate assembly and disassembly. I seem to remember complaints about assembly, and I found some remarks on this list from back in 2017... "the litkconn P/N 68F casework basically is a "total disassmbly" job. it's a pain in the ass and takes several minutes." http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-May/013788.html In the crowdfunding updates, the awkwardness of assembly is also mentioned here: "Additionally, I am considering sending out the PCB and casework unassembled, with full and precise assembly instructions for backers to follow. It’s not hard: it just needs to be done very carefully. This will save a considerable amount of time and money, as the cards casework will need hand-assembly (quantity 1,000)." https://www.crowdsupply.com/eoma68/micro-desktop/updates/pcbs-and-components-have-been-ordered So, I guess that with the above product family, one would want to invest in that tooling as well as the actual products, just to do things as the manufacturer intended. It is an interesting insight into part of the process that goes into making the product. I also had a bit more luck searching for product documentation today and also found this: https://media.digikey.com/pdf/Data%20Sheets/Hirose%20PDFs/NX1.pdf The product itself is about to be discontinued, but there's an interesting pictorial assembly guide including a picture of an assembly jig. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] links at rhombus-tech recent changes -> 404 not found
On Tuesday, 18 January 2022 21:56:31 CET Pablo Rath wrote: > Hello, > It seems to me that the recent changes listed here: > http://rhombus-tech.net/recentchanges/ do no longer work correctly (broken > links). Yes, it has been like this for a while, I think. You can still get to see the content if you go in via the front page, and the site map provides a way to navigate to any modified pages, although yours were the last modifications some time ago. I wonder what the future is for this initiative. We passed the fifth anniversary of the crowdfunding campaign last year, and it seems that despite our enthusiasm and support, most of us were never able to become full participants in anything that could have had a greater impact. So, in the event that we end up with nothing to show for our interest, it is hard to see what, if anything, we are left to continue with as its legacy. I feel that it is a sad but all too familiar situation, really. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Status update
On Monday, 29 March 2021 12:13:08 CEST Luke Kenneth Casson Leighton wrote: > On Monday, March 29, 2021, Felix wrote: > > Hey Luke, hope you and your and fam are doing well ;) We haven't heard > > anything from you in a while, and would be great to have an status update > > or something similar :P > > hiya Felix, yes doing well, very busy with LibreSOC tape-out is soon. > > Chris received the other 90 of the Cards, for testing before the remaining > 900 are done. We'll certainly look forward to news of how well the testing went. :-) Meanwhile, browsing old computer magazines, I came across this: "This may well be the smallest Windows-class PC in the world. The Cardio 386, from S-MOS, is the size of a type 3 PCMCIA card, and is now available in a 486 configuration. The i/o pins are on the long edge, unlike a normal PC card. The cards are designed for embedded applications." "Smallest ever PC fits on a card" Personal Computer World, July 1995 https://archive.org/details/PersonalComputerWorldMagazine/ PCW%20199507%20July%20Created%20From%20PCW%20Cover%20CD/page/n8/mode/1up I guess that since PCMCIA cards are effectively credit card size, the PCMCIA connection is tenuous, but perhaps there was some manufacturing capability available for making something similar to a PCMCIA card that led them in that direction. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Pluton: M$ firmware and TPM to be built into your processor...
On Saturday, 12 December 2020 17:11:28 CET David Niklas wrote: > Hi, > It has been a while since I posted. Today I have bad news. Apparently, M$ > has been working with AMD, Intel, and Qualcomm to place a new type of > TPM into their CPUs, APUs, and SoCs. It's already inside of the new XBox > processors. > It runs firmware which is, according to M$, produced by them. > > Here's an official link, and a tech site link for those of you who don't > want to visit M$'s site. > > https://www.microsoft.com/security/blog/2020/11/17/meet-the-microsoft-pluton > -processor-the-security-chip-designed-for-the-future-of-windows-pcs/ > > https://www.anandtech.com/show/16269/microsoft-pluton-hardware-security-comi > ng-to-our-cpus-amd-intel-qualcomm > > I've done some research googling, but at this stage the data on what sort > of access this new processor has and what it can do is anyones best guess. > > It sounds like the firmware might have unrestricted Internet access: "One > of the other major security problems solved by Pluton is keeping the > system firmware up to date across the entire PC ecosystem." > > I hope I'm panicking unnecessarily... It's just Microsoft being Microsoft, I imagine. Ignore all the people who claim "Microsoft has changed" because "Microsoft likes open source" plus all the people who even go as far as to deny that Microsoft ever did bad stuff in the past [*]. I also imagine that Microsoft doesn't like the look of things like this: https://opentitan.org/ Which, having looked at it only yesterday, was the first thing I was reminded of. Paul [*] Bad stuff as in demanding licensing fees for each Intel processor shipped regardless of what the processor or system was running, coercing computer manufacturers into exclusive agreements that forbade them from supplying other operating systems, incorporating other people's software into their operating system without permission, and so on. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] Somewhat off-topic updates about Ryzen, PolarFire, HiFive and Elbrus (was Re: Current status)
On Tuesday, 21 July 2020 23:36:28 CET Paul Boddie wrote: > > So, upcoming AMD products could be decent, but I would be wary about > stability for a while after their release. Following the Linux kernel bug > tracker can be informative: > > https://bugzilla.kernel.org/ > > Searching for "amdgpu" is probably what you want to do. For quite some time, > people were having problems with the 3200G, and that made me worried about > the 3400G, but it seems that even within product families there might be > some parts that are better supported than others. Since then, my Ryzen system has worked better than my work laptop that has an Intel Core 7 CPU with integrated graphics that aren't used because there is also an Nvidia video card which occasionally does some very weird display memory "picture interference" thing. (I thought that might be the HDMI output playing up, having had to mess with Synopsys HDMI on the Ingenic JZ4780 and seeing the many weird things that have to be set up to enable the peripheral, but is probably some dodgy interaction between the binary firmware blobs and the baroque "Linux plus GNOME plus whatever is in-between" graphics stack.) The only weird thing I have seen with the Ryzen 3400G is this kind of message (with dmesg prefixes removed): Corrected error, no action required. CPU:7 (17:18:1) MC3_STATUS[-|CE|MiscV|-|-|-|SyndV|-|-|-]: 0x98200150 IPID: 0x000300b0, Syndrome: 0x2a000503 Decode Unit Ext. Error Code: 0, Micro-op cache tag parity error. cache level: RESV, tx: INSN, mem-tx: IRD I have no idea whether this is really bad or not. [...] > "A low-cost dev kit for Microchip's PolarFire SoC, a low-power FPGA > integrated with a hardened quad core 64-bit RISC-V microprocessor > subsystem" > > https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit > > That is from the Microsemi part of Microchip's business, however, meaning > that it is another recent acquisition: Microchip presumably buying in new > technology to remain competitive. Since that campaign, they've started another: "PolarBerry is a System-on-Module (SoM) SBC utilizing the Microchip PolarFire SoC, which integrates a low-power FPGA with a highly secure, four-application- core, 64-bit, Linux-capable RISC-V subsystem." https://www.crowdsupply.com/sundance-dsp/polarberry They go on about how it has "defense-level security". And again, it relies on Microsemi's proprietary toolchain. Meanwhile, this one slipped below the radar given that SiFive already crowdfunded a similar kind of board successfully a while back: "Powered by the SiFive Freedom U740 RISC-V SoC and targeted for creating RISC- V applications, the platform features 8 GB of 64-bit DDR4 memory operating at 2400 MT/s, high-speed interconnects with PCIe Gen 3 x8 operating at 7.8 GB/s, Gigabit Ethernet, and USB 3.2 Gen 1." https://www.crowdsupply.com/sifive/hifive-unmatched However, I think this one might appeal to Luke a bit more: "Elbrus is a mini-ITX security-oriented motherboard for mobile/embedded usage based on the MCST Elbrus-8CB 8-core @ 1.5 GHz VLIW CPU on ELBRUS architecture." https://www.crowdsupply.com/sra-centr8/icepeakitx-elbrus-8cb In case OpenPOWER isn't exciting enough. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] EOMA68-A20, MD 1.7 severe Power Problems
On Sunday, 26 July 2020 11:54:27 CEST Luke Kenneth Casson Leighton wrote: > > you *need* a stable supply to do that (1.5 preferably 2.0 A) designed > *specifically* for providing USB power. UNDER NO CIRCUMSTANCES plug the 12v > PSU into the USB socket. and DO NOT use an "off-the-shelf generic 5.0v wall > wart". use something SPECIFICALLY designed for providing USB power because > it is (a) stable and (b) current-limited. All this talk of regulated power supplies reminded me of this product which takes a range of inputs via the barrel jack socket: https://proto-pic.co.uk/product/sparkfun-prt-13032-breadboard-power-supply-stick-5v-3-3v/ Meanwhile, the CI20 can be powered from a USB port and employs a barrel jack socket to accept that power. According to the hardware reference it is actually "a 5V 4mm (shield) x 1.7mm (pin) center positive connector ... identical to that of the original Sony PSP": https://www.elinux.org/CI20_Hardware#Power I'm not sure if either of these things are relevant here, though. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] DDR3 RAM Design Rules and Techniques
Hello, One thing that just came up in another forum is the matter of routing PCB tracks for DDR3 RAM, and this is probably a topic that was encountered by both the Pyra... https://pyra-handheld.com/boards/threads/analyzing-4gb-ram.81687/ https://pyra-handheld.com/boards/threads/is-there-really-a-light-at-the-end-of-the-journey.83007/ ...and the EOMA68 initiatives. Is there any pertinent documentation describing this exercise in the EOMA68 board design process? Searching for DDR3 on the Rhombus Tech site [*] indicates that some boards were done with guidance (at some level) from the vendors: http://rhombus-tech.net/ingenic/jz4775/news/11jul2014_routing_completed/ http://rhombus-tech.net/allwinner/a31/news/ Previous discussions of KiCad and Olimex boards, which presumably involved DDR3 routing, can be found via this message: http://lists.phcomp.co.uk/pipermail/arm-netbook/2019-May/016062.html I ask about this in the context of someone who just made design files available for a board using the Ingenic JZ4780 that they had been working on. Those files are here: https://gitlab.com/igagis/cranberrypi Paul [*] http://rhombus-tech.net/cgi-bin/rhombus/ikiwiki.cgi?P=DDR3 ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Current not intel Laptop/UMPC/Handheld Options
On Saturday, 25 July 2020 14:29:45 CEST Luke Kenneth Casson Leighton wrote: > https://www.pine64.org/2020/07/24/all-about-the-pinetab-update/ > > lots of things still going on with Pine64. The Pyra is still edging its way towards completion, too: https://pyra-handheld.com/boards/forums/pyra-news.250/ Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Tuesday, 21 July 2020 23:25:12 CEST Luke Kenneth Casson Leighton wrote:
> On Tue, Jul 21, 2020 at 9:57 PM Paul Boddie wrote:
> > OK, so the housing DT will contain the following for a VGA port...
>
> paul: quite late, here, more tomorrow. summary strategy:
>
> * look at rbpi "hats" and how dtb overlays are done
> * copy that
> * rename rbpi "hat" overlay pins 0 to M to "eoma68 pins 1 to 68"
It would be useful to know where all these "hats" are defined. I found the
following:
https://github.com/raspberrypi/linux/tree/rpi-5.4.y/arch/arm/boot/dts/overlays
A common theme seems to involve augmenting the gpio node from the chipset DT
as follows (in the nicer syntax):
&gpio {
some_pins: some_pins {
brcm,pins = <...>;
...
};
};
Then, various other nodes are augmented, also with device-specific details.
> in theory that should be pretty much the entire job, bar removing all
> multiplexed options other than the 1 specialist function and the GPIO
> option. where in rbpi base "hat" interface there would be up to 4
> multiplexed options per pin (one of which will be GPIO), that must be
> restricted to "GPIO" and "EOMA68 function", per pin.
>
> that really should be all.
Sorry, I just don't see how the overlays I found do this generically. All the
node referencing is device-specific, although there is some aliasing done in
"the firmware" for a limited number of nodes.
That works just fine with things like Raspberry Pi, but what we really need to
see is what a device tree overlay looks like for a product that is used on
multiple devices without needing to be customised for each one, if such an
overlay exists.
The only thing I've found that seems to do pin aliasing is this:
https://beagleboard.org/blog/2018-01-17-building-a-device-tree-overlay-for-your-new-pocketcape-design
Even then, there is some pretty liberal usage of what appear to be device-
specific node references alongside the pin aliases, but I guess it is a start.
Paul
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Monday, 20 July 2020 00:56:19 CEST Paul Boddie wrote: > > But there is also this: > > https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html Which had been removed when I just checked. > Oddly, the syntax in the above is far simpler than various other guides to > overlays, making me wonder whether they are describing different kinds of > overlays. For example (see part 2): > > https://www.raspberrypi.org/documentation/configuration/device-tree.md This is explained here: https://source.android.com/devices/architecture/dto/syntax Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Current status
On Tuesday, 21 July 2020 03:02:14 CEST David Niklas wrote: > On Monday, July 20, 2020, George Sokolsky wrote: > > > How people are moving forward with their computing needs? [...] > The RK3399 is a real winner of a processor, being sold on a lot of SBCs > for as little as $50. It's getting better and better SW support as devs > reverse engineer it's internal mali GPU and associated interconnect and > power controls. These Rockchip SoCs reportedly run pretty hot, don't they? That said, I noticed that the Raspberry Pi 4 has fan accessories available for it. So much for keeping up the pretense of Cambridge continuity with Acorn Computers unless the ultimate aim is to replicate products like the (unreleased) Acorn Business Computer with, apparently, a very noisy fan. > AMDs laptop offerings are also very temping and I'm recommending them to > normal people who want to purchase a laptop. Linux support is in great > shape for the 4000 series AFAIK[1]. Supposedly, AMD is coming out with an > APU even more amazing before the end of the year. I just upgraded my system (after fifteen years!) to one using a Ryzen 3400G APU (if they still call them that). However, Linux kernel compatibility is such that I'm running a kernel from the Debian backports repository because system reliability with these parts was a long time coming. And you have to use proprietary firmware blobs because all these companies need to have their secret sauce. So, upcoming AMD products could be decent, but I would be wary about stability for a while after their release. Following the Linux kernel bug tracker can be informative: https://bugzilla.kernel.org/ Searching for "amdgpu" is probably what you want to do. For quite some time, people were having problems with the 3200G, and that made me worried about the 3400G, but it seems that even within product families there might be some parts that are better supported than others. [...] > MIPS was looking promising until you read it's "open source" license. Since I've experimented with MIPS things for a while, I have to say that the custodianship of MIPS has been generally disappointing. First of all, Imagination Technologies seemed to want to either compete head- on with ARM by having a processor architecture and graphics technologies, or (when their Apple partnership collapsed) to broaden their offerings and to use MIPS as a vehicle into IoT and such. At that time, they had their academic programme to try and get people to experiment with the architecture. But RISC- V was already on the runway at that point, so it was too little too late. Then, when ImgTec was acquired, MIPS got acquired and quickly passed on to Wave Technologies (presumably making some people some quick and easy money). But the MIPS business seems to be in maintenance mode, at least if you look at their Web assets. And, of course, all the MIPS Creator stuff just fell off the desk. Any announcements about opening the architecture might well be perceived as just making some noise and keeping existing licensees on board. Indeed, casually following Microchip over the last couple of years or so, I saw it said that Microchip's acquisition of Atmel would mean that Microchip would probably double down on ARM and abandon new MIPS product development. Various pundits/punters claimed that Microchip wouldn't look twice at RISC-V. But then I saw this: "A low-cost dev kit for Microchip's PolarFire SoC, a low-power FPGA integrated with a hardened quad core 64-bit RISC-V microprocessor subsystem" https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit That is from the Microsemi part of Microchip's business, however, meaning that it is another recent acquisition: Microchip presumably buying in new technology to remain competitive. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Tuesday, 21 July 2020 00:49:48 CEST Luke Kenneth Casson Leighton wrote:
>
> i would prefer a level of indirection that names the EOMA68 pins by
> numbers, these numbers to be nothing to do with the function
>
> the reason being that exactly like pinctrl all EOMA68 Interface pins
> (except USB) can be GPIO.
>
> then, just like pinctrl, the next layer drops overlays onto those 68 pins
> to provide LCD ... *if the Housing Manufacturer wants them to be LCD*.
OK, so the housing DT will contain the following for a VGA port...
An actual connector definition for the benefit of various mechanisms. The
reason why I keep mentioning this is because the DRM mechanisms seem to depend
on it: there needs to be some kind of sink for the signal, and it's usually
some kind of connector. But this is arguably the easy part.
Something that indicates the EOMA pin requirements to supply that connector.
Normally, pin usage gets written on a specialisation of a device peripheral.
For example, for the Ben NanoNote:
&lcd {
pinctrl-names = "default";
pinctrl-0 = <&pins_lcd>;
port {
panel_output: endpoint {
remote-endpoint = <&panel_input>;
};
};
};
But in the EOMA68 universe, we don't want to override a specific peripheral
(&lcd here refers to the LCD controller on the JZ4720), nor do we want to
indicate pins that are SoC-specific.
So, we can define some kind of mapping for pins in the computer card DT, just
as you do here...
> these examples shows that it is therefore quite important to not drop
> functions directly onto pins but to have that "redirection" layer:
>
> &pio {
> eoma68_pin0: {
> pins = "PD0"
> function = "eoma68-pin0";
> };
> eoma68_pin1: {
> pins = "PE5"
> function = "eoma68-pin1";
> };
> .
> .
> };
>
> and *then* have an LCD dtb overlay (one 24, one 18, one 16 and one 15)
> which refers to the pins by their *EOMA68* name
>
> NOT the pinctrl name (e.g. from sunxi a20 dts) which is SoC specific.
But what I am missing is the construct by which you might apply the pin
reservations, unless you are merely making aliases for platform-specific pin
names within pinctrl and then using those in places where pinctrl attributes
are used.
Specifically, what I wonder about is how the equivalent of the <&pins_lcd>
gets applied at the SoC level given some kind of (platform-neutral) pin
reservation in the housing DT.
Sorry if this is obvious, but without concrete DT syntax for the configuration
throughout the different layers, I cannot see exactly how this would be done.
Paul
P.S. But recent experiences may be colouring my judgement here, having been
trying to shake the box of existing drivers and DT fragments to try and
persuade my CI20 to produce HDMI output, so far unsuccessfully. And yet,
practically the same code produces a picture just fine when ported to L4Re,
without all the distractions of driver frameworks and device trees (and the
DRM stack testing modes over and over and over again).
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Monday, 20 July 2020 01:38:34 CEST Luke Kenneth Casson Leighton wrote:
> On Sunday, July 19, 2020, Paul Boddie wrote:
> >
> > So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or
> > enables various peripherals,
>
> so, some peripherals like the otg, mmc0, hdmi and also interestingly the 2
> USB ports despite being on the EOMA68 connector, these would all go in the
> same level as cubietruck i.e. machine level.
Right.
> > and then - at run-time - each housing's DT which
> > activates the peripherals that were exposed but not enabled.
>
> yes. the 2nd sdmmc (mmc3 i think), the i2c, uart, spi, rgbttl and eint,
> all those would go into "dynamic pointer default NULL" set.
Yes, and I guess that the rgbttl peripheral would be the thing providing the
VGA output, so there would potentially be something there with a device tree
"port" that can connect to a corresponding port in the housing's DT...
[...]
> > For example, how would a VGA output port be defined?
>
> that ie precisely what the dynamic thing does: it's specified in the
> dynamic fragment.
>
> the dynamic fragment contains the names eoma68-pin1 to 68 and says that
> when eoma68-pin33 is connected it shall be given the purpose "RGBTTL HSYNC".
How does this correspond to the pinctrl groups that one usually sees? In the
sun7i-a20.dtsi file there is a pinctrl node with lots of groups defined.
Would there be some kind of "logical" pin group like this...?
&pio {
eoma68_lcd_pins: eoma68-lcd-pins {
/* assuming that LCD0 pins are routed via the connector's LCD
pins */
pins = "PD0", "PD1", ... ;
function = "eoma68-lcd";
};
};
(Here, I used the sun7i-a20-olinuxino-micro.dts file to provide some hints. In
the Ingenic DT files, by the way, you don't see so much of this any more
because the groups are actually defined in the driver itself.)
And then, there would be something using this pin group. Here, I have to guess
which phandle to use amongst other things. Since tcon0 is an A20 thing, this
would be in the computer card DT, with other card DTs providing their own
necessary recipes:
&tcon0 {
ports {
tcon0_lcd_out: port@2 {
...
tcon0_out_lcd: endpoint@2 {
...
remote-endpoint = <&vga_connector_in>;
};
};
};
};
Here, I'm missing the mechanism by which the pin group gets selected. Some
kind of coordination with the driver would be needed, I guess. Otherwise, it
wouldn't know which mode to use so as to produce output on the LCD0 pins.
> > Normally, there would be a connector node with an endpoint, so something
> > like this in the housing DT, perhaps:
> >
> > vga0: connector@0 {
> >
> > compatible = "vga-connector";
> > label = "vga";
> >
> > port {
> >
> > vga_connector_in: endpoint {
> >
> > remote-endpoint = <&vga_out>;
> >
> > };
> >
> > };
> >
> > };
>
> this definition would go in the *Housing* dtb fragment.
Yes, in the housing DT.
> the vga_out is defined to contain *dynamic* connections which link HSYNC
> to eoma68-pin33 (whatever).
>
> only when the "dynamic merge" kernel syscall is made will the substitutions
> occur, *including* the (now new) definition of vga0 events will then fire,
> the associated rgbttl.ko gets loaded, and (eventually) /dev/fb0 appears.
Yes, I'm just missing some idea of the actual device tree plumbing. But then I
don't think I'm particularly good at figuring out Linux device drivers and
device trees.
Paul
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Monday, 20 July 2020 00:20:58 CEST Luke Kenneth Casson Leighton wrote:
> On Sunday, July 19, 2020, Paul Boddie wrote:
> >
> > The principal differences appear to be as follows:
> >
> > The EOMA68-A20 DT doesn't have HDMI nodes whereas the Cubieboard DTs have
> > nodes for HDMI connectors and the usual peripheral nodes (&hdmi,
> > &hdmi_out).
> > Given the effort that went into putting micro-HDMI on the computer card, I
> > guess there might be some definitions to add here.
>
> yes.
OK, I'll add them.
> > The EOMA68-A20 DT has a special pinctrl node for mmc3_cd_pin (MMC3 card
> > detect, I guess). There are also LED pin differences, but I think these
> > are explained by pin definitions migrating to the sun7i-a20.dtsi file.
>
> ah. the updates to the hardware it is now mmc0
OK.
> > Some I2C definitions seem to be different in the Cubieboard DTs, but that
> > could also be due to pin definitions migrating to the sun7i-a20.dtsi file.
> >
> > The Cubieboard DTs enable the display engine (&de) and power
> > (&ac_power_supply).
> >
> > There are some changes to the Ethernet node (&gmac). (I didn't think
> > Ethernet was exposed by the computer cards when the specification was
> > updated after the first round of cards being made.)
>
> no it's gone
OK.
> > The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT has
> > a node ®_usb0_vbus that the other DTs do not have.
> >
> > So, it seems possible that an updated DT file would be a minor variation
> > on the Cubieboard 2 file.
>
> pretty much.
I'll have to look at the OTG thing to figure out its significance.
[...]
> > Indeed. I guess the computer card device tree sits at a level between the
> > chipset device tree and what would normally be the machine device tree.
>
> if i understand you correctly: not quite.
>
> the closest equivalent is 96boards and arduino shield dtbs.
>
> here the 96boards dtb file *is* the machine level.
>
> the pin header dtb locations however are NOT FILLED IN.
>
> they instead have special references - pointers. each pointer is named
> (given the pin number) but is set to NULL by default.
>
> at RUNTIME - not "device tree compile time" - at **RUNTIME** - a special
> command is run with a "shield dtb fragment" that directly and DYNAMICALLY
> replaces those named parameter pointers with the reference to the dtb
> fragment.
I understood the run-time aspect, but I thought that the specialisation would
be a bit like the way something like the Cubieboard DT specialises the A20 DT.
So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or
enables various peripherals, and then - at run-time - each housing's DT which
activates the peripherals that were exposed but not enabled.
I guess the challenge is to describe the peripherals in a neutral way in the
housing's DT so as not to taint them with the specifics of a particular
computer card DT.
For example, how would a VGA output port be defined? Normally, there would be
a connector node with an endpoint, so something like this in the housing DT,
perhaps:
vga0: connector@0 {
compatible = "vga-connector";
label = "vga";
port {
vga_connector_in: endpoint {
remote-endpoint = <&vga_out>;
};
};
};
And I guess there could be a corresponding endpoint in the computer card DT
that makes VGA output a possibility. There might also have to be some kind of
ddc-i2c-bus attribute referencing a node elsewhere, too.
Sorry if this was discussed on the list or documented elsewhere!
[...]
> > I guess I should ask whether such support made it into either of them.
>
> investigating 96boards and how their shields are supported should give some
> leads, there.
This was the first thing I found:
https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/
guides/dt-overlays.md.html
But there is also this:
https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html
Oddly, the syntax in the above is far simpler than various other guides to
overlays, making me wonder whether they are describing different kinds of
overlays. For example (see part 2):
https://www.raspberrypi.org/documentation/configuration/device-tree.md
> the absolute last thing needed however is hardcoded static compiled dtb,
> one for eoma68-a20-microdesktop, one for laptop, then one for
> eoma68-rk3288-microdesktop
>
> it would be utterly disastrous for EOMA68 to consider the base dtb file to
> be a "chipset" level tree.
>
> it has to be a *board* level (machine level)
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Sunday, 19 July 2020 22:43:59 CEST Luke Kenneth Casson Leighton wrote: > On Sun, Jul 19, 2020 at 9:35 PM Paul Boddie wrote: > > > > It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very similar > > to that from the Cubietruck 2. > > that sounds about right. possibly the original cubieboard. OK. From what I can see, there are strong similarities between the above file and both sun4i-a10-cubieboard.dts and sun7i-a20-cubieboard2.dts. (I got mixed up and wrote Cubietruck 2 above.) The principal differences appear to be as follows: The EOMA68-A20 DT doesn't have HDMI nodes whereas the Cubieboard DTs have nodes for HDMI connectors and the usual peripheral nodes (&hdmi, &hdmi_out). Given the effort that went into putting micro-HDMI on the computer card, I guess there might be some definitions to add here. The EOMA68-A20 DT has a special pinctrl node for mmc3_cd_pin (MMC3 card detect, I guess). There are also LED pin differences, but I think these are explained by pin definitions migrating to the sun7i-a20.dtsi file. Some I2C definitions seem to be different in the Cubieboard DTs, but that could also be due to pin definitions migrating to the sun7i-a20.dtsi file. The Cubieboard DTs enable the display engine (&de) and power (&ac_power_supply). There are some changes to the Ethernet node (&gmac). (I didn't think Ethernet was exposed by the computer cards when the specification was updated after the first round of cards being made.) The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT has a node ®_usb0_vbus that the other DTs do not have. So, it seems possible that an updated DT file would be a minor variation on the Cubieboard 2 file. > > Were the differences documented and are there any > > schematics to provide any necessary insight when updating the device tree? > > there's PDFs somewhere... http://hands.com/~lkcl/eoma/ > such as this: http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf And, as usual, when I go to download it, I find that I already have it alongside a schematic for the Cubietruck! > the thing is that it is critically important that the dts file *do > not* include the peripherals associated with the "Boards" > (Micro-Desktop, 15in laptop). the peripheral sets *MUST* go into a > "dynamic include" file that is detected at boot time and "inserted" > into the live device-tree. Indeed. I guess the computer card device tree sits at a level between the chipset device tree and what would normally be the machine device tree. > this functionality - dynamic runtime "insertion" of device-tree > fragments - was an idea *in development* back in 2013 we have had > to wait several years for this functionality to make its way into both > u-boot and the linux kernel. I guess I should ask whether such support made it into either of them. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Sunday, 19 July 2020 22:19:37 CEST Luke Kenneth Casson Leighton wrote: > On Sun, Jul 19, 2020 at 9:02 PM Pablo Rath wrote: > > Ok. But what did you use as defconfig in configs/ (U-Boot mainline)? > > it was 4 years ago: your guess is as good as mine, unless i happened > to put it in the wiki somewhere. Currently, I am updating this page: http://rhombus-tech.net/allwinner_a10/Building_Linux/ On which I noted that the boot page... http://rhombus-tech.net/allwinner/a20/boot/ ...provides a special configuration (eoma68-a20-4.7-config) that would presumably get copied into the configs directory as some kind of defconfig. However, it is probably superseded by the sunxi_defconfig file now, for the most part. It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very similar to that from the Cubietruck 2. Were the differences documented and are there any schematics to provide any necessary insight when updating the device tree? (Since these things appear to change all the time - or just decay - in the Linux kernel distribution.) Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Sunday, 19 July 2020 17:32:41 CEST Luke Kenneth Casson Leighton wrote: > On Sunday, July 19, 2020, Hendrik Boom wrote: > > > > debian does have an archive site somewhere where they keep totally > > obsolete and discontinued distributions. > > http://archive.debian.org is supposed to be that location. > > however the pool directory does not contain gcc cross compilers. Cross-compilers are relatively new in Debian as broadly supported things (ignoring things like Atmel cross-compilers and one-off attempts at providing toolchains for some release architectures). I think that they first made it into the distribution properly for Stretch, meaning that we're only on the second release that has them. Also, older packages probably have all sorts of dependencies on older distribution versions, and with that there's the need to virtualise or chroot entire software distributions. And then, it might turn out that the precise configuration of the compilers isn't entirely suitable, as I have discovered for various SoCs in the past [*]. Paul [*] However, that was actually related to soft-float support for MIPS, which needs to be configured at build-time for GCC, but which was omitted from the Debian toolchains because the assumption is that all the code compiled by the Debian compiler will be deployed on Linux, and Linux has run-time support for floating point instruction emulation (that a bare metal or alternative environment might not have). But in general, you cannot be too careful with some of this stuff, and not all shortcuts turn out to be what they seemed to be. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Sunday, 19 July 2020 14:17:21 CEST Luke Kenneth Casson Leighton wrote: > (btw thank you paul - and pablo - both) > > On Sun, Jul 19, 2020 at 12:18 PM Pablo Rath wrote: > > > > This is extremly helpful. I am going to try it out. Can you copy that to > > the wiki? > > yes please, paul. OK, I've updated this page... http://rhombus-tech.net/allwinner_a10/source_code/ It now links to these pages: http://rhombus-tech.net/allwinner_a10/Buildroot_Toolchain/ http://rhombus-tech.net/allwinner_a10/Building_U-Boot/ Hopefully, it still makes sense and can be followed by anyone wanting to get involved with this. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Sunday, 19 July 2020 13:17:38 CEST Pablo Rath wrote: > >On Sat, Jul 18, 2020 at 07:19:37PM +0200, Paul Boddie wrote: > > I saw that there is a section about legacy U-Boot in the page: > > > > http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/ > > Yes, obviously I had to start with U-Boot first. > Luke told me that sunxi U-Boot should build fine and that nothing has > changed so I started there. > > For mainline U-Boot I still need a valid config file to do 'make > eoma68_foo_defconfig'. There is a .dts file here > (http://rhombus-tech.net/allwinner/a20/boot/sun7i-a20-eoma68-a20.dts) > but I don't know if it was used for mainline U-Boot and not just for > Kernel compilation. I'm not sure what the relationship is between U-Boot and Linux. My impression is that U-Boot borrows code from Linux, and there are benefits to U-Boot knowing about device tree files, but my own experiences with U-Boot development are rather limited. [...] > > So, what seems to be necessary is to get an older compiler and to use that > > instead. Since distributions retire older compilers regularly, I used > > Buildroot to create a suitable GCC 4.9 cross-compiler than can then build > > the legacy U-Boot. > > I have realised that on Debian gcc versions are kept installed. I have > a native armhf installation (initially installed with Jessie) currently > upgraded to stretch and gcc-4.9 is still installed. Changed between gcc > versions with 'update-alternatives'. I don't know if this also apllies > to cross-toolchains because my experience with crossbuilding is limited. > > Sid (unstable) still has gcc-4.9 and even gcc-4.7 native armhf packages > so this could be another solution I have not tested yes as I have no > armhf sid installation. It's useful to hear that GCC versions are kept around. Recently, I upgraded hardware and now have Debian Buster installed, and I think GCC 7 is about as old as the packages get. For cross-compilers, GCC 8 seems to be what is offered. I did realise that you had probably managed just fine without having to find a toolchain, but it is probably useful to provide a path for others to follow as well. [...] > This is extremly helpful. I am going to try it out. Can you copy that to > the wiki? Maybe as a separate subpage or at the end. I think we should > keep everything short and clear for those who know what they are doing > but still provide enough hand-holding and external context for those > with less experience. I'll try and add the recipes to the wiki. I was going to do so, but then found myself doing other things instead. [...] > Good news is that I made it to the sunxi U-Boot prompt on Friday. Booted > via USB-FEL. So my > soldered Pins, UART connection, Power Supply, µUSB-OTG on the card work > fine. Great! > Next I have planned to compile a sunxi 3.4 Kernel and debootstrap a > Debian rootfs. > Then I want to try mainline U-Boot and a mainline Kernel. > Feel free to share your solutions and best practices with me! I'll try and take another look at this today. Hopefully, the old code can still be built without too many obstacles. The mainline code might present some challenges, at least with regard to specific hardware support. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Friday, 10 July 2020 08:59:07 CEST Pablo Rath wrote: > On Thu, Jul 09, 2020 at 11:43:58AM +0100, Luke Kenneth Casson Leighton wrote: > > > > yes, this is standard practice. you create the link on the parent, > > first, then it creates a question-mark, then you get an edit link. if > > you know what you're doing you can manually create edit links :) > > Thank you for the crash course. Worked... almost like... *magic*. > I have created a subpage under a20 and will put everthing there and we > can move individual sections later if necessary. I think I had similar problems until I realised that it is all very "old- school wiki", first creating links for new pages in existing pages, then getting the magic question mark, and then having the opportunity to create the new page. I suppose it encourages people to link to new content and to consider whether they really need a new page. I saw that there is a section about legacy U-Boot in the page: http://rhombus-tech.net/allwinner/a20/EOMA68-A20_2-7-4_preproduction/ The experience I had with old U-Boot versions that were contemporary with older versions of GCC is that the compiler-tweaking headers from Linux generally spew out lots of errors with newer compilers. One apparent solution was to just copy in the header from a more recent version of Linux (or maybe U-Boot) which is what I did for the MIPS Creator CI20 U-Boot, copying from a more recent version of Linux: cp ../CI20_linux-ci20-v3.18/include/linux/compiler-gcc.h include/linux However, that doesn't seem to be sufficient here. The structure of the Linux headers have changed, and while newer U-Boot versions seem to have adopted this structure, it doesn't seem to be easy to introduce to the legacy U-Boot for the Allwinner boards. So, what seems to be necessary is to get an older compiler and to use that instead. Since distributions retire older compilers regularly, I used Buildroot to create a suitable GCC 4.9 cross-compiler than can then build the legacy U-Boot. To make things complicated here, Buildroot also retires support for older compilers, so I had to find a version still supporting GCC 4.x that didn't also suffer from this issue: https://git.busybox.net/buildroot/commit/? id=c48f8a64626c60bd1b46804b7cf1a699ff53cdf3 Anyway, here are the commands I used: git clone git://git.buildroot.net/buildroot cd buildroot git checkout 2018.08.4 make menuconfig In the menu, the following settings were inspected/changed: Target options Target Architecture (ARM (little endian)) Target Binary Format (ELF) Target Architecture Variant Target ABI (EABIhf) Floating point strategy (NEON/VFPv4) ARM instruction set (ARM) Toolchain GCC compiler Version (gcc 4.9.x) To build the toolchain, run... make toolchain (Use -j for parallel builds, of course. You may need to install rsync if you haven't already done so. Other packages may also be necessary.) Setting PATH to reference this toolchain in output/host/bin, you can now build the legacy U-Boot as follows: git clone https://github.com/linux-sunxi/u-boot-sunxi.git cd u-boot-sunxi make CROSS_COMPILE=arm-linux- EOMA68_A20_config make CROSS_COMPILE=arm-linux- (Again, use -j to make this go faster. Note that Buildroot compilers tend to use their own naming, so it is arm-linux- and not arm-linux- gnueabihf- that needs to be used.) Here, the use of EOMA68_A20_config sets up a bootloader for SD cards, whereas EOMA68_A20_FEL_config would set up a USB-bootable payload. See here for all the details: https://github.com/linux-sunxi/u-boot-sunxi/wiki This should get you the u-boot-sunxi-with-spl.bin file that needs to be deployed. Hope this was helpful! Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] EOMA68 Computing Devices Update: Command Not Found
On Tuesday, 19 May 2020 02:05:52 CEST Luke Kenneth Casson Leighton wrote: > On Tue, May 19, 2020 at 12:43 AM Pičugins Arsenijs wrote: > > https://www.crowdsupply.com/eoma68/micro-desktop/updates/command-not-found > > > > Note on the 'lsusb' thing: I personally like the 'dmesg -Hw &' command, it > > stays in the background and prints the dmesg info in realtime - in > > particular, letting you see detailed data about newly-connected devices. > ah! thank you :) Any word on the shipment? I guess these things will be taking rather longer than usual. Hope everything is otherwise fine (with everyone)! Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
On Tuesday, 16 June 2020 10:44:47 CEST Pablo Rath wrote: > I have recieved an EOMA68-A20 2.7.4 preproduction computer card and the 1.7 > micro desktop (MD) last week. Just for clarification these boards are > nothing new and have been discussed on this mailing list. > If some of you already have their preproduction boards ready, I would > appreciate any help, hints and suggestions to help me getting started. I certainly don't have one, nor are there likely to be many in circulation, but maybe there are some people assisting Luke who have some experience with them. Without reviewing the previous threads, I can't give you any quick and/ or reliable answers to your questions. However, I did summarise the state of certain things on the wiki at one point: http://rhombus-tech.net/crowdsupply/status/ > 5. Git, notes and documentation > Finally I am wondering where to put my notes. A subpage on rhombus-tech > seems like a good idea good to me and indicates a work in progress in > contrast to the various wikis out there. Where do you want me to push my > work in progress git branches if I manage to hack something useful > together? You could probably make a wiki page on the rhombus-tech site with your notes, maybe linking to it from the one mentioned above. One thing I can imagine is that some kernel issues are likely to be much easier than when Luke was trying to get a kernel together, mostly because quite a bit of mainlining has since taken place, although I can't guarantee that the notorious Linux 4.7 bug mentioned on that page is still there or not. Still, it will be interesting to follow your investigations. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] MNT Reform Campaign
On Tuesday 12. May 2020 19.20.37 Christopher Havel wrote: > Forgive me for asking, because I didn't quite pass the requisite fervency > test to be enrolled in the Joint OSHW-F|L|OSS Technical Militia ( :P ), but > remind me, please, of a couple things, if I may ask them...? I can try and provide some suggestions, but I'm sure Luke can give you plenty of additional insight. > (1) Why are there none of these OSHW devices using existing x86-compatible > CPUs/SoCs? I can think of a few reasons, some mundane and some more important for open source hardware. One mundane but practical reason might be that there is a degree of additional complexity in board design and assembly with x86(-64) products. Looking at recent AMD products where the socket support has been fairly stable, the actual CPUs seem to have large numbers of pins. If the CPUs are actually socketed, maybe the techniques involved are less demanding than having to mount the CPUs directly on the boards, but then I can still imagine that the engineering isn't going to be easy. For lower-power products, things like the embedded Ryzen stuff uses a different socket type (FP5) to normal Ryzen (AM4) - even the GE variants of normal Ryzen - and for some products I get the impression that the "socket" is just an indicator of the footprint and not an actual socket where you would be able to swap out the CPUs, but I could be wrong. And this is just AMD: Intel seem to change "socket" types all the time which would make everything more complicated and demanding. It isn't a surprise that there are just a handful of major mainboard vendors presumably having deep relationships to AMD and Intel. For open source hardware, it is also potentially interesting to make low-power products, and here the power consumption of x86(-64) seems rather high. At the lower end, Intel seem to offer Atom-branded and Pentium-branded products that consume a few watts and seem to be based on relatively modern microarchitectures, and they did try to make embedded CPUs based on earlier microarchitectures - Quark, I think it was - that didn't catch on. There is also a strong temptation to drop the x86 legacy altogether when you are not strongly invested in it. My impression is that SoCs for other architectures provide a degree of freedom from that legacy at the cost of a lack of standardisation. But it also means that there is a certain potential to avoid the more recent undesirable aspects of BIOS-related technologies, although there are x86-64-based laptops being sold that supposedly address such issues (in certain regards) and that are promoted as being friendly to Free Software even if they are not actually open source hardware as well. > (2a) Are there any meaningful barriers to creating an OSHW-compatible x86 > CPU/SoC, independent of major chip houses (Intel, AMD) or established niche > players (VIA, etc)? Yes: patents. VIA only got away with releasing x86-compatible products because of some ancient agreement, as far as I remember, and Intel has been rather aggressive in preventing new entrants getting into the market. The histories of various companies passing through the x86 market are quite interesting: Cyrix, NexGen, National Semiconductor, IBM, Transmeta, and so on. Many of the alternative x86 implementations seem to have ended up at AMD over the years. > (2b) I've heard noises of a homegrown sort of effort out of China, from a > company and fab house over there... could that CPU be considered as an > acceptable candidate for such an effirt, and if not, why...? (I assume not, > and because "China!", but I'm wide open here.) I think I heard something of the sort, too. There is nothing to stop anyone from making their own x86(-64) implementation technically, and we must be at the stage where a fair amount of the x86 architecture is not patent encumbered. Then again, there are plenty of other architectures that are a lot more interesting and performant than old-style x86. That brings us to another pertinent point about modern x86-64 CPUs: the performance presumably comes from the microarchitecture that is effectively internal and specific to each of the big players' products (things like Core and Zen). Seeking to compete with existing x86 products would involve a colossal amount of work replicating what they have managed to do with those microarchitecture efforts. Well, those were just a few ideas, some more credible than others. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] MNT Reform Campaign
Hello, It got mentioned about two-and-a-half years ago on this list, but the MNT Reform campaign has finally begun: https://www.crowdsupply.com/mnt/reform Of potential relevance to those following EOMA68-related efforts might be various resources that the MNT Reform effort has made available: https://source.mntmn.com/MNT/reform Things like the PCB layouts, microcontroller firmware and case designs are published, although people have previously noted that Autodesk Fusion isn't a particularly libre-friendly format for the case designs. One could envisage adaptations of this for EOMA68-related purposes or something with similar objectives. Certainly, user-upgradeable functionality via an externally accessible PCMCIA-style slot (or similar, rather than the internal SO-DIMM slot) would surely be worthwhile exploring. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] How about an opensource nuclear reactor?
On Monday 9. March 2020 23.02.30 David Niklas wrote: > On Tue, 10 Mar 2020 00:07:44 + Luke Kenneth Casson Leighton wrote: > > > > 100 megawatt. err.. where do you source the uranium or plutonium? > > > > err. > > AFAIK, you buy it from the US gov. in the USA. For other countries you > may have to trade to obtain some as not every country produces their own. In other words, you either have to be on a list or get yourself onto a list. One of those kinds of list isn't the kind you want to be on. And the uranium and plutonium is on a different kind of list altogether, but that's the reason for those other lists. :-) Meanwhile, some related reading just came up: https://www.bbc.com/future/article/20200309-are-small-nuclear-power-plants-safe-and-efficient I guess we're all on someone's recommended reading list. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Is everything okay?
On Monday 2. March 2020 20.22.27 Luke Kenneth Casson Leighton wrote: > https://www.crowdsupply.com/eoma68/micro-desktop/updates/coronavirus-and-a-plan-for-pcb-testing Thanks once again for keeping us up-to-date! And more important than that, to hear the personal side of things, people looking after one another, and so on. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] EOMA68 Computing Devices Update: Measurements and a Hypothesis
Hello, Sorry, just warming this thread up with a few random observations... On Monday 2. December 2019 20.05.55 Luke Kenneth Casson Leighton wrote: > On Mon, Dec 2, 2019 at 3:23 PM Paul Boddie wrote: > > > > https://www.crowdsupply.com/eoma68/micro-desktop/updates/measurements-and-> > > > a-hypothesis > > > > From what it says, it rather sounds like same (or a similar) problem is > > being encountered as the one which happened with the Ingenic JZ4775 > > boards: > yehyeh. except i didn't know about the PCBs not actually matching the > gerber files, back then. OK, that would have been a bit awkward for troubleshooting, too. [...] > i did actually partly get them up and running, but i'd put a 24mhz XTAL on > instead of 48mhz, and the SD/MMC wasn't having it. i tried fixing that in > software (doubling the PLL frequencies for the SD/MMC) but couldn't get it > up and running. Yes, I imagine that the external oscillator is supposed to be 48MHz, and there may well be a limit to how far you can get (and how well it will work) by just using the PLL multipliers to get you to the frequencies you want. > with it only being single-core 1ghz MIPS32 i dropped the investigation. Interestingly, these SoCs all have other cores tucked away inside them, although you probably can't get away with regarding them as "proper" cores. For instance, on the JZ4780 (which is dual-core), but also the JZ4770, JZ4760 and most likely the JZ4775, there's a core called AUX in the VPU and another one called MCU in the programmable DMA peripheral, both of them being XBurst cores but without certain amenities. Typically, they lack full MMUs, cache, FPUs and other things, but they seem to have fast access to some cache-like memory (TCSM). I imagine that with a bit more investigation, other cores will pop up, but it is interesting how they get a lot of mileage out of the same architecture instead of mixing and matching (like the ARC cores in Intel CPUs or the OpenRISC cores in Allwinner SoCs). I was also trying to find out a bit more about the dedicated video and "vector matrix arithmetic" blocks associated with the VPU functionality, and one has to wonder what is going on there as well. Meanwhile, I wonder if you have heard from Mike lately or whether things are generally stalled with regard to the production issues. I guess that there will be a few weeks of holiday and disruption to take into account now, but I thought that maybe you'd caught up with him before the break. Anyway, hope things are working out wherever you might be. (And that also goes for other readers of the list, of course!) Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Libre RISC-V -- I mean OpenPower M-Class GPU update
On 2020-01-02 00:28, Luke Kenneth Casson Leighton wrote: after they got the ARM7 functional, barry managed to get ARM their very first license, ever: with Plessey. they were so happy, they offered him a job. barry turned it down: he would have been employee number 12, and a very rich man, now :) The Plessey connection is interesting to hear about. Of course, Plessey got merged into GEC which became GEC Marconi. Ultimately, Marconi, with the GEC assets stripped away and with the company focusing on the apparently successful telecoms equipment model that made Ericsson a lot of money, itself failed. but ARM - aka ACORN RISC machines (not Advanced RISC Machines) - basically had zero cash, and at one point was completely unable to pay its employees (this is like... early 1990s). they licensed the ARM11 design to Intel for GBP 100,000, unrestricted, royalty-free, in exchange for a promise from the team that IBM had bought (the DEC Alpha developers), would "fix all the problems and give the changes back". The story I have heard is that a DEC team did the StrongARM on their own initiative - not a surprising thing within DEC if you read about the different RISC initiatives within DEC in the 1980s and 1990s and all the corporate politics - doing so maybe without a licence and without ARM even knowing about it, and then they approached ARM afterwards. Whether that story is true or not, it effectively saved ARM's bacon. It certainly kept Acorn viable for another couple of years because their roadmap was running out of road, waiting for ARM800 or ARM810 CPUs which, in their envisaged form, probably never appeared. Also, the target frequency would have been modest compared to StrongARM, but that probably just shows what expertise DEC had accrued and applied when developing Alpha. Probably the other understated development at that point in ARM's history was the introduction of the Cirrus Logic ARM7500 and ARM7500FE products which were the first ARM SoCs (as far as I am aware). A bunch of network computers and set-top boxes used those products, and they also kept Acorn going for some more time. The ARM7500FE also had hardware floating point arithmetic, unlike the StrongARM, and it was therefore still an attractive choice despite being clocked a lot slower than the StrongARM. the DEC Alpha developers - whom Intel themselves didn't know what to do with, so gave them the PXA Project to do - took one look at the HDL and went "holy f*** this is s**t" and started again from scratch. they could do so because they had that GBP 100,000 royalty-free license from ARM, and the contract wasn't worded carefully enough. thus, the PXA 2xx series became the world's first superscalar ARM-compatible architecture... *not* the ARM Cortex A8 as ARM keeps telling everybody :) As far as I know the XScale and PXA product lines descend from StrongARM as a consequence of the bizarre and rather suspicious settlement between DEC and Intel where DEC supposedly won but ended up weakening its own position, probably hastening its acquisition by Compaq and the effective demise of various technologies like Alpha. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Libre RISC-V -- I mean OpenPower M-Class GPU update
On 2020-01-01 22:09, Luke Kenneth Casson Leighton wrote: the collaboration that is in place, and which is otherwise successfully taking place, is taking place behind *closed doors*, where we, as Libre Businesses, are told, basically, "sign this agreement which entirely compromises your business model, or go fuck yourself". I haven't followed what goes on with RISC-V licensing, but it rather sounds like there are vested interests who want to retain control and to leverage their inherent advantage as developers of the technologies concerned. This is a pretty familiar story from the world of standards, even Internet standards, where companies effectively "front-run" standards by loading them up with descriptions of their own technologies, effectively requiring standards implementers to play catch-up all the time. This latter strategy is not quite the same thing as, say, people being gatekeepers to a CPU architecture, but it is part of a more general phenomenon of stacking the odds in one's own favour and disadvantaging outsiders. A more mundane example would be any one of numerous corporate-run Free Software projects that demand copyright or comprehensive licensing assignments from contributors, and who make it tediously difficult to get code upstream, all because the company's needs supposedly override all others. by complete contrast... the OpenPower Foundation's Director, Hugh Blemings, is someone who has worked with Libre Developers (he himself is one) for over two, nearly three decades. *he* was the one that told *me* that the OpenPower Foundation Members have created a Membership Agreement that is specifically designed to allow Libre Businesses to be "happy" with its terms and conditions. Maybe ARM's success is a corrupting influence when companies and organisations try to monetise hardware architectures, but ARM only got into its lucrative position through a combination of good luck and a fervour for licensing things, the latter only ever coming about as some kind of correction for ARM's corporate predecessor's obsession with keeping everything proprietary and trying to use such proprietary technologies to their own exclusive competitive advantage. It will be interesting to see how the different initiatives (RISC-V, OpenPower, MIPS...) evolve to respond to openness concerns and the need to cultivate interest in their offerings more generally. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] EOMA68 Computing Devices Update: Measurements and a Hypothesis
Hello again, I saw the latest update when it was issued a few days ago, with these details being particularly important: "PCBs are etched with acid, and when the tracks or pads are particularly close together (such as with BGA balls), not enough acid gets in to eat away the copper, and (in a very indirect way) the BGA pads end up being far larger than they should be. This, in turn, means that when the IC is put on the PCB and heated up, the BGA balls (which are made of solder) will spread out much farther, and potentially even spread so far that they contact each other and short out." https://www.crowdsupply.com/eoma68/micro-desktop/updates/measurements-and-a-hypothesis From what it says, it rather sounds like same (or a similar) problem is being encountered as the one which happened with the Ingenic JZ4775 boards: "When the first 6 samples were done, only one was found to be working: for some reason the DDR3 BGA solder balls had spread and caused short circuits. One of the samples was still with the factory, and that too was found to have shorts. Mike has been extremely helpful, and this is the first time that he's been involved with BGA, where his uncle's factory has been the one that assembled the samples." http://rhombus-tech.net/ingenic/jz4775/news/EOMA68-jz4775_XRay_Photos/ At that point in time, I don't remember any more news about resolving the matter, and with the campaign being finalised the priority was no longer to get these boards working. But perhaps one of these situations informs the other, or maybe they inform each other somehow. Thanks in any case for keeping us updated! Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] crowdsupply update 27sep2019 power regulators
On Sunday 29. September 2019 01.35.31 Luke Kenneth Casson Leighton wrote: > > Ahh yes. The lovely fraud by china taobao sellers. Crack open the 200uF > capacitor and it contains a 10uF one inside. > > Mike on the other hand has a solid relationship with his suppliers, one he > buys a million components a year from. Has anything else become known about this particular issue? Were the regulators the only problem or only the first known problem? I guess travel and logistics complicate things here, but I seem to remember it being mentioned that replacement regulators were on their way. Paul P.S. I hope Canada is working out and is not too cold at this time of year compared to your usual places of residence. ;-) (I read recently that Canada doesn't have mandated national limits for lead in public water supplies, which happens to be yet another huge concern for marginalised communities, this alongside the matter of multinationals apparently taking whatever drinkable water those communities might have had in order to sell big-name bottled water to affluent consumers.) ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] STM32MP1
Hello, I saw that Olimex were getting excited about a ST Microelectronics SoC that, at least in some forms, might be an interesting EOMA-related candidate, too: https://olimex.wordpress.com/2019/09/03/stm32mp1-nice-candidate-for-new-industrial-grade-olinuxino-lime/ https://olimex.wordpress.com/2019/09/19/stm32mp1-olinuxino-development-update-we-managed-to-build-ubuntu-18-04-lts-with-linux-kernel-5-3-now-we-need-your-feedback-on-gpios/ Here's the actual product site (with the now "normal" nagging about cookies, all enabled by default, and even spurious whining about my browser being "out of date"): https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html As noted by Olimex, there's a variant (STM32MP157) with a "3D GPU". According to the datasheet, this is a Vivante solution. Some people might be worried about the main CPU specification, though: 650MHz dual-core Cortex-A7. There's this interesting all-in-one module available, too: https://octavosystems.com/octavo_products/osd32mp15x/ Olimex were a bit "sniffy" about this, mentioning the 512MB RAM of the available modules, but it looks like future ones will have 1GB RAM. Anyway, I hope this is interesting to someone out there. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Fwd: [eoma68 update] report back from factory on HDMI
On Wednesday 3. July 2019 09.03.44 Luke Kenneth Casson Leighton wrote: > > Mike's staff began the PCB assembly of the run of 100, and had to stop > at 36. 20 were ok: 16 of them, the HDMI connector refused to fit. > The reason: the CNC machining on the edge of the PCB has not been done > accurately enough: it's simply too ragged. The staff did some > experimentation, cleaning up some of the edges in the cut-out with an > xacto-knife: this did the trick, even though it is shaving something > like 0.01mm off the ragged edge of the PCB. I can imagine how frustrating this can be, but it is good that some experimentation on the spot was able to identify the likely cause. (My own limited experience with PCBs, albeit with "maker"-level producers, suggests that some PCB cutting/milling is not done as accurately or in as tidy a way as one might expect. There have also been some other interesting experiences with production quality with some producers, but that is another story.) > The left and right edges do not matter too much, however where the > HDMI connector comes in close, it definitely does. Mike is going to > talk to the PCB factory to see if there is anything that they can do > in future, however with 1,000 PCBs already manufactured, the safest > thing to do is probably to *hand-trim* that PCB edge, removing the > burrs, on all 1,000 PCBs. It is too bad that this adds another step to the process, but it at least hopefully remedies the issue. I guess it shows that minor faults can become more serious problems further down the chain of production. > Again, to reiterate, because I am still seeing evidence of > "complaints" out there, from people who believe this should be easy: > these are absolutely ridiculously tiny components and tolerances, and > the budget on which it's being done is equally as frugal. 0.05mm on > the edge of a PCB. 0.2 mm wide pins, with 0.2mm clearance between > them. Having seen the measurements related to various parts, I can more easily believe how challenging it is. And it seems intimidating when considering the demands of production to such levels of accuracy. > A "normal" Single-Board Computer product from any other > well-funded Corporation would use large (Type A) HDMI, top-mounted, > with plenty of tolerances and no need for the PCB edge to be > accurately milled. Yes, it seems that the larger but less ambitious players get off easy again. > Again, to reiterate: we do not know what will need to be solved next. > Therefore, a production date simply cannot be provided, and that > really is the end of the matter. Or, the answer is: the production > date is "the production time plus the unknown time to solve unknown > and unknowable future issues". Well, I hope that you, Mike and his employees feel that valuable experience is being gained that will pay off in future. It would certainly be nicer if everything went more smoothly, but one might then wonder which potential problems are being missed. > Mike is sending me the 20 "good" PCBs so that I can test them here, to > see if they are okay. The staff will continue with the rest by > shaving the burrs on the PCB on every single one of the remaining 80 > with an xacto-knife, before putting them through the production line. > It is looking like I will need to do the testing of all 100 of this > preliminary production run, here, at my home, in Taiwan. And I hope that the rest of the run and the testing go a bit better than how things have gone so far. Keep up the good work! Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] eoma68 a20 card production
On Friday 21. June 2019 22.13.02 Luke Kenneth Casson Leighton wrote: > > Reason why 3.4.104+ has to be shipped was explained 18 or so months ago. > > Entire OSes need to be redone otherwise. I have tried to document some of this here: http://rhombus-tech.net/crowdsupply/status/ Some other topics are also covered, such as changes to the Computer Card hardware during the realisation of the campaign. I hope this summary proves to be helpful, anyway. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Schematic and PCB layout CAD files
On Monday 17. June 2019 08.40.22 Luke Kenneth Casson Leighton wrote: > On Sun, Jun 16, 2019 at 5:14 PM Paul Boddie wrote: > > On Wednesday 12. June 2019 02.09.12 Luke Kenneth Casson Leighton wrote: > > > added here > > > http://rhombus-tech.net/pcmcia_sources/ > > > > I have updated this page with some more details and some remarks about the > > physical constraints involved. If such remarks belong elsewhere, feel free > > to move them. > > no, great idea. Phew! [...] > interestingly, there's nothing to stop you putting the card inside > the PCB at a slight angle, such that whilst at the PCMCIA header end > there is plenty of room (relatively speaking) on either side of the > PCB, and at the other end the PCB becomes flush with the floor of the > metal case. I think you'd really have to be confident amount the manufacturing process to do this. > > I don't know whether this would have influenced the choice of sockets in > > the current batch of boards, but I wonder if it might be influential or > > useful to consider for any subsequent production. > > the issue is that even if the 1.2mm PCB is flush with the 5.0mm floor > (leaving no room for underside components for about... 35 possibly > even as much as 40mm (half) the Card, which would hugely complicate > the design, the connectors are still around 3.3mm in height (USB-OTG, > Micro-HDMI Type D) > > 5.0 - 0.1 (thickness of the metal) - 1.2 (PCB thickness) = 3.7mm > > 3.7 - 3.3 (height of the connector) = 0.4mm > > minus another 0.1mm for the top case shield. > > so that leaves only 0.3mm clearance, which means that the connectors > will poke out in a completely asymmetric way, which is very ugly. I guess that the solution involving extending the board to provide connectors, in that classic PCMCIA/CardBus style seen with things like USB adapter cards, wasn't desirable because it would demand extra casework to be done at quite some expense. So the mid-mount connectors were a reasonable compromise. > the mid-mount option gave a reasonably symmetric above- and below- > gap that doesn't look quite so ugly. > > plus, having 50% of the PCB impossible to put components on the > BOTTOM side means that the PMIC area would need redesigning (again), > spreading out the components to fit the ones that normally go on > BOTTOM. Yes, I can imagine that limiting the components to one side brings its own challenges. For simple cards only providing flash memory and other such things (Web searches yield some kind of card for Mercedes vehicles of this nature), I guess that it isn't a major concern. [...] > > P.S. I have also been working on KiCad footprints for some of the parts I > > have found, in case anyone is still interested in such things. > > superb. if you send me an ssh key i can arrange to add you to the > repo that i started 6 years ago: > http://git.rhombus-tech.net/?p=eoma.git;a=summary I'll send you that, trying to remember the preferred form of the exported key this time. ;-) Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Schematic and PCB layout CAD files
On Wednesday 12. June 2019 02.09.12 Luke Kenneth Casson Leighton wrote: > > added here > http://rhombus-tech.net/pcmcia_sources/ I have updated this page with some more details and some remarks about the physical constraints involved. If such remarks belong elsewhere, feel free to move them. It was interesting to work through some of the calculations. The 0.4mm offset of one of the header parts seems like a curious figure until one does the calculations and determines that it must be intended for boards of 1.2mm thickness (or less) with components mounted on the upper side. Indeed, headers employing such an offset might conceivably be interesting when considering sockets on the "non-EOMA68" edge of a computer card, since these headers would maximise the space available to components on the upper side of a board, presumably permitting top-mount sockets to be used. I don't know whether this would have influenced the choice of sockets in the current batch of boards, but I wonder if it might be influential or useful to consider for any subsequent production. I hope this was helpful, anyway. Paul P.S. I have also been working on KiCad footprints for some of the parts I have found, in case anyone is still interested in such things. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Schematic and PCB layout CAD files
On Saturday 1. June 2019 21.18.34 Luke Kenneth Casson Leighton wrote: > On Sat, Jun 1, 2019 at 7:05 PM Paul Boddie wrote: > > > > Knowing your policy on information existing only on the list, > > que? no, the wiki's there for people to edit and make the > information more accessible. That's what I meant. So I was looking on the Rhombus Tech and eLinux.org sites for information, but it wasn't so easy to find the essentials. [...] > > It does seem that the Amphenol > > connector tries to guard against this - as well as I interpret the > > drawings - and I wonder if others also do so. > > in combination with the correct matching casework, of course. being > incompatible with the PCMCIA *external* specification would have been > disastrous. On the topic of connectors and casework, I happened to come across this selection of products: http://www.morethanall.com/products/index/btype_id/5/type_id/62 (It was while investigating the Olimex KiCad footprints that I found an obscure product code for a microSD connector, this then yielding the above site when searching the Web.) I just thought I'd post the details here in case it happened to be of interest, the company being based in New Taipei City, no less. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Intel's at it again
On Sunday 9. June 2019 22.38.55 Luke Kenneth Casson Leighton wrote: > On Sun, Jun 9, 2019 at 10:10 PM Paul Boddie wrote: > > Reminds me of Olimex's SOM204. Must be three times better than EOMA68: > > > > https://www.olimex.com/Products/SOM204/ > > standards need to be properly designed, otherwise they're not standards. I think there's quite a bit of optional stuff in those 204 connections, arguably making it a bit like a breakout board for SoCs. That might be helpful for some applications, but probably isn't what one might call "plug and play". > > P.S. Any news on the production front? > > mike's manager's quit, and the production knowledge which we learned > and accumulated through the samples has gone with him. > > mike and i need to re-learn and recall the information. That is unfortunate news. I hope you can both figure things out without too much effort and inconvenience. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Intel's at it again
On Monday 3. June 2019 20.59.11 Luke Kenneth Casson Leighton wrote: > > On Mon, Jun 3, 2019 at 4:18 PM David Niklas wrote: > > > > Sorry to be the bearer of bad news, but Intel's at it again: > > https://www.anandtech.com/show/14467/intel-launches-the-nuc-compute-element-for-modular-computing-systems A few people in the article's comments are already unhappy about it, having had to abandon their investment in Intel's last initiative. > oh look, it's EOMA200! Reminds me of Olimex's SOM204. Must be three times better than EOMA68: https://www.olimex.com/Products/SOM204/ Paul P.S. Any news on the production front? ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Schematic and PCB layout CAD files
On Friday 31. May 2019 23.49.57 Luke Kenneth Casson Leighton wrote: > On Saturday, June 1, 2019, Paul Boddie wrote: > > > > The inner dimensions are actually interesting for practical reasons, which > > was why I was asking about the range of PCB sizes. > > If there is no user facing connector, there is the possibility of a range > of length. > > If it is ok to stick the PCB out the end of the Card just like WIFI and Eth > PCMCIA used to do, length is limited only by practicalities. Yes, this makes sense. > Otherwise, there is no "range": the casework really does define the PCB > size to around a 0.1 mm tolerance or less. It was mostly needing to know how wide a PCB might need to be. Obviously, one can play it safe by keeping the width well within 54mm. [...] > > There was a run of cards done at one point (or more). Did anyone actually > > do anything with those cards at the time? I seem to remember confusion > > about engineering boards, people having one kind of board and not the > > other, and so on. Did they all end up in people's desk drawers or > > something? > > Pretty much. Do you have any reflections on that? Was there a realistic expectation that people might develop software or hardware to take advantage of those boards? Could more have been done to accelerate the initiative with this access to actual hardware? [...] > > Again, it was interesting to see this with regard to what kind of PCB > > sizes would actually be produced. > > 78.1 x 47.3 is what is required for the litkconn casework, and there is no > wiggle room on that. Right. [Amphenol 95622-004LF] > > When you note that 1.5mm is useless, do you mean that within a housing > > (casework), a 1.5mm board takes too much space from, say, 3.3mm (Type I) > > or 5.0mm (Type II), and that a thinner board is needed? > > Both. [...] > They are. This was described several times on this list and in at least one > update. Knowing your policy on information existing only on the list, I had hoped to see more information on the wiki, but it is useful to get more details again now. > The stainless steel is 0.1mm thick. That leaves 4.8mm. > > The SDMMC sits 1.9mm above the PCB, as does the mid mount USB OTG. > > The 2.2uH Inductors were also very very specifically chosen to fit under a > 1.9mm threshold, they are 3.2 x 3.2 mm and are quite expensive compared to > cheaper wire wound inductors which come in around the 2.5mm height mark. > > Also the SoC is around the same height, plus various large capacitors (1206 > 10uF) and one large diode have all had to be special item "Low Profile" > orders, all 1.9mm or lower. I must admit that I don't have a wide experience of SoC heights, with the only one to hand here being an Ingenic JZ4780 that doesn't really seem very tall. > So now we are down to 2.9mm. > > On the underside the *MID MOUNT* Micro HDMI and USB OTG connectors sit > 1.6mm below the PCB. > > No components above that height are permitted, it has meant a couple of > redesigns, moving some large 0805 capacitors topside. > > These underside capacitors, particularly under the CPU and DRAM, are > absolutely essential for stabilising power during peak loads, and they > clearly cannot go on TOP because they have to be extremely short tracks. > Being NEXT to the SoC would NOT be okay. They HAVE to go underside, as > close to the BGA pin where power is drained as physically possible. > > Aside from the Micro HDMI and OTG mid mount connectors there is nothing > over a 1mm height. Still, that is enough. > > 2.9 minus 1.6 is 1.3mm > > That leaves a mere TENTH of a millimetre spare clearance if using a 1.2mm > PCB. > > Can you see that for this type of design a 1.5mm PCB would be completely > impractical? Yes, it mostly makes sense. > If on the other hand there were no mid mount connectors it MIGHT be > possible. > > Anyway this is why Litkconn header and casework were selected because it > has all 68 PCMCIA pins on TOP instead of a twin pair staggered in height. Are such headers (I wasn't aware of the terminology) easy to find? Searching for PCMCIA headers in the mainstream channels, even using convenient sites like Octopart, is excruciating. [...] > > This is what I found, but I wondered why it wasn't mentioned on the > > specification pages, or why 55mm appears in the diagrams. I did find two > > pages with the 85mm x 54mm x 5mm dimensions on the Rhombus Tech site, > > however: > If you see any that are wrong please do correct them. The diagrams are the challenge since they are not readily editable. However, they possibly need reworking, anyway, partly due to their vintage. [...] >
Re: [Arm-netbook] Schematic and PCB layout CAD files
On Friday 31. May 2019 17.06.14 Luke Kenneth Casson Leighton wrote: > On Fri, May 31, 2019 at 3:47 PM Paul Boddie wrote: > > Also, the A10 news page has mentions of these dimensions from several > > years > > ago: > > > > http://rhombus-tech.net/allwinner_a10/news/ > > > > However, the PC Card documentation indicates that the actual housing of > > such a card is only 54mm wide, so I don't see how existing PC Card > > housings would accommodate such a PCB. > > that's what cost USD $15k when the engineer we paid didn't read the > spec properly. i told him to source one of the caseworks, measure the > INNER dimensions of the area as defined by the plastic, and use those. The inner dimensions are actually interesting for practical reasons, which was why I was asking about the range of PCB sizes. [...] > > I do remember that EOMA68 cards (maybe of an earlier generation) were > > produced. > > yes. There was a run of cards done at one point (or more). Did anyone actually do anything with those cards at the time? I seem to remember confusion about engineering boards, people having one kind of board and not the other, and so on. Did they all end up in people's desk drawers or something? > > Then again, looking at the A10 news page, there is a picture of a > > PCB layout from 2013 with dimensions of 78.1mm x 47.3mm, although it isn't > > completely clear what the screenshot is really showing. Again, it was interesting to see this with regard to what kind of PCB sizes would actually be produced. > > Another thing that I wondered about is the width of the board when > > accommodating a board edge connector like the Amphenol 95622-004LF, which > > seems to be a low-cost and readily-available connector. It seems that the > > board edge needs to be less than 50.8mm across because such connectors > > enclose the contact area on each side. > > https://cdn.amphenol-icc.com/media/wysiwyg/files/drawing/95622.pdf > > that's a really weird connector. it appears to be a socket, however > it is one that fits on the *edge* of a PCB, of a very specific height > (am having difficulty working that out from the diagram). it's > probably requiring 1.2mm PCB however that is guess-work. > > no wait, Cross Section C, it's 1.5mm, and that also tells us it's the > PCMCIA *header*. Yes, my interpretation of Section C-C is that 1.5mm is the minimum board thickness, with the usual 2.2mm connector. > btw, 1.5mm is useless because the clearance on TOP components is > nowhere near enough. When you note that 1.5mm is useless, do you mean that within a housing (casework), a 1.5mm board takes too much space from, say, 3.3mm (Type I) or 5.0mm (Type II), and that a thinner board is needed? Computer card heights/thicknesses mentioned here, by the way: https://www.elinux.org/Embedded_Open_Modular_Architecture/EOMA68/FAQ I could understand 3.3mm being difficult, with 0.9mm left on each side of the board, but 5.0mm should leave 2.6mm (minus casework) on one side. Then again, I know the margins can be pretty small with these things. > > I am only really asking these questions because I have been looking at > > making some footprints and other resources, and at least the fundamental > > board dimensions should be an obvious thing to discover, but I just > > didn't see them mentioned as prominently as I had thought they would be. > > the PCB has to fit inside the casework, and the casework's *external* > dimensions are required to conform to PCMCIA. Yes. > PCMCIA, is, obviously > (https://www.google.com/search?q=PCMCIA+card+dimensions) 5.0 x 85.6 x > 54.0 mm This is what I found, but I wondered why it wasn't mentioned on the specification pages, or why 55mm appears in the diagrams. I did find two pages with the 85mm x 54mm x 5mm dimensions on the Rhombus Tech site, however: http://rhombus-tech.net/allwinner/a31/orders/ http://rhombus-tech.net/freescale/iMX6/orders/ > however the reason why there's no prominent mention of the *inner* > dimensions is because, obviously, they're critically dependent on what > *casework* is chosen, *NOT* repeat *NOT* on a hard spec. > > it is *PCMCIA case size conformance* that is the hard requirement, > *NOT* the actual PCB size. Yes, it was really for an indication of what kind of PCB sizes result from these hard requirements that prompted me to ask. That and a need to question why there were boards made that were wider than the apparent external width of the card housing. > example: the PCB size (its length) will also critically depend on the > PCMCIA header dimensions. if the header is N mm deep, then obviously, > if you make a PCB that is exactly 85.6 mm long, i
Re: [Arm-netbook] Schematic and PCB layout CAD files
On Tuesday 21. May 2019 21.57.16 Luke Kenneth Casson Leighton wrote: > On Tue, May 21, 2019 at 5:43 PM Paul Boddie wrote: > > Again, in case anyone wanted to take a closer look. > > thanks paul. No problem! Actually, looking a bit closer at PCB-related topics, I started to wonder about a few things. Maybe they are actually covered in the specifications or on the wiki, but I didn't manage to find what I was looking for. First of all, investigating the EOMA68 computer card characteristics, I didn't find the physical dimensions of such cards other than mentions of their thickness. I imagine that the dimensions would be the same as those of the different PC Card (PCMCIA) profiles: https://web.archive.org/web/20080822091349/http://www.pcmcia.org/pccard.htm#03 I did find a PCB size of 85mm x 55mm in diagrams on the Engineering Board pages: https://www.elinux.org/Embedded_Open_Modular_Architecture/EOMA68/EngineeringBoard https://www.elinux.org/Embedded_Open_Modular_Architecture/EOMA68/MiniEngineeringBoard Also, the A10 news page has mentions of these dimensions from several years ago: http://rhombus-tech.net/allwinner_a10/news/ However, the PC Card documentation indicates that the actual housing of such a card is only 54mm wide, so I don't see how existing PC Card housings would accommodate such a PCB. There is also the matter of the length of a PCB. Again, the PC Card housing is supposedly 85.6mm, which leaves a board length of 85mm as being plausible. Have these measurements been confirmed or maybe subsequently revised? I do remember that EOMA68 cards (maybe of an earlier generation) were produced. Then again, looking at the A10 news page, there is a picture of a PCB layout from 2013 with dimensions of 78.1mm x 47.3mm, although it isn't completely clear what the screenshot is really showing. Another thing that I wondered about is the width of the board when accommodating a board edge connector like the Amphenol 95622-004LF, which seems to be a low-cost and readily-available connector. It seems that the board edge needs to be less than 50.8mm across because such connectors enclose the contact area on each side. Is that generally how these connectors work? I see that pictures of EOMA68 computer card PCBs seem to have a narrower edge connector part, with the rest of the board presumably spanning the interior of a PC Card housing. I am only really asking these questions because I have been looking at making some footprints and other resources, and at least the fundamental board dimensions should be an obvious thing to discover, but I just didn't see them mentioned as prominently as I had thought they would be. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Schematic and PCB layout CAD files
On Monday 20. May 2019 13.18.14 Paul Boddie wrote: > > Also, this board is distinct from the Olimex A64-based laptop and SOM board, > with the latter being completely proprietary, as I understand it. I thought that I should point out, however, that the laptop board designs including the CPU board appear to be freely available: https://github.com/OLIMEX/DIY-LAPTOP/tree/master/HARDWARE Again, in case anyone wanted to take a closer look. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Schematic and PCB layout CAD files
On Monday 20. May 2019 04.22.41 Luke Kenneth Casson Leighton wrote: > On Sun, May 19, 2019 at 10:09 PM Paul Boddie wrote: > > On the topic of KiCad and designs related to the EOMA68-A20 cards, it is > > worth noting that the Olimex A64-OLinuXino board schematic and layout is > > available in KiCad format: > > > > https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/A64 > > -OLinuXino_Rev_D > this is the project i was referring to that was a nightmare to > develop. there's a FOSDEM talk about it. I'd have to review what has been said about it: there are usually indications of problems in the Olimex blog articles, either in the articles themselves or in the comments. Right now, I only recall problems with the A64 kernel support, as usual, and nothing much about developing the hardware. Various Olimex talks have covered KiCad, but my impression was that they were largely happy about it. This doesn't mean that these projects are necessarily collaborative or have people actually looking at the designs. I didn't find any discussion in their forums about such things. One of my motivations for looking closer was to see whether people can actually open these files and do things with them. As far as I can tell, these files seem to be usable, although one would have to go through the entire process to find out whether they genuinely reproduce the same board, of course. Anyway, here are some articles I found about this board and KiCad: https://olimex.wordpress.com/2015/10/16/we-work-on-a64-olinuxino-the-first-open-source-hardware-64-bit-development-board/ https://olimex.wordpress.com/2015/11/20/a64-olinuxino-update-2/ https://olimex.wordpress.com/2015/11/10/a64-olinuxino-update-schematic-almost-done-now-component-placement-on-the-pcb-is-on-the-way/ https://olimex.wordpress.com/2016/01/08/a64-olinuxino-oshw-linux-computer-is-close-to-complete-routing-github-update-of-kicad-files/ https://olimex.wordpress.com/2016/01/22/a64-olinuxino-routing-completed-but-we-still-have-to-final-touch-this-and-that/ https://olimex.wordpress.com/2016/02/17/a64-olinuxino-64-bit-arm-oshw-designed-completely-with-kicad-is-live/ There isn't really much detail in these articles, but I suppose it gives an impression of the timeline. > btw, just so that people are aware: tsvetan has consistently lied to > a *lot* of people and caused huge problems for the EOMA project. Sure, but I thought that I should at least mention that Olimex have made the component/footprint libraries and designs available for KiCad. This might give anyone interested a head start on doing something similar, or at least provide an indication of how much work is involved. Maybe the design/libraries effectively use modified versions of the standard components/footprints and that it wouldn't be much effort to replicate that work independently. But this would only make designs with other SoCs like the A20 more feasible and give more confidence to people that it can be done. Paul P.S. Note that I wouldn't necessarily recommend the A64 as the basis of a product given the apparently ongoing software problems: https://olimex.wordpress.com/2019/03/08/a64-olinuxinogot-mainline-linux-kernel-5-0-images/ Also, this board is distinct from the Olimex A64-based laptop and SOM board, with the latter being completely proprietary, as I understand it. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Schematic and PCB layout CAD files
On Saturday 18. May 2019 18.49.32 Jakub Kákona wrote: > > And yes, Arun, unavailability of easily sharable CAD design formats is a > blocker of potential widespread use by the community. But I personally > hope, there will be enough appeal of open design files that I or someone > else redesign it in KiCAD. I guess you, Jakub, must be involved with the following... https://github.com/MLAB-project/Modules https://github.com/MLAB-project/kicad-mlab Does that mean that the SoC modules referenced there are KiCad designs? On the topic of KiCad and designs related to the EOMA68-A20 cards, it is worth noting that the Olimex A64-OLinuXino board schematic and layout is available in KiCad format: https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/A64-OLinuXino_Rev_D It seems like earlier boards were done with Eagle, but I guess that they made the jump to KiCad in the last couple of years. An important aspect of the above board is the availability of component/footprint libraries: https://github.com/OLIMEX/KiCAD I am not going to argue in favour of KiCad's usability or otherwise, particularly since my computer probably doesn't have the performance to make it work very well, but it was possible to at least play around with the A64- OLinuXino design once I had set up some symbolic links to let KiCad find the libraries. (Also KiCad 5.0.2+dfsg1-1 was needed - from Debian testing - rather than the surprisingly earlier 5.0.0+dfsg1-1 found in Debian unstable.) So perhaps someone who is better at KiCad might have some fun adapting that design. It is open (source) hardware, after all. There were a few people on this list a few years ago who might have given this a go, but I don't know what happened to them. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] EOMA68 Computing Devices Update: 2.7.5 Cards Under Way, NLnet, and Intel Compute Card
On Monday 6. May 2019 02.56.03 Luke Kenneth Casson Leighton wrote: > > not in this case: the application was only rejected because the NLnet > Foundation needed to tick a single box, "you're one person applying > for 2 projects, and we have a 1st-project-1st-application limit of EUR > $50k. is there a 2nd person, living in the EU, who could be the > front-man, for... um EU-bureaucracy-satisfying-political-reasons, > kinda thing?" Well, I don't think I would feel comfortable putting my name on an application just to enable it to navigate the bureaucracy. Although I am familiar with this initiative, I am just like many of the other people on this list who are supporters of it, in one way or another. It would feel dishonest for me to act as a kind of front figure, especially because that is precisely how I would perceive my own involvement. [...] > mmm... again no, not really :) and it's more that you're an > advocate for success, and your reputation in the software libre world, > that matters more. There must be others you have been working with who might satisfy the requirements. I might also add that I am living in an EEA country that is not in the EU. I doubt that this would make a huge difference, but it is still worth noting. Of course, were I living in my country of birth, it would be anyone's guess as to how long I and my fellow residents might have left in the EU thanks to factors beyond my control, but that is another sordid story. As far as reputations go, I don't have any notion of what mine is, besides me writing a fair amount on a selection of different topics. But I would hope that being somewhat independent from particular initiatives might be a part of it. We both have some familiarity with one individual - you more than I, in fact - who had a reputation for frequently communicating with their audience, having some kind of following and far more influence than I might have. But after some unfortunate outcomes with projects, including one which saw $10 go via a crowdfunding platform into a Swiss bank account where it has been resting ever since, we don't hear very much from them any more. (Note that I don't blame that individual for the continuing inactivity of that sum of money, but their reputation has not exactly blossomed as a consequence.) I do want to see this initiative deliver results because this would empower everyone who has been waiting for those results. After all, the initial campaign is, and was always going to be, the start of something more significant. But my role in this initiative is not significant enough for me to act in any official capacity, sad to say. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] EOMA68 Computing Devices Update: 2.7.5 Cards Under Way, NLnet, and Intel Compute Card
On Sunday 5. May 2019 22.02.09 Luke Kenneth Casson Leighton wrote: > > yep :) the good news is, the dev-process issues are resolved, > production just rolls off the assembly line. Great! [...] > btw, i meant to ask you, paul: would you like to be the person that > applies for the NLnet Grant? (and then subsequently acts as the > coordinator)? I'm not sure I'd be comfortable doing so, not least because I don't think I have the skill set for managing something like this, and I also don't have the kind of background for working with grants, applications and the accompanying paperwork. I have worked with people who have been involved with such things in academia, and my impression is that experience with these processes counts for a lot. Maybe there are people you know with more experience with such matters, also with project management experience in the hardware domain, who might be worth approaching. I also imagine that you would really want someone closer to the action than people like me watching the action from several time zones away. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] EOMA68 Computing Devices Update: 2.7.5 Cards Under Way, NLnet, and Intel Compute Card
Hello, Thanks once again for another update on the progress being made with the different boards: https://www.crowdsupply.com/eoma68/micro-desktop/updates/2-7-5-cards-under-way-nlnet-and-intel-compute-card It must be frustrating to encounter production issues (with the Micro Desktop), but I imagine that such things are only avoidable with enough experience of the relevant processes. I suppose that the only way to deal with them is to take the lesson along for next time, pretty much as is noted in the update. Meanwhile, it sounds like the computer cards are waiting for components before being assembled, so we should remain hopeful that their production is more straightforward. It will be interesting to read the next update, certainly. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] TIL: Intel's credit-card sized modular computer is "inspired" by EOMA68
On Wednesday 8. February 2017 01.04.35 Paul Boddie wrote: > > Still, showering the market with products isn't likely to diminish consumer > confusion, is it? Intel's own corporate attention span is as much a threat > to this product as almost anything else. And as anticipated... "It's the end of the line for Intel Compute Cards" https://www.theinquirer.net/inquirer/news/3073050/its-the-end-of-the-line-for-intel-compute-cards Informative quote: "Spare a thought for NexDock, a partner of Intel that spent two years working on software to allow its NexPad computers to work with the Compute Cards, only for Intel to pull the hardware." Details here: "The Tale of NexDock and Intel Compute Card" http://nexdock.com/blog/the-tale-of-nexdock-and-intel-compute-card/ And there was also a cursory review almost two years ago: "Intel Compute Card hands-on review" https://www.theinquirer.net/inquirer/review/3011074/intel-shows-off-computer-card-at-computex-2017 It seems like people were receptive to the idea of pluggable computer cards, but Intel's proprietary technology was always going to threaten the viability of this implementation of the concept. Meanwhile, the NexDock people seem to be pursuing their smartphone docking campaign suggesting that USB-C will be the way that people might attach computer cards to their "docks" in future, however that might work. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] EOMA68 Computing Devices Update: 500 Micro Desktop PCB Assemblies
Hello again, It was nice to see this latest update on the project: "Just a brief update: Mike’s factory has assembled the 500 Micro Desktop PCBs, though the through-hole VGA connectors still need to be hand-soldered on. These are the simpler of the two boards, so all of the Micro Desktops are being done, whereas explained in a previous update, the more complex board, the EOMA68-A20, will only be done in a smaller test run of 100 at first." https://www.crowdsupply.com/eoma68/micro-desktop/updates/500-micro-desktop-pcb-assemblies It must be satisfying to see all of this start to come together. On the topic of casings for the computer cards, I get the sense that there are no ready-made solutions for the outward-facing side of the cards, this despite most traditional PCMCIA/CardBus-profile cards exposing ports of different kinds (such as modems, network ports, like two cards I have from many years ago) and thus having similar requirements. I suppose 3D printing or some other creative casing solution isn't an option. Injection moulding seems to be quite demanding, as the following from the Tomu campaign indicates: "Right now a shop in China is etching the Tomu case shape into one ton of steel. Once that’s done they’ll manufacture a few units to verify the etching works. After this “T0” shot, they will harden the steel tool and start production." https://www.crowdsupply.com/sutajio-kosagi/tomu/updates/design-done-production-started To provide context, the Tomu case is a tiny piece of plastic of around one square centimetre and probably no more than 3mm in depth! Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] EOMA68 Computing Devices Update: New Factory Equipment, New Grant Proposal
Hello, Good to see another update: https://www.crowdsupply.com/eoma68/micro-desktop/updates/new-factory-equipment-new-grant-proposal I hope Mike is bearing up in the face of his recent difficulties. With regard to your funding proposal [1], I see that you wish to revive the other computer cards, and this brought to mind a couple of things I saw recently. One of them was the StereoPi crowdfunding campaign: https://www.crowdsupply.com/virt2real/stereopi The relevant aspect of this is the use of the Raspberry Pi Compute Module as the core of the solution. Previously, the Compute Module was rather "unobtainium", shall we say, but given that Adafruit and the like seem to actually have the latest models in stock, I guess that they are being made and sold to real people. Although things like the StereoPi have developers as their audience, and so it doesn't really bother people that bare boards and edge connectors are the basis of modularity, it would be nice to be able to pitch EOMA68 (and related profile) products for these kinds of things. But these kinds of campaigns do help to demonstrate the case for EOMA68 and modular computing. Another thing that I noticed was in perusing the Dingoonity forums, where there is a fairly active forum about Ingenic-based handheld devices: https://boards.dingoonity.org/ingenic-jz4760-devices/ As the URL indicates, a lot of them seem to be based on the JZ4760, but there was a curious remark about the JZ4770 used in the GCW Zero: "There's no GCW Zero clone. H350 is its presumed internal name. The factory illegally sold prototypes from the initial test runs. Apparently the factory is hogging the last JZ4770 SoCs in existence. So don't expect a third party to jump in and start manufacturing a compatible device." https://boards.dingoonity.org/ingenic-jz4760-devices/gcw-zero-14324/msg184122/#msg184122 Of course, the JZ4770 is the Vivante-based product variant, alongside the JZ4780 (PowerVR-based) and JZ4775 (no GPU). The latter two are still featured on Ingenic's Web site and are presumably active products. Hopefully, there are no availability issues, although one may wonder whether the JZ4760 might be a fallback if there is a glut of those (as evidenced by the continual stream of handhelds) and a shortage of the others. Again, EOMA68 would be a good way of enabling products for this market. People seem to end up chasing discontinued products and settling for random imports, often being disappointed with some aspect of them or other, plus the software is not exactly responsibly produced, either. Paul [1] http://rhombus-tech.net/nlnet_2018/ ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?)
On Wednesday 12. December 2018 19.19.43 Luke Kenneth Casson Leighton wrote: > > On Wed, Dec 12, 2018 at 6:39 PM Paul Boddie wrote: > > > > Although it's not a 64-bit CPU and is MIPS-based not ARM-based, wasn't the > > JZ4775 board almost done? > > pretty much - i just couldn't get beyond u-boot, as i had put a 24mhz > XTAL in rather than a 48mhz, and i couldn't get the PLLs right to get > beyond the SPL loader. Yes, 48MHz seems to be the EXCLK frequency for this particular generation of JZ SoCs: the JZ4780 uses that frequency for the CI20. As for the PLLs, the clock configuration seems to change from SoC to SoC, but they are probably similar, and documentation, kernel and U-Boot support should be out there for perusal. [Dingoo, GCW-Zero, MIPS-based consoles and emulation] > ok - well, i've still got 2 of the cards around somewhere, and i can > order some 48mhz XTALs: i have a heat gun so should be ok to put them > in. > > i have no idea what kinds of volumes to expect. Demand or supply volume? As for demand, it is difficult to say, but I thought some reporting of things from the wider world might help you decide what might be worthwhile doing in future, especially if most of the work is done. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Huge RAM requirements (was: What do 1, 000 EOMA68-A20 PCBs look like?)
On Sunday 9. December 2018 05.07.51 Luke Kenneth Casson Leighton wrote: > On Sat, Dec 8, 2018 at 7:54 PM zap wrote: > > Any plans to use rk3399 for a 2nd revision of the eoma68 standard? or > > any alternative arm processor? Since risc-v is maybe 3+ years out of the > > way? > > yes. bear in mind it's around USD $5k-10k per design effort. i > *may* be able to recover the RK3288 PCB i did. the RK3399 would be > nicer. Although it's not a 64-bit CPU and is MIPS-based not ARM-based, wasn't the JZ4775 board almost done? And didn't it have 2GB RAM already, before the A20 2GB RAM (and HDMI) rework effort? Of course there is the software distribution issue (if you want FSF endorsement), but there seems to be some demand for similar products. I follow the Dingoonity scene at a distance and although there is plenty of gadget chasing - people seem to throw themselves at random handhelds with poor screens and obsolete JZ variants - there are some that still wonder about successors to the GCW-Zero handheld or even getting one of the original ones, particularly as it seems that not everyone managed to receive one in that campaign. The enthusiasm is presumably something to do with MIPS-based stuff being used in various consoles of a certain era. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] microkernels
On Tuesday 11. December 2018 01.46.29 Luke Kenneth Casson Leighton wrote: > > SE/L4. one research group actually created a complete > minimum-compliant POSIX subsystem on top of SE/L4, absolutely nothing > to do with any operating system "per se", and then successfully ported > an entire qt-based webkit browser *and all its dependencies* to run on > it. Was this related to Genode or something else? I know that Genode supports/supported a WebKit browser - maybe Arora - and that it supports a range of microkernels, although the focus seems to be on using their favoured Nova microkernel instead these days [*]. > the "filesystem" was entirely flat. no subdirectories. so when i say > "minimally compliant" it really really was "minimally compliant". That would be an odd decision to make given that it would need to have a filesystem of some kind and that beyond a rudimentary memory-based temporary filesystem, pretty much all of the ones out there have directories. If they'd gone to the trouble of porting a WebKit browser, porting an established filesystem would surely have been straightforward. L4Re has virtual filesystem support, but it seems pretty limited in a number of ways, and the bulk of the heavy lifting needed to support dynamic linking seems to be left to a "rom" filesystem. But even that supports directories. (Of course, L4Re is not aimed at seL4, but there are fairly comparable things for seL4, I believe.) Paul [*] As is increasingly customary with various projects, I hesitate to depict Genode in any particular way, even after digging through the copious promotional/educational materials so that I might precipitate a coherent impression, in case it gets perceived as misrepresenting something or someone. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] Microkernel-based systems (was Re: Reframing The Holy War)
On Monday 10. December 2018 09.02.57 Adam Van Ymeren wrote: > On December 10, 2018 8:48:56 AM EST, Hendrik Boom wrote: > > > >Just curious -- what microkernel systems are available to run on modern > >home computers just in case one is tired of Linux and wanting to try > >something else? > > MINIX and GNU Hurd both exist and work. Hardware support isn't great > however, might not work on the specific machine you have. Dave may have mentioned this previously on this list, but here are his articles about trying out the Hurd: "Exploring Alternative Operating Systems – GNU/Hurd" http://www.boddie.org.uk/david/www-repo/Personal/Updates/2016/2016-08-08.html "Back to the Hurd" http://www.boddie.org.uk/david/www-repo/Personal/Updates/2017/2017-06-30.html He also looked at Inferno, which isn't a microkernel-based system as far as I know, but it has some interesting characteristics: "Exploring Alternative Operating Systems – Inferno" http://www.boddie.org.uk/david/www-repo/Personal/Updates/2016/2016-09-01.html Another interesting general-purpose system is HelenOS: http://www.helenos.org/ This is apparently microkernel-based and should work on modern home computers. My mini-rant a few days ago discussed a tentative revival of the Hurd using L4-related technologies. Although the Hurd eventually got going by using the Mach microkernel (also seen in OSF/1, IBM Workplace OS, NeXTSTEP, Mac OS X, and so on), there have always been things in it that have been regarded as less than satisfactory. As far as I know now, there are certain limitations that conspire to produce pathological system behaviour, and this appears to have been difficult to remedy: https://www.sceen.net/the-end-of-the-thundering-hurd/ The principal reason given for no longer pursuing things like Hurd-on-L4 seems to be that "we already have GNU/Linux" and that device drivers would need writing, alongside the suggestion that people could instead be working on other, supposedly more urgent things. The latter suggestion should be ignored: if someone wants to work on operating system fundamentals, they aren't necessarily going to find working on PDF reader software satisfying, especially if no-one is likely to be paying them for their volunteering, anyway. I'm not going to claim that writing device drivers, driver frameworks, filesystems, and all the other things are easy enough. However, they do seem to get written over and over again, in alternative operating systems (of which there are many if you start looking) and in the Linux world itself. Moreover, it should be a more approachable activity in the microkernel world precisely because drivers are normal programs, not glued-in parts of the kernel framework that are subject to continual churn. My current perception of the weaknesses of various microkernel technologies is that their developers mostly seem to be chasing niches, not general-purpose computing. That may be making some people good money, but it doesn't necessarily help the average computer user. Indeed, with things like Intel Management Engine, it can actually be harmful to users instead. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Reframing The Holy War
On Sunday 9. December 2018 17.24.14 Jean Flamelle wrote: > > Linux's amplifying complexity hampers security. Of course, one could look more closely at microkernel-based systems for a possible remedy. Sadly, ever since the famous Torvalds versus Tanenbaum discussion, plenty of people cling to the remarks of the former as he sought to ridicule the work of the latter, oblivious to the fact that... 1. Microkernel performance was always a tradeoff (acknowledged by the DMERT work done by Bell Labs in the 1970s and in other contemporary work). 2. Performance has improved substantially over the years and in some cases wasn't that bad to begin with, either. 3. Billions of devices have shipped with microkernels. Some people also probably cling to the idea that Torvalds "won" his debate. Now that MINIX 3 runs in every Intel CPU supporting Management Engine functionality, it is clear who actually won, at least in terms of the "bottoms on seats" measure of success that the Linux kernel developers tend to emphasise over things like GPL compliance by vendors (some of those vendors being Linux Foundation members, of course). Paul P.S. I wasn't going to dignify this thread because of the inflammatory terminology used in the subject suggesting some kind of irrational fervour. In fact, demanding and ensuring complete control over the technologies we use is a pragmatic and entirely justified strategy for anyone who cares about their data, their computing capabilities, and even their quality of life. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like?
On Friday 7. December 2018 16.28.24 Wookey wrote: > On 2018-12-07 15:24 +0100, Paul Boddie wrote: > > Cross-building would be a workaround, but Debian appears fundamentally > > opposed to that, > > Do you mean 'as buildds'? I don't know. If that is the way the Debian archive is built then perhaps the answer is "yes". > Debian's support from cross-building has improved hugely over the last 8 > years, and you can now crossbuild a _lot_ of debian. Helmut told me 'nearly > 2/3rds' a while ago, although I'm not sure if that's 2/3rds of _everything_, > or some subset. It is certainly easier to perform cross-building activities, although I will admit that I am not typically cross-building packages these days. I've probably said before that when the cross-toolchains became available, it helped a great deal with the things I tend to do, so I really appreciate them. One thing that I do find frustrating, however, is the trail of pages on various sites (wikis, typically) that describe the state of progress at different points in time. It isn't particularly coherent and undermines the impression of the progress that has been made. > There is lots more that could be done (not least educating upstreams > that like to do 'uncrossable things'), but we are the opposite of > 'fundamentally opposed to it'. Perhaps I should have clarified that Debian appears fundamentally opposed to using cross-building as the means of building the archive for an architecture. I understand that the aim is to ensure that people can run systems that are able to build their own packages, but it seems that we will arrive at a point where the imperfect result of natively-built packages needing to be complemented by cross-built packages will become unavoidable. > > even though the alternative is the abandonment of architectures. And > > you even have the new and shiny arm64 support in jeopardy because the > > appropriate server hardware never seems to get to market (or stick > > around). > > In what way is arm64 'in jeopardy'? I don't think it's going anywhere. Maybe I got the wrong impression from this message: https://groups.google.com/d/msg/linux.debian.devel.release/meYaIZR7Sm0/GtHUxlbGAQAJ I guess that the main concerns are that some arm64 products aren't supporting arm32 (of whichever flavour), that there are lots of "development board" products but not so many "data centre" products, making automation and management difficult. I might also add that when looking at ARM server offerings, they seem to be pretty expensive (maybe to differentiate themselves from existing offerings on traditional server architectures), and it probably doesn't help that companies don't follow through on their roadmaps, meaning that people end up waiting forever for something that might have been a usable product. But maybe there is no shortage of usable arm64 hardware for archive-building purposes and that my perceptions of such shortages for other architectures are also incorrect, too. If so, I stand corrected. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like?
On Friday 7. December 2018 08.49.57 Luke Kenneth Casson Leighton wrote: > On Fri, Dec 7, 2018 at 2:39 AM Julie Marchant wrote: > > And as for 32-bit MIPS... just outta luck, I guess, at least until an > > FSF-approved distro starts supporting it. From what people have said about Debian, I can envisage getting PureOS to work on mipsel. It is just that I haven't dedicated any time to really looking into it yet. > all 32-bit OSes are on the ropes, but not for the reason that most > people think. it's down to the linker phase of binutils *running out > of memory*, due to a default option to keep the object files and the > binary being linked in memory: > > https://marc.info/?l=binutils-bugs&m=153030202426968&w=2 > https://sourceware.org/bugzilla/show_bug.cgi?id=22831 > > unfortunately this is quotes not anyone's responsibility quotes, it's > one of those little-known syndrome / underlying / indirect causes. It is a consequence of people not really valuing the longevity of hardware. A decade or so ago, people still cared about whether GNU/Linux worked on old hardware: it was even a selling point. Now people are probably prioritising the corporate space where you can just request a new laptop with double the memory from your manager and pretend that it was a cheap way of solving the problem. > please please for goodness sake could people spread awareness about > this more widely, try out some very large builds including > comprehensive debug build options, adding the option advised in that > bugreport, and report back on the bugreport if it was successful or > not. It's interesting to search for the suggested linker options... -Wl,--no-keep-memory ...to see where they also came up: https://bugzilla.redhat.com/show_bug.cgi?id=117868 I like the way the reporter gets an internal compiler error. These things, including linker assertion errors which the user shouldn't see, don't seem to get adequately diagnosed or remedied in my experience: you just get told that "you're holding it wrong" and WONTFIX. Still, since 2004 there should be some test cases by now. ;-) I see that you have been working hard to persuade people, though: https://bugzilla.redhat.com/show_bug.cgi?id=117868 It really sounds like a classic database problem, and I wonder what the dataset size is. Of course data processing is faster if you can shove everything into memory, but the trick is to manage volumes that are larger than memory. Cross-building would be a workaround, but Debian appears fundamentally opposed to that, even though the alternative is the abandonment of architectures. And you even have the new and shiny arm64 support in jeopardy because the appropriate server hardware never seems to get to market (or stick around). > *without* that option, the fact that firefox now needs SEVEN > GIGABYTES of resident RAM in order to complete the linker phase (which > is obviously impossible on a 32-bit processor), armhf, mips32, and > many other 32-bit architectures are just going to get... dropped by > distros... > > *for no good reason*. Well, it sounds like the usual practice of greasing up a hippo and hoping that the result will be as lean and as fast as a cheetah. The Web gets ever more complicated and yet many of the tasks we need it for remain the same. Still, the usual advocates of disposable computing would have us continually upgrade to keep being able to do even the simplest things, finding a way of selling us what we already have, as always. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like?
On Thursday 6. December 2018 09.58.51 Elena ``of Valhalla'' wrote: > On 2018-12-05 at 17:40:29 +0100, Paul Boddie wrote: > > Of course, Debian supports everything of interest, but then there has to > > be a process of weeding out non-free packages and content. > > Note that this "process" simply involves not adding the 'non-free' > repository to /etc/apt/sources.list. It's not silently added by default, > the user/admin needs to make an explicit choice to add it. Sorry, I meant in the context of being free enough for FSF endorsement. Otherwise, there would be no need for distributions like PureOS, gNewSense, and so on. Discussion can be had about the FSF criteria, of course, but since Luke is actually seeking such endorsement, the only thing that might be helpful for him is to indicate to him that various FSF concerns are now addressed in the more mainstream distributions, such as there not being random firmware binaries in kernel packages, and so on. Since I don't track what Debian's policy on such things is, bringing any new developments to his attention could be useful and save him a lot of time and effort. I tend to be wary about making any statements about Debian policy these days since it tends to get me flamed by random people. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like?
On Wednesday 5. December 2018 03.38.59 Luke Kenneth Casson Leighton wrote: > > it was quite hilarious to get up and running. > https://wiki.parabola.nu/MIPS_Installation - oh. discontinued. > that's not going to help *sigh*. Yes, it seems that people got enthusiastic when Stallman started using that Lemote laptop, but when he stopped using it, they all dropped MIPS as soon as they could. So, gNewSense and Parabola both supported the MIPS architecture on some level, and Guix still does, I think, although since the Lemote stuff supported mips64el, any remaining support in these distributions is not useful for 32-bit devices, amongst which is the Ingenic SoC that you were looking at. Of course, Debian supports everything of interest, but then there has to be a process of weeding out non-free packages and content. Since your EOMA68 campaign, PureOS has become a candidate for a suitable Debian-based FSF- endorsed distribution (ignoring systemd concerns). If Trisquel hadn't switched to Ubuntu as its base, it would also have been a candidate, but instead it suffers from Ubuntu's arbitrary architecture selection policy. > basically it's a hell of a lot easier if you have a native x86 > parabola install, as you can then use the equivalent of debian foriegn > arch debootstrap, and the --second-stage you run a qemu emulator to > finish off the install. > > that's basically exactly what i did... except because i didn't have > native x86 parabola i ran in qemu. > > it worked really well and makes for a hilarious story. I guess you are able to rely on the existing ARM port of Arch, though. What I found was that for building packages from scratch you have to combine Parabola and Arch repositories, and the mechanisms for doing this are not very coherent. I ended up having to write tools to look up packages in different packaging repositories, first trying one place, then another, and so on. Some of these tools I ran in an appropriate x86 Parabola installation because they won't work in a "portable" way in other environments. What I learned is that there is a considerable difference between genuine multi-architecture distributions and the kind of architecture-and-a-half distribution that Arch seems to be, with Parabola being under that umbrella. I think Arch has already thrown i386 over the side, so I wonder whether Parabola will also have to do so in time as well. Generally, I think that the Arch maintainers make some pretty questionable decisions: switching the default version of Python to version 3 very early on in the 3.x lifespan being one notable example. But having the choice is good for people who can get along with such decisions, I guess. Paul P.S. It is also pretty frustrating that people seem to need Richard Stallman to tell them what to do. When I asked people supposedly interested in porting the Hurd to L4-based systems about such matters, one of the responses indicated that Stallman didn't think that working on operating system fundamentals was worthwhile compared to doing other things. But if something is worth doing, even if not everyone agrees, why does anyone need some kind of "sign off" from someone they've heard of? Just do what you think is right or interesting or enjoyable or useful, already! I honestly don't know why anyone would follow a mailing list on a topic if they didn't already know it was worthwhile. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like?
Hello, Nice to see the progress being made in the recent update: https://www.crowdsupply.com/eoma68/micro-desktop/updates/what-do-1-000-eoma68-a20-pcbs-look-like It's a shame that you have to redo your Parabola bootstrapping. I experimented with bootstrapping Parabola on MIPS a few months ago using two different approaches - (1) try and cross-compile packages, (2) try and native build in another environment - and it was rather frustrating either way. Ultimately, I didn't regard it as a great way to spend my time. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] Latest Update
On Thursday 18. October 2018 06.11.42 Luke Kenneth Casson Leighton wrote: > On Wed, Oct 17, 2018 at 5:29 PM Paul Boddie wrote: > > > > P.S. Still no progress from Crowd Supply on the latest update? > > getting there Thanks for posting this, with it being published yesterday: https://www.crowdsupply.com/eoma68/micro-desktop/updates/test-run-of-100-a20-cards-and-contract-work I am sorry to hear about the hassle with the contracting and the disappointing experience that seemed to result. It is unfortunate that organisations are often incapable of being persuaded to function in a way that would actually serve their best interests. In my earlier consulting days, the mantra "appropriate quality" would be used as an equivalent to the rather familiar "don't spend too much time on it". What results from this is that people then don't do things properly, store up trouble for the future, and then hope that the customer will pay again to make things right. I guess it is an indication of how much of human society operates: put things off, collect the immediate rewards, and leave the mess for others to fix at their expense. A note about Liberapay, though: it seems that they do support other payment providers now. If you can tolerate PayPal (I cannot) then they are supported. The other current option is Stripe. In any case, I hope the test run works out and can pave the way for production and the release of more funds. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Should we support libre.computer's efforts at promoting lima?
On Wednesday 17. October 2018 16.30.17 Luke Kenneth Casson Leighton wrote: > > it depends on what you take into account. if someone else pays the > NREs to the foundry, i.e. a university agrees to collaborate and is > offered access to a foundry for either free or at reduced rates, > $250k-$500k comes off that amount, straight away. Some interesting perspectives on this can be read about here: https://chips4makers.io/blog/startup-costs-and-low-volume-manufacturing.html The author is currently running a campaign on Crowd Supply: https://www.crowdsupply.com/chips4makers/retro-uc Maybe you might have spoken to the people involved, either at FOSDEM or via Crowd Supply, but I suppose there might be some potential for collaboration or discussion. The campaign itself won't get funded, it would seem, but like various others that went the same way, this is more a consequence of a number of different factors rather than it being a statement on the merits of making genuinely free and open silicon. FPGAs and the implemented CPUs are widely available and already in use amongst the target audiences, for instance. However, pursuing such a campaign with a product that really needs to be done with "proper" silicon - needing higher frequencies and power/performance benefits, perhaps - might get more support, albeit from not quite the same audiences as the ones targeted in this campaign. Paul P.S. Still no progress from Crowd Supply on the latest update? ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Schedule Updates?
On Wednesday 12. September 2018 11.13.51 Luke Kenneth Casson Leighton wrote: > > hiya paul, thanks for the prompting: the latest update i wrote just > yesterday, and it doesn't pull any punches. i've had to take contract > work and it's a 100% full-time distraction. the DRAM's fine, new > 2.7.5 samples work great (or maybe it's 2.7.6 i can't even remember). > i'm in europe: i have absolutely no equipment here. > > i have to arrange to get mike a laptop with a remote-accessible > tunnel, so i can copy OSes to it etc. that's going to take time. Sorry for the delay in acknowledging your reply to my earlier message! I guess that Crowd Supply still have your update in the queue, unless the update was published elsewhere and has nothing to do with them. In any case, I hope you are managing to juggle your different projects satisfactorily and will be able to work more closely with Mike again in not too long. Whilst perusing the Crowd Supply site, I saw this interesting news: "Mouser acquires Crowd Supply" https://blog.crowdsupply.com/2018/10/03/crowd-supply-has-been-acquired/ I didn't realise that Mouser already carried Crowd Supply products, but I guess it increases their reach. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] So this is kind of interesting, I thought...
On Tuesday 18. September 2018 14.05.44 Christopher Havel wrote: > https://hackaday.com/2018/09/17/a-1-linux-capable-hand-solderable-processor/ Interesting comment from Olimex: https://hackaday.com/2018/09/17/a-1-linux-capable-hand-solderable-processor/#comment-5108388 In short, the article is referring to the A13, procured from people recycling them from old devices and, I could easily imagine, doing all the usual tricks to pretend that they are new/working/genuine. > A (barely) hand-solderable Linux-able ARM SoC. US$1 each if you buy a full > reel from a questionable supplier According to another comment from Olimex, the original packaging is trays not reels. But it wouldn't be Hackaday if it weren't encouraging questionable commerce and bizarre hacks that are difficult to reproduce and less convenient than doing things in other ways. And there's also the mandatory Hackaday clickbait factor, of course. Meanwhile: http://rhombus-tech.net/allwinner/r8/ The R8, A13 equivalence being noted in other comments on that article, plus the NextThingCo connection. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] Schedule Updates?
Hello,
I was reviewing the last update on Crowd Supply for the EOMA68 campaign [1],
and taking information from that and from discussions on this list, it seems
that the following timeline was being followed:
15th June: Crowd Supply update, prototype tested, DRAM tested and ordered,
HDMI not tested
Late July: DRAM manufactured ("about a month to have the 8 Gbit 1600 MHz
DDR3 x8 RAM ICs manufactured"), assembly begins (working from
"three months after getting the cards back from assembly before
shipping begins")
Late October: "delivery of the first units" (presumably "delivery" is the
same as "shipping", meaning "dispatch" from Crowd Supply)
I hope that things have been proceeding as anticipated. August was a quiet
month on this list, and I imagine that Luke has been very busy with all his
projects, but I wonder if there is any news about whether the DRAM
manufacturer came through, whether assembly could start, whether testing might
have begun (and was hopefully a success), and so on. I imagine that there is
also the awkward matter of getting the boards from China to the US, related
bureaucracy, and other complicating factors.
Anyway, I hope everything is going well, that Luke isn't overworked, and that
I didn't miss something that would have made the current state of the schedule
a bit clearer.
Paul
[1]
https://www.crowdsupply.com/eoma68/micro-desktop/updates/2-7-5-samples-received-dram-is-ok-micro-hdmi-to-confirm
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Campaign Schedule and Future Sales/Products
First of all, thanks for taking the time to reply to my questions! On Monday 16. July 2018 04.38.34 Luke Kenneth Casson Leighton wrote: > [Campaign schedule] > Yes. Mike is being extra cautious, hes ordered the full set of components > now for 1000 cards and 500 mds. This is good to know! I imagine that the other offerings, principally the laptop, are on hold pending further development, however. [...] > > Meanwhile, I noticed that the matter of future sales and products arose in > > another thread, with the intention being expressed that others will be > > producing and selling boards in future. > > More that as the certification mark holder i cannot sell at all to anyone > period and so that automatucally means someone else has to. > > I can barely get away with treating people here as engineering assistants > or something like that. [...] > > "We need your backing for this project and the current Computer Card > > before we can be in an established financial position to properly evaluate > > and bring you these faster Computer Cards." > > > > https://www.crowdsupply.com/eoma68/micro-desktop/updates/product-roadmap [...] > We as in all of us who want this project to succeed. However also i am > taking a liberty and indirectly speaking on behalf of thinkpenguin. I suppose this makes sense. My impression is that since ThinkPenguin is involved, it was a vehicle for them to assess the viability of the exercise for things that they might sell in the future. So, "we" in the specific context of the campaign seems to mean "you and ThinkPenguin" (as one would expect), even if in the wider context it means a group of other people, too. I only note this because the outcome of the campaign only immediately changes the "financial position" of the broader group in saving them the costs of having to prove the concept themselves. [...] > > Although "the point about the A20 running out of time" [1] has been made > > repeatedly since the start of the campaign (this quote being from March > > 2017 in the context of suitable NAND ICs), might it be envisaged that the > > design files be released for the A20 card to perhaps *stimulate* the > > project's development and stability after this campaign concludes? > > Basically yes however the files will need to come with an agreement that > recipients shall respect the Certification Mark which takes absolute > precedence over and above the GPL. > > Complicated. I think that any approach that keeps the design licensing "clean", whilst upholding the liability protection you need with regard to the "brand", would be acceptable. But I don't profess to be able to tell you what you need to do. > > Has there been any constructive interest from anyone to produce more > > boards using this design? > > A couple of companies approached me, also thinkpenguin have always wanted > to stock them. OK. This is very reassuring. From what you have said above and earlier, these companies will have to take control of the production and retailing. I guess that ThinkPenguin, as being part of this campaign, are in a position to do just that without any awkward contractual complications. [...] > > Another thing I found myself considering is the matter of the other cards > > mentioned during the course of the campaign. If they are not going to be > > offered via future campaigns, will they be offered by existing partners > > or collaborators? For instance: > > > > http://rhombus-tech.net/ingenic/jz4775/ > > http://rhombus-tech.net/rock_chips/rk3288/ > > http://rhombus-tech.net/nexell/s5p6818/ > > The 6818 is a tough one. The 3288 i still have to get 2 of the 4 drams > recognised. Rockchip are under NDA with the DDR initialisation so cannot > help. The 4775 i need to replace the 24mhz xtal. I don't want to speculate unnecessarily here, but I suppose that those interested parties mentioned above must have a route to acquiring the rights to produce boards based on these other designs. Indeed, I think this is the core of the confusion: you apparently cannot routinely make and sell the cards while at the same time being the custodian of the certification mark. So, people like me might wonder what all these boards are good for. But it seems that you might be in a position to produce designs that others can make and sell, albeit doing so in a distinct role from that of custodian. Obviously, others might make their own designs eventually, but a selection of initial designs that others might be able to acquire helps to prove the concept. I hope that this is a reasonable interpretation of the situation. Apologies if this has just restated something that was already obvious to most people. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] kuala lumpur airport on way chennai
On Saturday 14. July 2018 13.35.06 Luke Kenneth Casson Leighton wrote: > On way to 9th RISCV workshop in chennai, preliminary slides here > http://hands.com/~lkcl/libre_riscv_chennai_2018.pdf > > Contains links to other talks but not accepted ones. > > Paul Boddie i still owe you a reply to your message. Thanks for the acknowledgement! I recognise that you are very busy, but I felt that it would be useful for the rest of us, and also helpful for you, for you to articulate your plans. My concern, particularly as the specific campaign was always meant to be the first step in something larger, is that the route towards this larger goal is no longer clear to the rest of us. Have a safe journey! Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] Campaign Schedule and Future Sales/Products
I saw the recent response to my enquiry ("EOMA68-A20 Prototype Status") which
was augmented by a campaign update:
"It’s going to take about a month to have the 8 Gbit 1600 MHz DDR3 x8 RAM ICs
manufactured: we’re on the way. [...] All in all, it will likely take three
months after getting the cards back from assembly before shipping begins. That
puts actual delivery of the first units in late October."
https://www.crowdsupply.com/eoma68/micro-desktop/updates/2-7-5-samples-
received-dram-is-ok-micro-hdmi-to-confirm
This new information is much appreciated, and I hope that everything continues
going to plan. Meanwhile, I noticed that the matter of future sales and
products arose in another thread, with the intention being expressed that
others will be producing and selling boards in future.
Now, there may have been some confusion in that other thread because I seem to
recall talk of follow-up campaigns (although these may have been related to
other hardware projects, not computer cards). Indeed, the August 2016 campaign
update about the product roadmap had the following to say:
"We need your backing for this project and the current Computer Card before we
can be in an established financial position to properly evaluate and bring you
these faster Computer Cards."
https://www.crowdsupply.com/eoma68/micro-desktop/updates/product-roadmap
The crucial question in the context of the above is therefore the following:
who exactly is "we"? If not any of the parties behind the current campaign,
who might it be? Here, I can understand some confusion or a mismatch in
expectations.
But in any case, this discussion of future sales and products reminded me of a
number of things, the first of which being the board designs:
"The only exception to this rule to release everything in advance is the PCB
CAD files for the Computer Card. We’re planning to release the PCB CAD files
for the Computer card once sufficient units are hit that ensures any third
party manufacturing runs will not undermine the project’s development or
stability."
https://www.crowdsupply.com/eoma68/micro-desktop/crowdfunding
Although "the point about the A20 running out of time" [1] has been made
repeatedly since the start of the campaign (this quote being from March 2017
in the context of suitable NAND ICs), might it be envisaged that the design
files be released for the A20 card to perhaps *stimulate* the project's
development and stability after this campaign concludes?
Has there been any constructive interest from anyone to produce more boards
using this design? I see that Olimex have recently introduced a variant of one
of their A20-based products using the compatible T2 SoC [2]. So, the A20 still
has an audience and a commercial life, apparently.
Another thing I found myself considering is the matter of the other cards
mentioned during the course of the campaign. If they are not going to be
offered via future campaigns, will they be offered by existing partners or
collaborators? For instance:
http://rhombus-tech.net/ingenic/jz4775/
http://rhombus-tech.net/rock_chips/rk3288/
http://rhombus-tech.net/nexell/s5p6818/
The first two of these had been prototyped, as I recall (and has been
documented), and so I imagine that there is some value in seeing them become
products, subject to economic and technical viability, the latter of which
reminding me of the following remarks:
"The rk3288 is not a low-power chip, and the heat sink supplied (pictured
above), is not adequate for any CPU-intensive activity, quickly throttling
performance when it gets too hot."
https://forum.armbian.com/topic/4614-asus-tinker-board/
(The above is just an acknowledgement of the difficulties of selecting
products, not an invitation to discuss the details.)
Finally, I realised that the current campaign began almost two years ago. I
think the second anniversary of its launch will be on Friday this coming week.
It would be interesting to hear any reflections on the position of this
initiative two years on, whether (and how) the roadmap might change, and what
still needs to be done to bring this modular computing vision to fruition.
Apologies if I missed various updates or announcements that happen to answer
some of my questions!
Paul
[1] https://www.crowdsupply.com/eoma68/micro-desktop/updates/complexities-of-
hardware-progress-and-travel
[2] https://olimex.wordpress.com/2018/06/20/a20-olinuxino-lime-revision-h-is-
now-in-stock-the-oshw-linux-computer-now-support-emmc-and-can-be-produced-
with-industrial-grade-temperature-4085c/
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] EOMA68-A20 Prototype Status
Hello, I don't want to intrude with questions whose answers are already known, but back in January there were estimates of "five to seven months" with regard to "shipping", by which I presume that the final hardware was meant: https://www.crowdsupply.com/eoma68/micro-desktop/updates/eoma68-a20-2-7-5- gerbers-off-to-factory-thank-you-to-everyone-for-the-sponsorship However, there was also the matter of prototypes being made. This was covered in the February update: "We might get lucky and have the PCBs back, if so I will post photographs." https://www.crowdsupply.com/eoma68/micro-desktop/updates/fosdem-2018-shakti- project-tape-out-nearly-done-2-7-5-eoma68-a20-pcbs The March update suggests that the prototypes were still waiting for RAM: "Mike is following up on pricing for Samsung DDR3 RAM, which appears to be available. I want one other guaranteed supply of a completely different RAM IC and I will tell him to go ahead with the 10 samples… but not until we have an absolute guarantee of availability. Then once the samples are done we have a clear and extremely simple and straightforward production schedule to follow." https://www.crowdsupply.com/eoma68/micro-desktop/updates/fosdem-recap-risc-v- update-and-certification-marks The April update made a mention of another source of RAM, but nothing new about the prototype schedule: https://www.crowdsupply.com/eoma68/micro-desktop/updates/ddr3-ram-and-a-libre- risc-v-soc Are there any further updates on this situation? I imagine that the production schedule is more or less "when it is ready", as I have always understood it, but I did wonder whether there had been further progress with the prototypes. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Certification Mark: My hat in the Ring
On Friday 21. April 2017 05.08.22 Luke Kenneth Casson Leighton wrote: > bit too weird, man :) I had a bit of a sketch and came up with this: http://www.boddie.org.uk/downloads/EOMA68/logo.svg A lot of the earlier logos were quite literal and incorporated specific hardware details or tried to communicate "hardware", but I agree with Hrvoje Lasic: "But also keep in mind that logo is about identity, not business model that exist today." So I just focused on the text and tried to redraw it as the graphic itself. Font usage can bring up all sorts of problems in addition to trying to find something that is pleasing to the eye. There are no heavy meanings to be found here. I like the way you can invert most of the letters and read the same thing, so it made sense to turn it into a broadly circular design. Also, circular marks are not unusual. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] microdesktop casework as DXF files for laser-cutting
On Sunday 2. April 2017 23.05.25 Luke Kenneth Casson Leighton wrote: > ok so i've created corner-pieces which will need to be 3d-printed, > they contain slots for the PCB as well as for upright 1.5mm 3-ply > sides. the far corner near the PCMCIA eject button needs some work / > rethinking because there's a cut-out in the PCB. > > the cut-out is basically too far back, and that's lack of iterations / > planning on my part - i'm not doing another revision of the > microdesktop PCB now, not at this stage, so i'll work something out. > > http://hands.com/~lkcl/eoma/kde_tablet/microdesktop_3.png This should be the following, I think: http://hands.com/~lkcl/eoma/kde_tablet/3dcase/microdesktop_3.png :-) Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] AMD considering releasing the PSP
On Monday 13. March 2017 18.13.37 Hendrik Boom wrote: > > > > x86. part-hardware-emulated x86 fine (like the Loongson 3H > > architecture did), non-x86, fine. pure x86: dying and dead very soon. > > Intel already tried that a *long* time ago, with the Itanium. It was > provided with software that emulated the x86. But AMD made a 64-bit > hardware version of the x86 and took over the market because its hardware > outran the emulation on the Itanium, forcing Intel to follow suit or lose > the Windows market. Itanium was something of a special case, being of Hewlett-Packard origins and employing an instruction set architecture that arguably made life more difficult for tool developers. Itanium was a fiasco for quite a few hardware manufacturers who bet big on it being a success, especially those who abandoned their own technologies. Besides, it was said that the big performance gains in the more recent era of x86 were due to effectively delivering a RISC-style CPU and employing an x86 instruction-recoding front-end, although I don't personally have any familiarity with this. There's an interesting remark about such things on the Cyrix 6x86 Wikipedia page: "The 6x86 is superscalar and superpipelined and performs register renaming, speculative execution, out-of-order execution, and data dependency removal. However, it continued to use native x86 execution and ordinary microcode only, like Centaur's Winchip, unlike competitors Intel and AMD which introduced the method of dynamic translation to micro-operations with Pentium Pro and K5." https://en.wikipedia.org/wiki/Cyrix_6x86 > Is the situation different now? With an ARM version of Windows, and > Microsoft's now proven ability to port Wondows to new architectures, quite > possibly. The difference is where the market is. It was arguably the strength of the relationship between Microsoft and Intel that kept both of them dominant in the conventional computing market, and that led to Microsoft's reliance on x86, even though NT was intended for and delivered for other architectures (i860, MIPS, Alpha, PowerPC). But Microsoft has had to adapt to the market and isn't able to define what people want any more in various areas. What matters a lot more now is the power consumption and performance/power ratio. AMD's new processors look interesting, for instance, but there's a big gap between their power numbers and the kind of numbers you see for SoCs being delivered in huge volumes for things like phones. And even Intel's offerings have punished AMD for that in recent years. I imagine that AMD wants to exercise its option to make x86-compatible products as much as possible, given that few other companies are legally clearly allowed to do so, but that could easily make the company oblivious to opportunities elsewhere. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] AMD considering releasing the PSP
On Friday 10. March 2017 17.08.47 Julie Marchant wrote: > Trisquel forum thread here: > > https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-comm > unity > > And this is the Reddit thread where it happened: > > https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_ > radeon_and_other/def5h1b/ > > It would be a good idea to encourage AMD to do this. Who knows? It could > lead us to an x86 EOMA computer card of some sort in the future. ;) Not > to mention, it would just be better for us overall to have AMD on our side. Interesting comment: "Unfortunately AMD is licensing Trustonic's PSP firmware. They do not have the option to open source it." https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/defn8l1/ Of course, this is just one aspect of AMD's technologies, but similar obstacles probably appear along each of the paths towards freedom for all the different things their products provide. Even with all their GPU expertise, they are unlikely to make the technologies transparent because every patent troll and potential competitor might try and sue them over some detail or other. That, unfortunately, is the pact of silence all the GPU vendors adhere to, whether or not the explanation really has much merit. It's interesting that this happens now. I was vaguely aware that AMD had just launched their Ryzen line of products, and was also vaguely aware that they'd been trying to get their Zen microarchitecture out. However, AMD have a history of underwhelming the market in many ways, so it makes one wonder what an appeal to the "community" is all about. One can be cynical and say that companies only appeal to anyone if the market is too tough, and once they're doing fine again, they forget about all their friends in the "community". Still, their stock price has gone up sixfold over the last few months, so maybe I'm not the one to second-guess them. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Olimex is making an "open-source" laptop...
On Tuesday 7. March 2017 03.53.26 Hendrik Boom wrote: > > Are we waiting for the Hurd? I don't know what level you're aiming for with that question, but the Hurd is available today. However, as I noted, a lot of deployments of Linux are being done in microkernel/hypervisor environments, so nobody is waiting for anything, really. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Arm processors
On Friday 3. March 2017 01.47.49 Siarhei Siamashka wrote: > On Fri, Mar 3, 2017 at 12:48 AM, Paul Boddie wrote: > > > > Source: > > https://olimex.wordpress.com/2017/02/07/fosdem-and-teres-i-update/ > > > > Some of that is specific to their laptop, but some of it seems relevant > > to any A64 device. Maybe you could reconcile what the Olimex people are > > saying with what you are claiming. > > I guess, the emphasis was on *all* A64 features. And the mainline kernel > clearly does not support *all* A64 features yet. Sure, it wasn't good enough for a demonstration. But that doesn't need *all* features, either. Yes, I agree that it's not their focus and that they just want to demonstrate the hardware. As people have noted before, it isn't always that helpful if such a hardware- only focus continues through to retail because people can end up with hardware that they cannot support themselves, with software that violates the licensing terms. > Also Olimex people are always saying that they don't do software and > don't have software expertise in-house. The are not the best people > to ask for this information. Well, there was someone who appeared to be "in the know" replying to questions on their blog, so I was rather going off what they were saying. I don't expect the Olimex people to know the details, but I do expect them to know whether they can ship compliant software or not. > > If you have any definitive information to the contrary, particularly > > about the boot0 code that Luke appears to be referring to, please post > > links to it. > > Regarding Luke's claim stated in bold letters, here is the commit in the > mainline U-Boot, which has added the A64 DRAM controller support: > > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=1bc464be1fc559a3f6dc133429 > 7245d5b27b9b57 Thank you for posting this reference. > But the reverse engineered A64 DRAM controller support code existed > in experimental git branches many months before it finally landed > upstream and anyone could try it. I did see this on the A64 page: "U-Boot 2017.03-rc1 saw the addition of the required DRAM init code, so SPL support is now enabled. However this version lacks support for loading the ATF, which limits the usability." https://linux-sunxi.org/A64#Mainline_U-Boot It was found under the empty boot0 section, so I guess one is supposed to read the page like a switch statement in the C programming language or something. > > The linux-sunxi wiki was very vague on such matters last time I checked. > > And yes, I have seen the "mainlining effort" page: > > > > https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix > > It's very good that you have found this page. You can clearly see > many links to the work-in progress branches that are used for > developing various drivers and test them. > > If you don't understand something, you can always join the #linux-sunxi > irc channel on freenode and ask around. Well, I don't track Allwinner SoC support at all, really, but I thought that since we had the opportunity to get to the bottom of this matter, it might be best to ask someone who clearly has information about it. Publishing such information in obvious places is more helpful than having people "ask around", though, because it saves everyone time and reduces their confusion. To that end, I added the following page to the Rhombus Tech wiki so that people have the ability to inform themselves more conveniently on the topic: http://rhombus-tech.net/allwinner/a64/ Naturally, corrections and improvements are welcome. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Arm processors
On Thursday 2. March 2017 22.20.27 Siarhei Siamashka wrote: > On Thu, Mar 2, 2017 at 6:22 AM, Luke Kenneth Casson Leighton > > wrote: > > On Thu, Mar 2, 2017 at 12:49 AM, zap wrote: > > reverse-engineering i have come to the conclusion is a total - and > > > > criminal - waste of time and effort. by the time all features are > > 100% stable it's several YEARS down the line. look at how long ago > > the A64 was released, and the libdram code STILL HAS NOT BEEN > > REVERSE-ENGINEERED. it's 200 lines of code for fuck's sake. > > You are just very poorly informed about the status of A64 support. > And it's quite funny that there are people who believe you rather > than trying to get this information first hand. Well, I posted the results of some enquiries a few weeks ago in the context of the Olimex laptop. Everything sounded very promising until this appeared: "For the moment the only working Linux Kernel which supports all A64 features is the Allwinner Android Kernel. This Kernel is full of binary blobs, but the only one which could be used for demo. Beside the binary blobs many other things are broken, like the power management, different drivers like the LCD backlight PWM, wake up from suspend, eDP converter is not set properly and works just in 15 bit color mode etc etc. We have the hardware for 50 laptops ready (developer edition), but we do not want to ship before we take care for the software. At other hand we do not want to ship TERES I with Android or RemixOS also which are complete with binary blobs and will never be Open Source." Source: https://olimex.wordpress.com/2017/02/07/fosdem-and-teres-i-update/ Some of that is specific to their laptop, but some of it seems relevant to any A64 device. Maybe you could reconcile what the Olimex people are saying with what you are claiming. If you have any definitive information to the contrary, particularly about the boot0 code that Luke appears to be referring to, please post links to it. The linux-sunxi wiki was very vague on such matters last time I checked. And yes, I have seen the "mainlining effort" page: https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] passthrough, a20 and rk3288 cards
On Tuesday 21. February 2017 21.16.54 Eric Duhamel wrote: > On February 21, 2017 3:52:12 AM PST, Luke Kenneth Casson Leighton wrote: > >btw i didn't hear from anyone about the offer to send out > >pre-production cards. > > I'm tempted but I have nothing to bring to the Linux effort; zero > experience hacking or installing the kernel and not much time to learn. I'm probably not the kind of person to bring much to the table, either, but what kind of equipment would one need to actually attempt anything with such a card at this point? I recall various videos with cards being interfaced to things, but they might have involved previous generations of equipment like that "micro engineering board" that was made a few years ago, so it might be useful to know what the practical requirements are for those who are able to contribute effectively in the near future. (Or maybe those people don't need me to ask because they already know what they'll need.) Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] passthrough, a20 and rk3288 cards
On Tuesday 21. February 2017 12.52.12 Luke Kenneth Casson Leighton wrote: > ok so still waiting for the updates to go out from crowdsupply, brief > news in the meantime. > > revision 2.7.2 pre-production test pcb run has been ordered, i will be > assembling those myself, here in taiwan, using my host's equipment. > btw i didn't hear from anyone about the offer to send out > pre-production cards. A couple of people added their names to the end of this page: http://rhombus-tech.net/allwinner_a10/ I don't know whether that's the offer you were talking about, though. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Olimex is making an "open-source" laptop...
On Sunday 5. February 2017 21.27.14 Paul Boddie wrote: > > I actually thought I'd ask about the software in the comments on their blog > post: > > https://olimex.wordpress.com/2017/02/01/teres-i-do-it-yourself-open-source- > hardware-and-software-hackers-friendly-laptop-is-complete/#comment-24787 There's more about the software in the update about the laptop from after FOSDEM: https://olimex.wordpress.com/2017/02/07/fosdem-and-teres-i-update/ "For the moment the only working Linux Kernel which supports all A64 features is the Allwinner Android Kernel. This Kernel is full of binary blobs, but the only one which could be used for demo. Beside the binary blobs many other things are broken, like the power management, different drivers like the LCD backlight PWM, wake up from suspend, eDP converter is not set properly and works just in 15 bit color mode etc etc. We have the hardware for 50 laptops ready (developer edition), but we do not want to ship before we take care for the software. At other hand we do not want to ship TERES I with Android or RemixOS also which are complete with binary blobs and will never be Open Source." So the story is a bit different from the answer I got before, which was here: https://olimex.wordpress.com/2017/02/01/teres-i-do-it-yourself-open-source- hardware-and-software-hackers-friendly-laptop-is-complete/#comment-24795 "You can look at the Linux build scripts at Github and address your software related questions to Linux-Sunxi developers who work on Allwinner devices Linux support, as we are not experts in this field. To the best of my knowledge If you need video with hardware acceleration binary blobs are unavoidable for the moment with A64, but otherwise all other hardware features have sources with no blobs." Maybe they realised that people will be very upset if they have some weird, GPL-violating vendor distro on their new purchase. Meanwhile, on discussions about alternative SoCs, the EOMA68 campaign update describing the different SoC choices got a mention. Since Olimex already make Rockchip-based products, it surprises me slightly that they aren't pursuing that route as well (or instead). Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Logging and journaling
On Thursday 9. February 2017 21.23.19 Jonathan Frederickson wrote: > I agree with Julie here. If you tell users you're providing Debian, it > should be stock Debian (or as close as possible as is needed to > support the hardware). Likewise for every other distro. I agree with Jonathan and Julie here. ;-) Let the distinction between Debian and Devuan be the means by which people choose to run systemd or not. After all, that is more or less the reason why there are two such distributions rather than one. [*] By all means indicate why you do not agree with systemd, but instead of making more work for yourself, may I respectfully suggest that you just let people switch their order from Debian to Devuan if they agree with you now, perhaps not having thought about the matter before? And let people switch the other way (or to something else) if they agree with your view of Devuan and actually want the option of having systemd from first power-on. As for people who agree with you on both systemd and Devuan's attitude towards it, I guess you could just see if this affects anyone who placed an order. Paul [*] There are supposedly improvements in the distribution-building process with Devuan, which I thought could be of interest to various libre distributions - removing unwanted packages and content is what they do, after all - but the documentation isn't that great for any of these distributions in informing what the possibilities might be. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] TIL: Intel's credit-card sized modular computer is "inspired" by EOMA68
On Wednesday 8. February 2017 00.28.39 Luke Kenneth Casson Leighton wrote: > > http://www.mouser.co.uk/pdfdocs/intel-joule-platform-mechanical- descriptor.pdf > > looks completely different Sorry, you're right! I saw something that resembled it, looked at the specifications which do include things like wireless networking, and forgot that they really are putting their Core line of CPUs into the Compute Card, whereas this other thing uses Atom, which one might have thought they'd be using for low power consumption. (I guess it was Atom and AMD's G-series that you very briefly considered for possible EOMA68 applications.) Still, showering the market with products isn't likely to diminish consumer confusion, is it? Intel's own corporate attention span is as much a threat to this product as almost anything else. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] TIL: Intel's credit-card sized modular computer is "inspired" by EOMA68
On Thursday 2. February 2017 00.00.01 Ralf-Peter Rohbeck via arm-netbook wrote: > Just saw this on Reddit: > https://www.reddit.com/r/linuxhardware/comments/5rhuig/til_intels_creditcard_sized_modular_computer_is/ I've been fed adverts for it now, leading to this product page at Mouser: http://www.mouser.co.uk/new/Intel/intel-joule/ Pricing starts at around £150 per unit. I see this as Intel gradually moving back towards what they know. Their embedded boards don't really seem to have been widely picked up, at least in the hacker/hobbyist mainstream (although maybe the Arduino 101 really has sold well), and what started with a higher-end Arduino competitor employing a Pentium-class CPU (Quark) became a 500MHz Atom-based product (second generation Edison) that has now led to this 1.5GHz Atom-based board (Joule). Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Olimex is making an "open-source" laptop...
On Tuesday 7. February 2017 17.17.14 Luke Kenneth Casson Leighton wrote: > > On Tue, Feb 7, 2017 at 4:01 PM, Jonathan Frederickson > > > > Sure, but is that a result of the hardware actually being that > > different or is it just because manufacturers aren't actually > > upstreaming their code? In the latter case, everyone would have to > > keep rewriting driver code, but not because it doesn't already exist - > > just because they can't cooperate. > > it's a byproduct of the N (designs) times M (processors) problem. > Fabless Semi A flatly refuses to mainline their kernel because it > costs them too much time and money to do so, passes it OEM B who just > compiles it maybe makes a few (GPL-violating modifications) and chucks > product out the door. Interestingly, although Ingenic (mentioned earlier) have always seemed to target older kernels - you can't really blame them if it's what their engineers know, they can get stuff out the door easily, and the Linux speedboat is not exactly their fault, anyway - at least they released all the code, and the various jz47xx SoCs appear to be supported pretty well in the mainline, thanks to various people forward-porting those code drops. (I recently promised to test mainline kernels on the Ben NanoNote, and I mustn't forget to get back to that.) So although there's limited libre operating system distribution support for those SoCs, mostly because of a lack of commitment from those distributions, fuelled by a perceived lack of available hardware to build them natively, the kernel support is probably pretty good. Of course, you can't guarantee that stuff won't be thrown out of the speedboat, but the situation has been surprisingly good for a couple of years at least, I'd say. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Olimex is making an "open-source" laptop...
On Tuesday 7. February 2017 15.29.59 Matt Campbell wrote: > On 2/7/2017 8:19 AM, Paul Boddie wrote: > > Plus, I don't really see Linux-the-kernel as the future, anyway. > > Why not? It has such momentum now; it would be a lot of work to port all > the drivers to anything else. There's so much hardware and software churn these days that the driver availability argument probably isn't as important as it once was. So much stuff is probably being done for individual products that people are undoubtedly having to write code for new hardware, anyway. I guess Linux still has the advantages of being something people know and having driver frameworks that people can use. However, various driver frameworks inside Linux seem to have changed over the years, hopefully for the better, meaning that unless the drivers of interest are on the speedboat (and maybe they were but fell off the back at some point), they're unusable now. Linux doesn't have a monopoly on such frameworks, though: there's nothing to stop other solutions offering something much better. Meanwhile, all the bravado about monolithic kernels being best and there being no tolerance for any performance decrease whatsoever (not even 15% or whatever the number was) seems absurd in this age of endless exploits and after-the- fact mitigations, with a lot of Linux deployments being done on top of microkernels/hypervisors now, anyway. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Olimex is making an "open-source" laptop...
On Tuesday 7. February 2017 15.01.51 Stefan Monnier wrote: > > Not only that: if the machine doesn't run a vanilla Linux kernel, > there's a terribly good chance that 3 years down the road, you'll still > be stuck with the same outdated kernel. Right. Even when vendors actually release the corresponding source code and don't drop in binary blobs, due to the phenomenon I call "the Linux speedboat", if they've forked an old kernel and done things their way, and if someone doesn't get on the case immediately, there's the unenviable task of forward-porting that code to whatever it is that the Linux kernel developers happen to like today. If the vendor didn't manage to throw their code aboard the speedboat at the right time, everyone is left floating in the wake. An example of this that Luke mentioned before was the Skytone Alpha netbook which has an Ingenic SoC that just happens to be the one that there really is no documentation for, although assumptions can be made that it is similar to others that are documented publicly. You can get the sense of how things are by going through the sources for the shipped *2.6* kernel derivative, but it's an exercise in itself to figure out how all that should be redone for today's kernels. Maybe such forward-porting is not too hard: I actually had a go, not being a kernel hacker, but I didn't sense any genuine interest from anyone who might be better equipped to help such work along. Shinier things take precedence over sustainability and longevity for such people, I guess. Add in weird bootloader and kernel init tricks and you have to be fond of kernel hacking to be bothered. Plus, I don't really see Linux-the-kernel as the future, anyway. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Olimex is making an "open-source" laptop...
On Sunday 5. February 2017 20.25.42 Luke Kenneth Casson Leighton wrote: > > On Sun, Feb 5, 2017 at 7:11 PM, Christopher Havel wrote: > > > > Basically, I'm saying, it might not be the whole journey to a truly > > open-source system -- but it's a step in the right direction and should > > be recognized and (to an extent) applauded as such. At least they're > > /trying/. > > he's being supported (financially) by people who also don't quite > fully understand the ethical consequences of their decisions and > actions. and that's fine. collectively they're perfectly entitled to > "explore that space". I actually thought I'd ask about the software in the comments on their blog post: https://olimex.wordpress.com/2017/02/01/teres-i-do-it-yourself-open-source- hardware-and-software-hackers-friendly-laptop-is-complete/#comment-24787 I'm guessing that Thomas, the guy responding, might be the guy from Free Electrons, but maybe it isn't. Nevertheless, he seems knowledgeable about the state of play with the A64. (Not that you'd get a particularly coherent message by looking at the linux-sunxi wiki.) I guess that the sticking point is arguably the "software isn't our problem" attitude, which allows people to claim that something is "open source" (or "software hacker's [sic] friendly" in this case) and then retreat from substantiating the claim. It will be interesting to see if Olimex supplies SD cards with images on them and what kind of source code you can get. They appear to provide such cards for their other products. Given the post-sales problems with various SoCs and boards, actually delivering a top-to-bottom Free Software distribution should be the minimum just to demonstrate any particular device's credentials in the "openness" department. That's not just an ideological requirement but very much a practical one: no-one wants to have to troubleshoot, say, an overheating system because the software support involves proprietary pixie dust that may or may not be available. Anyway, look after yourself out there, Luke! Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] Logos
On Monday 30. January 2017 14.33.46 Julie Marchant wrote: > On 01/30/2017 05:25 AM, Alain Williams wrote: > > Unfortunately that is not good enough ... you are assuming that people > > will use the monchrome version of the logo rather than just photocopying > > the colour one on a monochrome copyier. > > You can easily prevent that with a trademark policy... and why would > someone choose to make their own half-baked monochrome conversion when a > proper one is available? People are lazy. Have you never seen anyone copy-paste the first image they found on the Internet into a Word document and then send it around? People even manage to do this for materials they have full access to, as in there will be a bunch of properly-done logos all made ready (at great expense) on some shared disk or intranet site, and yet someone will still just take the shortcut of grabbing the nearest low resolution bitmap from Google, drag at the corners of it in their Word document, and then, "What do you mean by the vector/big/small/monochrome/greyscale version?" At a former employer, the work done on the logo to specify the colours and profiles was possibly some of the best work I saw done at that company. Shame the logo wasn't very good, though. Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] Mini-PCIe and other interfaces (was Re: Intel at CES)
On Thursday 5. January 2017 22.30.42 Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > On Thu, Jan 5, 2017 at 7:06 PM, Alain Williams wrote: > > About 30 seconds in on the BBC video you get a quick view of the hole. > > ah! that looks very much like Mini PCIe. which has USB and a > one-lane PCIe on it, a few GPIOs and I2C. 50 pin. if that's what > they've picked it's not a bad choice. Mini-PCIe rang a bell, and then I suddenly remembered the following unrelated product from before the Christmas vacation: http://globalscaletechnologies.com/p-72-marvell-espressobin.aspx I actually found it via here, originally: https://wiki.debian.org/InstallingDebianOn/Marvell/ESPRESSOBin Which may mean that some of the Debian-on-ARM people are familiar with it. The Mini-PCIe connection is that this board actually supports that interface along with SATA and multiple network ports, which is pretty unusual for a low-cost single board computer. What might be more interesting in the context of EOMA68 or related standards is the SoC, the Armada 3700: https://github.com/MarvellEmbeddedProcessors/main/wiki/Armada-3700 Despite very odd usage of the word "proprietary" on that page, it appears that the documentation and software is pretty transparent, although I haven't dug into any of this myself. Sorry if this is tangential or got mentioned before! Paul ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
[Arm-netbook] systemd dependencies (was Re: new development laptop needed, looking at dell xps 13 9350)
On Thursday 8. December 2016 16.00.56 Julie Marchant wrote: > On 12/08/2016 09:25 AM, Paul Boddie wrote: > > I don't want to get into an argument about systemd, but one way of > > detecting systemd would to be for things to test for a file that always > > gets installed as part of the systemd packages. This file could even > > have zero content and be explicitly added by the package maintainers (if > > the systemd people kept renaming everything), and nothing would ever > > need to link to anything. You could call this magic file libsystemd.so > > if you wanted, and it could actually be libsystemd.so if you really > > wanted. That would be a very Unix-like way of dealing with this. > > That would not be a portable way to do it. Very bad idea. What if the > system you're on uses that directory for something else? It could be > that it just has to not support systemd at all. Or what if that turns > out to be the file name of something else? You can make this unlikely, > but not impossible. We're talking about distributions where the package maintainers get to decide where everything lives. So, if the systemd packages were installed and configured, there would be a file indicating that systemd is available. Indeed, the Debian configuration mechanisms may well be able to provide such information anyway, so an alternative could involve running one of the Debian tools to determine what the init system is. Obviously, I'm only talking about Debian here: other distributions would have their own mechanisms. It would be distribution policy to not let such files be populated by other packages. When people advocate abandoning distribution tools and using all the different language- and system-specific tools for distributing software instead, they often overlook the value provided by things like distribution policies, whose aims are to make sure that everything works together. The approach described above relies on Debian policy and tools to have a chance of working. Similar caveats apply to other distributions. > And how would it be Unix-like? OK, I'm much younger than Unix and only a > video game programmer who mostly uses Python, so maybe this is just > because of that, but I have never heard of any Unix-like system telling > programs about its capabilities by having or not having a particular > file. Usually you use a simple function for that. Checking for the > existence of a particular file would be esoteric. I'm also younger than Unix. :-) What form would this "simple function" take? If it is a Python function, it has to be implemented by a module which in turn needs implementing using a file. Similarly, a C function would need to be implemented in a library which in turn needs implementing using a file. All I'm saying is that demanding a specific link dependency is needless overengineering when a well-managed system could just permit a test for a file instead. Not everything is written in languages that like to link to random shared libraries: doing things in shell scripts is often sufficient, hence my remarks about the absurdity of shared libraries being the point of integration when an actual executable (for example, xdg-open) is the better choice. (I seem to remember people actually saying that if you wanted to use their special libdesktopopen thing from a shell script, you'd need to write a one-off C program to link to it yourself, reproducing an executable that they didn't want to see provided themselves.) And the use of files to direct behaviour is definitely Unix-like, directing the evolution of Unix-inspired systems like Plan 9, even though they haven't proven as popular (but in many respects that has little to do with the chosen paradigm itself). Things like the system/device filesystems provided by Linux are definitely inspired by this supposed Unix tradition. > Of course, that's all assuming you don't need to link to libsystemd, > since that's something you decide at compile-time, not at runtime. If > you need to link to libsystemd anyway, then the whole idea is pointless. I thought the issue was that a load of packages had unconditional libsystemd dependencies because they might need to test for systemd. Of course, if they want to use systemd, they'll need libsystemd, but otherwise they appear to be burdened with a chunk of functionality that they might only want to test for. I don't see generic mail handling programs having unconditional dependencies on, say, postfix just to test whether postfix is running (example [*]), so why one would need such a specific dependency in the case of systemd is rather mysterious. Then again, I haven't followed all the politics around this. [*] https://packages.debian.org/jessie/mailagent Apologies if people don't want to read th
