[Arm-netbook] NLNet Proposal Draft
Luke, Here is what I've hammered out. It looks like the proposal process must have changed. They seem to want a lot more detail! Richard Thematic call:NGI Zero Core Contact information === Your name (max. 100 characters) Richard Wilbur Email address richard.wil...@gmail.com Phone number 1-406-589-4228 Organisation (max. 100 characters) ??? Country United States of America General project information === Project name (max. 100 characters) ??? Deliver EOMA68 Website / wiki(I guess I should make a page on the rhombus-tech.com wiki for this proposal?) Please be short and to the point in your answers; focus primarily on the what and how, not so much on the why. Add longer descriptions as attachments (see below). If English isn't your first language, don't worry - our reviewers don't care about spelling errors, only about great ideas. We apologise for the inconvenience of having to submit in English. On the up side, you can be as technical as you need to be (but you don't have to). Do stay concrete. Use plain text in your reply only, if you need any HTML to make your point please include this as attachment. Abstract: Can you explain the whole project and its expected outcome(s). (you have 1200 characters) The "Deliver EOMA68" project aims to deliver on the goals of the EOMA68 project (reducing E-waste, respecting computer users’ freedom, and reducing energy requirements for fulfilling users’ computing tasks) by delivering the hardware to the customers. Specifically, this project aims to develop: 1. A test software load for already assembled CPU cards that will qualify them for delivery to first 100 customers. 2. A hardware-software test bench to fully exercise the capabilities of the CPU cards in order to provide feedback to manufacturing (~1000 CPU cards) and facilitate repairs. 3. A hardware-software test bench to fully exercise the capabilities of the Micro-Desktop cases in order to provide feedback to manufacturing (~600 Micro-Desktop cases) and facilitate repairs. 4. A new revision (v1.8) of the Micro-Desktop to solve observed issues in power supply stability and standards compliance. 5. A new revision of the CPU card with run-time configurable interfaces made possible by incorporating an FPGA. Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions? I have been active in the EOMA68 mailing list and I guided the redesign of the micro-HDMI signal path and connector layout for the current production version (v2.7.5) of the EOMA68 CPU card. I proposed new circuits for the next version (v1.8) of the EOMA68 Micro-Desktop. At other times in my career I have worked on the design of circuit board layout for high frequency signals, programmable logic design, boot-time and run-time test software, board and processor bring up/first boot, and debug and repair of analog and digital circuit problems. I have taken an idea through solder-less breadboard prototype, PCB prototype, an initial production of commercial product, revised to greatly reduce production costs, increase functionality. Requested support Requested Amount 5 (5000 to 5 in Euro) Explain what the requested budget will be used for? Does the project have other funding sources, both past and present? (If you want, you can in addition attach a budget at the bottom of the form) Support Richard Wilbur's development efforts Fabricate and assemble CPU Card and Micro-Desktop case test benches. Purchase test equipment: oscilloscope, signal analyzer, bench supply, function generator Fabricate and assemble prototypes of revised CPU Card and Micro-Desktop case Explain costs for hardware, human labor (including rates used), travel cost to technical meetings, etc. (This starts to sound like we need full estimates and not just IDEAS!) Compare your own pro
Re: [Arm-netbook] What's new at the end of 2023?
On Tue, Nov 21, 2023 at 12:53 PM Luke Kenneth Casson Leighton wrote: > > On Tuesday, November 21, 2023, Richard Wilbur > wrote: > > I would need some hand holding with the application process. > > i have *10* applications online now, you can see how obvious > they are. the tasks (milestones) come later. first thing > is "notes on why you want to do this", and seriously if > you take longer than 30 minutes something is wrong. Where are those 10 applications? I am interested in taking a look at them. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk Configuration, options, subscribe and unsubscribe at: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to: arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] What's new at the end of 2023?
On Tue, Nov 21, 2023 at 1:24 AM Luke Kenneth Casson Leighton wrote: > > folks if you would like to get paid for sorting this out > NLnet is very keen to have people put in grant applications > of EUR 50,000. a BRIEF summary of an IDEA is all that is > needed, spending more than 40 minutes on writing the application > is more than needed. For developing the tests for the current cards? > funding the next revision EOMA68 Card would be fantastic, > i suggest one with an FPGA, using the popular ECP5, based > on the ulx3s. > > also fixing mcrodesktop 1.7 > > richard? I am definitely interested in this effort. Having some grant money to help with design, prototyping, and testing would be especially useful. > deadline for next application dec 1st. I would need some hand holding with the application process. By the way, are the mentioned NLnet funds available to U.S. citizens like me? Can I apply for the grant? Sincerely, Richard ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk Configuration, options, subscribe and unsubscribe at: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to: arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] What's new at the end of 2023?
On Thu, Nov 9, 2023 at 1:30 PM Pablo Rath wrote: > As we have discussed in January (2023) on this list I have a working > boot-image fullfilling the minimal requierements (U-Boot, Linux Kernel, > Debian root image on UART console) somewhere on my hard drives. > Andreas Grapentin and I have broken hardware. I don't know if Andreas > made any progress at repairing his hardware. Sorry about your busted hardware. > So my question is: "Can anyone with working hardware test and varify my > boot-image before we send it to Crowdsupply?" > This is the crucial step right now. We can ice the cake later once 100 > cards get released into the world. > > Richard, am I correct that you have a working computer card and a > microdesktop in you possession. Are you willing to set it all up and > test my boot-image? I have an untested computer card (v1.7.4) and microdesktop (v1.?, I've got to lay eyes on it to verify the version). I am interested in setting it up and would be happy to test your boot-image. (I'm also interested in being able to generate a boot image from source. Do you have notes on how you built it?) I'm a few days away from being able to set things up, I believe. Then I can try things out, verify that my computer card works and try out your boot image. After that we can send the boot image to CrowdSupply. When I can lay my hands on an oscilloscope, I intend to carefully/gingerly test my microdesktop board. I get the impression from what others have written, there's a pathology with either the pcb layout or the assembly around one of the regulator chips. So I'd like to observe it misbehaving without burning anything up. Richard ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk Configuration, options, subscribe and unsubscribe at: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to: arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] What's new at the end of 2023?
On Wed, Nov 8, 2023 at 3:12 AM Luke Kenneth Casson Leighton wrote: > if someone, even one person, gets them a test image, 100 people > can get their cards. Have we distilled the requirements for a test image down into a document anywhere? Namely, lists of what is required and what would be good or nice to have under explicit headings? If not I'll be happy to start a wiki page. Looks like we need a build of uboot and the kernel + test software to exercise the interfaces we want to test. Possibly with automated gathering and interpreting of results to speed the logging and repair of problems. Sincerely, Richard ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk Configuration, options, subscribe and unsubscribe at: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to: arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] next step is a boot image
> On Jan 12, 2023, at 05:55, Luke Kenneth Casson Leighton wrote: > > yes this one is a cross-compile. there are extra prefix ENV vars to > define to get it to work. Is there a page describing/documenting how to set up the cross-compile tools and environment (or at least which target architecture to use)? Is there a page discussing which kernel source (+patches) supports this board. Sounds like we might want a page covering the status of support for different hardware/CPU features (if it doesn’t already exist). ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk Configuration, options, subscribe and unsubscribe at: 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 Nov 23, 2022, at 21:34, Luke Kenneth Casson Leighton wrote: > > https://www.theverge.com/22599932/bitcoin-raid-keene-new-hampshire-ian-freeman-libertarian-prosecution Thanks for the link. Looks like a messy situation but I didn’t see any indication that Mr. Waid was arrested or prosecuted. I get that bad things happened to some of his friends but how does that affect his ability to test EOMA processor cards or communicate via E-mail or telephone? ___ 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] Green (literally photosynthetic!) technology to team with EOMA-68
EOMA-68 seems uniquely positioned to benefit from this type of technology! Low-power, long-endurance designs could make some pretty cool applications. “Algae-powered energy cell can keep a microprocessor running around the clock anywhere with sunlight” https://www.zmescience.com/science/algae-powered-energy-cell-can-keep-a-microprocessor-running-around-the-clock-anywhere-with-sunlight/ ___ 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 Sun, Jul 26, 2020 at 2:31 PM Pablo Rath wrote: > > >On Sun, Jul 26, 2020 at 10:54:27AM +0100, Luke Kenneth Casson Leighton wrote: > >> On Sun, Jul 26, 2020 at 10:33 AM Pablo Rath wrote: > > > > > > I am very sorry to inform everyone on this list that I had a severe power > > > problem with my Micro Desktop 1.7. > > > I applied power to the DC Jack and the area right to the jack burned > > > out. (see attached picture). > > > > thank you for sending this to the list, as i asked, after you sent it > > initially privately. i had this happen to a 1.5 MD board 3 years ago, > > but no others, despite them running for prolonged periods of time. > > > > what i noticed about that board was that the inductor was not properly > > soldered down. this would be insufficient contact, introduce > > resistance, and at that point the RT8288 would go unstable. > > Ok. As you have probably deduced from my questions I am not really into > hardware. Thank you for all your explanations and clarifications. > I still try to wrap my head around what should work straight away, what > could work with the right modifications and what can never work... > > [...] > > > > As I said I am very sorry that I screwed up. > > > Luke, do you have any ideas what went wrong? > > > > not in the slightest. or - maybe: have a look at the contact points > > where the inductor sits on the PCB. there should be quite a lot of > > solder, there. > > Sorry for the dumb question but where can I find the inductor? Without the assembly drawing at my fingertips this would be my educated guess. It’s the closest component to the offending regulator IC that looks the part of an inductor. [see attached picture] I am going to check my mini desktop PCB for good solder on the inductor. I will also look at possible modifications/improvements to that feedback circuit layout given the present PCB layout. (I have some experience with specifying rework/changes to remedy deficits in already-fabricated PCB’s.) Best wishes, Richard ___ 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...
M$‘s move certainly seems monopolistic in nature. I’m a little surprised they were able to twist so many arms (AMD and Intel?) so hard! And I’m surprised that anyone in the SoC market would seriously dedicate their processor to running a M$ OS. Thanks for the link to the Open Titan site. It looks like a step in the right direction. I wonder if libre-soc could liberate the 4 remaining blocks still marked “proprietary” (Foundry IP, Analog IP, Physical Design Kit, Chip Fabrication) and create a “libre-titan”? I guess an underlying question is, “Do we have a need to lock everything down that tight in a libre-soc system, since we are designing it from the ground up to avoid many of the exploits inherent in the AMD and Intel architectures?” Richard ___ 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] Any progress?
> On Sep 18, 2020, at 07:09, Luke Kenneth Casson Leighton wrote: > […] > i got up and running on an FPGA a couple weeks ago > (Versa ECP5) > https://www.youtube.com/watch?v=72QmWro9BSE Congratulations on the success of booting the libre SoC on FPGA. Which processor instruction set architecture are you folks using? Looks like the toolchain for that FPGA has a free/libré license?[*] Did I misread the Lattice Semiconductor announcement? If it’s really free/libré I might have to save my pennies for one of those boards! Sincerely, Richard Reference: [*] http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/ECP5VersaDevelopmentKit.aspx ___ 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] OpenPOWER virtual coffee continues every Tuesday UTC 22:00
Sounds like a neat group. What should I study up on to get the most out of the discussion? ___ 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] Free ASIC fab. for open designs
> On Aug 25, 2020, at 14:57, Luke Kenneth Casson Leighton wrote: > > On Tuesday, August 25, 2020, Philip Hands wrote: >> >> It seems that is a 130nm fab, based in the USA somewhere. > > yes. > > it is around 25 sq mm and an 80 pin QFP fixed package. Very nice! That sounds really cool from the perspective of someone who got a big kick out of VLSI Design class but never had the budget to run a personal design through to packaged dies. 80 pins and 25 sq mm at 0.13μm with free digital and analog cell designs. Now, I wonder how quickly the free toolchain will solidify? ___ 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 Jul 21, 2020, at 13:29, David Niklas wrote: > > On Tue, 21 Jul 2020 04:31:43 +0100 > Luke Kenneth Casson Leighton wrote: […] >> if you want to know more then do join one if rhe virtual coffee calls >> >> https://openpowerfoundation.org/openpower-virtual-coffee-calls/ > > :cry: > Another Zoom conference. Proprietary executable. Known spying company. > Why luke, why do people always have to choose the worst of proprietary > stuff? > > https://nypost.com/2020/04/10/chinese-spies-are-trying-to-snoop-on-zoom-chats-experts-say/ > https://medium.com/swlh/zoom-are-you-spying-me-7c07feebf85 > > We have linphone, ekiga, not to mention the myriad of stuff on shareware > sites ( Here's a good one I know from my windowz days > https://www.freewarefiles.com/ ), if it must be proprietary. > We have IRC, Jabber, Argh! So much good stuff! > Conferencing stuff (not all FLOSS, but still a lot there): > https://www.ubuntupit.com/top-20-best-linux-video-conferencing-software/ What about Jitsi Meet? https://jitsi.org/jitsi-meet/ Free Software Encrypted Anonymous Free Service ___ 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] Fixing the fex file once and for all
Thanks, Luke. Looking forward to following your instructions next week after I'm back home. On holiday in a different timezone right now. ___ 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] Fixing the fex file once and for all
On Thursday, July 18, 2019, Luke Kenneth Casson Leighton wrote: > > > honestly, just other people helping out - *actually* helping out with > u-boot, linux kernel etc. - would be a huge relief. > I've been itching to get involved since I picked up my prototype in England but waiting (too patiently? Should I have bothered/reminded you about it earlier?) for the video how-to you promised to make on how to non-destructively plug the unenclosed CPU card (without the guides) into the micro-desktop case. Would the cable-only setup be a valid way to get started? Should I expect the micro HDMI plug to be alive? I guess the earliest debug output (u-boot?) will likely be on the serial console available through the EOMA68 connector. ___ 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
> On Mar 27, 2019, at 11:59, Luke Kenneth Casson Leighton wrote: > > the existing plastic comes as-is. making *any* changes would require > a minimum of around USD $20k in design and injection-molding costs. Yes, that's prohibitive when you are on the wrong side of out of money! >>> as a result we considered very thin metal sheet (thick foil in >>> effect) that could be stamped (or laser cut) and was effectively a >>> "metal sticker" that could go over the end and be bent round. >>> probably even by hand. >> >> Did you try the foil? How well did it work? > > no - just a design idea. shelved for the first Cards as there's > insufficient funds. can always send them out later. Any idea how much it would cost to test the idea? ___ 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
> On Mar 27, 2019, at 06:21, Luke Kenneth Casson Leighton wrote: > >> On Tue, Mar 26, 2019 at 11:52 PM David Niklas wrote: >> >> On Sat, 23 Mar 2019 16:56:25 + >> Luke Kenneth Casson Leighton wrote: >> >>> >>> not a snowball in hell's chance. resin is too brittle, 3D printing >>> is far too inaccurate, and the plastic is extremely thin. 5 years ago >>> the ones we had stamped out for prototypes (laser-cutting i believe) >>> broke almost immediately. >>> >> >> What material did you laser cut? I would have thought that laser cut >> aluminum would be perfect. > > ten prototypes of the mass-produced PCMCIA plastic surround from > Litkconn had holes laser-cut to make space for the micro-sd, > micro-hdmi and USB-OTG ports. > > the result was plastic under 1mm deep that had only around 0.5mm > height below e.g. the micro-sd card and it of course snapped > immediately. Sounds like a more flexible plastic is needed but that clearly impacts the manufacturing processes available and thus the cost. > as a result we considered very thin metal sheet (thick foil in > effect) that could be stamped (or laser cut) and was effectively a > "metal sticker" that could go over the end and be bent round. > probably even by hand. Did you try the foil? How well did it work? ___ 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] Free the (Intel) FSP?
This looked interesting--like Intel is starting to feel pressure from RISC-V, et cetera. Regardless, I'm still very interested in security, efficiency, configurability, and other aspects of libre design of RISC-V. https://www.phoronix.com/scan.php?page=news_item&px=Intel-Open-Source-FSP-Likely ___ 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 v1.7
Here's the circuit diagram-scribbled on a piece of paper with pencil. Photo shot with phone camera and cropped and scaled down in GIMP. If it needs to be larger to be readable, I still have the original so can rescale as needed. ___ 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 Sep 21, 2018, at 20:02, Christopher Havel wrote: > […] Interesting economic scenario. I think it works best when the arbiter of the exchange rate for goods is impartial. Otherwise the exchange rate would be influenced by biases. > if I've got my math right (sorry, I'm severely math-challenged -- to the > level of > having some sort of otherwise-unnamed "math fluency disorder" that I was > labeled with in grade school... the gist is that I understand the > *concepts* on actually something of a slightly advanced level, but I can't > manage the actual *exercises*, real-world or textbook, without a > half-decent calculator). In this case, the arithmetic associated with your example seems to work out fine. Maybe you've outgrown the "math fluency disorder"? In my recollection it seems boys' brains mature later and I know there can be significant individual variation in the timing. > Alternatively, in a less-regulated society, we'd haggle for a while and > figure out for ourselves what eggs and cheese should be worth -- although > that somewhat sidesteps the need for standardized units altogether. This avoids the bias of a government official--exchanging that for the biases of each potential customer. > Of course, that one guy who only has stuff that absolutely nobody wants, kinda > gets into a bit of trouble in a barter economy... the conceptual system is > not without its flaws. But, hey, that's true of everything out there, so... > I dunno. /shrug That guy goes bankrupt if he doesn't adapt to the market demand in capitalism. Sincerely, Richard ___ 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] HDMI Player Stick as DRM-free Merch Alternative
On Jul 22, 2018, at 15:11, Jean Flamelle wrote: > > Encourage copying, modifying, as well as redistributing the content. By this do you mean an unencrypted output over HDMI (without HDCP in other words)? > However build a culture of the 'Unpause-able Player Stick': How do we "encourage copying, modifying, as well as redistributing the content" from an 'Unpause-able Player Stick' that has "air-gap" security? Who can copy, modify, or redistribute the content? What is the utility of making it 'Unpause-able'? That was always one of the advantages I saw to having user control: you can adapt the viewing experience to the realities of your life. It seems to me that a lot more variety of materials will be required to make one of these sticks than an optical disc which is mostly one type of plastic. That would seem to make the stick more difficult to recycle than the disc. If the stick can't be loaded with new content, then its use cycle will be closer to a non-rewritable optical disc. What if we created an open video format that allowed sections of a work to be attributed to the original author/creator? Sort of a digital credits meta-data list. Could also be useful for still images, audio, and possibly other media. A method to identify some portion of the whole work and record attribution information. Editing tools would be very useful in managing this data. ___ 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] HDMI Player Stick as DRM-free Merch Alternative
> On Jul 22, 2018, at 16:48, Jean Flamelle wrote: > > The device being airgapped so that the only input is power, should > socially suggest that one can't be tampered with or forged (i.e. by > extracting a signing key). One fly in the ointment is that, at least according to my understanding, power on the HDMI is part of VESA (Video Electronics Standards Association) DDC (Display Data Channel) support. As such the power is supplied by the video signal source which is the I2C bus master on the DDC bus. This applies to all of the incarnations of VESA DDC on VGA, DVI, and HDMI. Thus, in order for us to be able to use the HDMI power pin as an input, we need to be connecting that pin to some other HDMI signal source (computer, DVD player, Blu-ray player, et cetera). Hence our smallest form factor for HDMI-only connections would be an HDMI(male)-HDMI(female) adapter to plug in between an HDMI source (as above, for power) and an HDMI sink (monitor, television, projector, et cetera). For convenience, I recommend connecting between the HDMI source and the HDMI cable going to the HDMI sink. Another option would be to use a USB connection for power. Not as elegant as the HDMI stick but USB power is relatively ubiquitous for charging mobile devices. And it doesn't require a separate HDMI source just for power. In fact, a lot of televisions with HDMI ports also sport USB ports so a USB cable would be sufficient. Furthermore, if power is truly our only input we'll have a hard time sending out a signal which is compatible with a wide range of displays unless we choose the lowest common resolution/color depth. We could adapt to the best display mode that the display offers, and that our board can generate, if we connected to the bi-directional VESA DDC bus and read the display's capabilities. Richard ___ 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] HDMI Player Stick as DRM-free Merch Alternative
> On Jul 22, 2018, at 15:11, Jean Flamelle wrote: > > A monofunction PCB that when power is supplied from the HDMI, > generates a private key signature, displays it as a QR code for a few > moments, then plays whatever video is stored on nand. > > The QR code confirms the legitimacy or official-ness of the copy. This sounds similar, in concept at least, to something like a GPG signature over the presentation content. The processing to calculate the signature over a feature-length high-definition video (Blueray movie ~15-25GB[max single layer])[1] to verify authenticity is significant. I would recommend implementing the algorithm in FPGA (eventually ASIC?) to speed the calculation. I don't know what calculation time would be acceptable. We can probably buy some user patience with a real, honest, linear-response progress bar and possibly a countdown timer. Let's say we have NAND read rates that allow us to pull 1GB/s into the signature processor and we can process data as fast as it arrives. That would give us 1s of calculation time for every 1GB of content or 15-25 seconds to calculate the QR code. Samsung has a 32GB chip with a high-speed serial interface capable of 880MB/s in sequential reads.[2] That's ~88% of the speed we talked about above. (25GB transfer in 28.4s) And it is in mass production! The size sounds good, too: 11.5x13x1.2mm (I had some time to burn while riding around with my family to different appointments and waiting while the girls were in lessons.) Richard References: [1] https://en.m.wikipedia.org/wiki/Blu-ray [2] https://www.samsung.com/semiconductor/estorage/eufs/ ___ 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] HDMI Player Stick as DRM-free Merch Alternative
Sounds interesting. This sounds like a bit of 'how'. The 'why' is alluded to in the title but not so much in the body. I can understand DRM-free to allow more freedom to user. What I'm missing is more of what advantages the user reaps from using this device. Does the user purchase, rent, or borrow the stick? Who can load content onto it? What problem(s) does it solve? What do you mean by "Merch Alternative"? ___ 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
> On Jul 18, 2018, at 07:15, Luke Kenneth Casson Leighton wrote: > >> On Monday, July 16, 2018, Richard Wilbur wrote: […] >> I was wondering >> where we were in regard to ordering parts, fabricating circuit boards, etc. >> for the microdesktop as I saw issues which could be addressed by creating a >> v1.8 schematic, BOM, and layout. > > > I know. It should have been 8 to 10 months ago. Cant delay now. Do after. > Just how it is. Document, plan carefully. Nextv batch 1.8 Sounds great! I'll document things on the wiki and look forward to the shipping date for v1.7! ___ 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 v1.7
On Tue, Jul 17, 2018 at 7:43 PM, Luke Kenneth Casson Leighton wrote: > > Richard can you please edit community_ideas micrideksoo oage rhuombustech > maintain all of this there revisioons to revisions of email knoen to be not > a sustainable way to track detailed important information Luke, That's a great idea. I was just noticing how the updates weren't fitting into the original so well and thinking I didn't know which wiki page on which to write stuff. Thank you for answering my question before I had a chance to ask it! Richard ___ 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 v1.7
Here are links to the files: ftp://lists.phcomp.co.uk/files/arm-netbook/EOMA_I2C_VESA_calc.pdf ftp://lists.phcomp.co.uk/files/arm-netbook/EOMA_I2C_circuit_small.png These are evidently by default good till 18 August 2018. If they are still cogent to the discussion I will try to keep them around longer. Richard ___ 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 v1.7
On Tue, Jul 17, 2018 at 7:04 PM, Pičugins Arsenijs wrote: > > > 2. Implement circuit in attached > > diagram[EOMA_I2C_circuit_sketch_small.png] ... > > Did not get your attachments. I'm thinking they were scrubbed > by the ML software? Maybe post a link - imgur/other sharing > service? It is likely the PDF was scrubbed. The PNG got into moderation because it was too large. So I sent them both to the E-mail address at the bottom of the mailing list signature, below: > ___ > 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 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 v1.7
On Jul 17, 2018, at 19:04, Pičugins Arsenijs wrote: >> 2. Implement circuit in attached >> diagram[EOMA_I2C_circuit_sketch_small.png] ... > > Did not get your attachments. I'm thinking they were scrubbed > by the ML software? Maybe post a link - imgur/other sharing > service? > > Arsenijs > > ___ > 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 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 v1.7
Addendum Why? 1. Make VESA DDC lines conform to VESA DDC spec. (VDD=5.0V, I2C signalling)[1] 2. Respect VREFTTL in the range of 3.3-5.0V on EOMA side of VESA DDC lines. 3. Respect EOMA requirement that all lines except EOMA I2C be tri-stated at power on. How? 1. Connect pull-up resistors for VESA_SDA(R8) and VESA_SCL(R12) to VESA_PWR (+5.0V) instead of VREFTTL. Maximum current requirement on VESA_PWR is ~670uA. 2. Implement circuit in attached diagram[EOMA_I2C_circuit_sketch_small.png] on each of SDA and SCL. I have attached a spreadsheet[EOMA_I2C_VESA_calc.pdf] showing how this accommodates the I2C signalling for VDD=3.3V=VREFTTL and VDD=5.0V.[2] It also accommodates the EOMA68 VREFTTL input levels by not allowing the EOMA side of the signal to exceed one Schottky diode drop(0.3V) above VDD=3.3V. 3. Enable the current limiting regulator (SY6280) for VESA_PWR (+5.0V on VGA pin 9) with latch of LCDDE when it first goes active (line coming from EOMA68 connector). References: [1] https://en.wikipedia.org/wiki/Display_Data_Channel [2] http://www.nxp.com/documents/user_manual/UM10204.pdf ___ 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 v1.7
On Tue, Jul 17, 2018 at 7:02 AM, Pičugins Arsenijs wrote: > > Some thoughts: > > > 3. Add another SY6280 current limiter for +5V and connect to VGA pin > > 9 (VESA power). Seems to be some difference of opinion on current > > requirements: 50mA[2], 300mA-1000mA[1]. If we were to limit at > > 300mA, it should easily supply the needs of I2C serial EEPROM and > > probably not over-tax our power supply. > > I've also seen the VGA/HDMI +5V used to power various converters > (most often, HDMI->VGA, but I imagine the inverse is sometimes used > as well). I agree. I designed a converter that was powered by VGA DDC pin 9 power or, in the absence of that, the VESA DDC SDA and SCL pull-up, or the VGA horizontal and vertical synchronization signals. I don't remember exactly how much power it used but it was relatively efficient as I used low-power CMOS PAL (Programmable Array Logic, precursor to FPGA's). Basically its largest-current operating mode was driving to TTL loads across the video cable. > > For VESA_SDA and VESA_SCL, add diode limiters connected to ground > > similar to ESD117-ESD123 on the SD bus lines provided the > > diode-limiting voltage is greater than VREFTTL nominal range. > > Otherwise use BAT54S connected between ground and VREFTTL. > > Is it not possible that VESA_SDA and VESA_SCL are 5V? If so, they could > require level shifting from 5V, am I wrong here? It turns out VESA DDC uses I2C signalling.[1] I2C signalling is bi-directional open drain or open collector so the high state is due to a pull-up resistor. The I2C bus voltage can be +5 V or +3.3 V, although other voltages are permitted.[2] All the devices on the bus have to tolerate the bus voltage. In my experience, the VESA DDC reference design used a pull-up supply of +5 V. The EOMA68 card doesn't have to drive it that high, simply go hi-Z and the pull-up resistor in the microdesktop will pull it that high. But the EOMA68 card will have to tolerate +5 V on those two lines (VESA_SDA, VESA_SCL) or we jump into the tricky area of logic-level translation for bi-directional open-drain signals. Good observations. Thanks Arsenijs! References: [1] https://en.wikipedia.org/wiki/Display_Data_Channel [2] https://en.wikipedia.org/wiki/I%C2%B2C ___ 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 v1.7
On Jul 3, 2018, at 03:19, Luke Kenneth Casson Leighton wrote: > >> On Tue, Jul 3, 2018 at 1:57 AM, Richard Wilbur >> wrote: >> >> By the way, what is the status of the microdesktop >> design v1.7? Have you already invested in parts (specifically >> the 2x10 header) and/or circuit boards? > > yep all good. the funds that were transferred to mike 18+ months ago > ($60k) are down to around $45k now and he's got most of that left with > which to order components for the 1.7 md and 2.7.5 card. I was asking with regard to the possibility of releasing a microdesktop v1.8 with a few refinements (presumably electrical/electronic changes that fit within the same form factor, id est, no change to the case). Why? 1. Open up more possibilities for experimentation by tripling the number of GPIO lines available at expansion connector(2 → 6). 2. Add soft-start to the power regulator for 3.3V supply. 3. Support VESA DDC Plug and Play monitor detection regardless of power-up order between monitor and computer.[1] 4. Improve signal quality (and reduce radiated/coupled EMI) for VGA interface. 5. Improve Electro-Static Discharge protection (page 1 of the schematic says: “TODO: ESD protection”). How? 1. Bring the remaining 4 GPIO lines from the EOMA68 connector (J14 pins 20,54,21,55) to the expansion header(J5). Dropping VESA_SCL and VESA_SDA lines from J5 (available and used on VGA connector J4) gets us two pins for free. Then we either get a larger connector (2x11 instead of 2x10), find two other signals to drop from the expansion header (EOMA68-I2C_SCL, EOMA68-I2C_SDA which are connected to the serial EEPROM for chassis identification?), or decide we are happy to have doubled the GPIO presence (2 → 4) and stop. 2. Add a 10K Ohm resistor between +5V and Enable(pin 1) on U9. 3. Add another SY6280 current limiter for +5V and connect to VGA pin 9 (VESA power). Seems to be some difference of opinion on current requirements: 50mA[2], 300mA-1000mA[1]. If we were to limit at 300mA, it should easily supply the needs of I2C serial EEPROM and probably not over-tax our power supply. 4. Route signals as high-speed/frequency pairs.[1] A. Change the name of VGA pins(J4): pin Name 5 HSYNC_RTN 6 RED_RTN 7 GREEN_RTN 8 BLUE_RTN 9 PWR 10 VSYNC_DDC_RTN B. Make sure the following pairs are routed as microstrip pairs from connector pins to signal driver: VGA_ROUT/VGA_R(1), RED_RTN(6) VGA_GOUT/VGA_G(2), GREEN_RTN(7) VGA_BOUT/VGA_B(3), BLUE_RTN(8) VGAHSYNC/VGA_HSYNC(13), HSYNC_RTN(5) VGAVSYNC/VGA_VSYNC(14), VSYNC_DDC_RTN(10) Return lines should connect to ground pins of signal driver and/or ground side of power supply decoupling capacitor at signal driver. The first three pairs (video lines) should be over unbroken ground plane as they are the highest-frequency lines (12.6MHz-388MHz depending on video mode). Add VREFTTL decoupling capacitor next to R12 and R8 (pull-ups for VESA_SCL and VESA_SDA) then route the following pairs from VGA connector to pull-ups/decoupling capacitor ground: VESA_SDA/SDA(12), VSYNC_DDC_RTN(10) VESA_SCL/SCL(15), VSYNC_DDC_RTN(10) 5. Filter VGA cable shield connection to ground with ferrite beads (J4 pins 16,17). Likewise USB2 ports (J11, J3) pins M0 and M1. Also EOMA68 connector (J14) pins “0”, “0/2”, if those are connector shield connections? What are J14 pins 73 and 74? (They are labelled “GND” but left unconnected?) We don't have a metal chassis here to connect the shields directly to. If we did, I'd suggest connecting shields to chassis ground and then ferrite bead to separate chassis ground from power/signal ground. For VESA_SDA and VESA_SCL, add diode limiters connected to ground similar to ESD117-ESD123 on the SD bus lines provided the diode-limiting voltage is greater than VREFTTL nominal range. Otherwise use BAT54S connected between ground and VREFTTL. Add BAT54S connected between ground and USB2VBUS across USB2 data lines EOMA68-DM0, EOMA68-DP0, DM2, DP2. Just some thoughts. ;>) Richard References: [1] https://en.wikipedia.org/wiki/VGA_connector [2] https://en.wikipedia.org/wiki/Display_Data_Channel ___ 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
>> On Jul 15, 2018, at 20:38, Luke Kenneth Casson Leighton >> wrote: > […] > Yes. Mike is being extra cautious, hes ordered the full set of components > now for 1000 cards and 500 mds. By "mds" I guess you mean "microdesktops"? This was the gist of my earlier question regarding the status of microdesktops. I was wondering where we were in regard to ordering parts, fabricating circuit boards, etc. for the microdesktop as I saw issues which could be addressed by creating a v1.8 schematic, BOM, and layout. ___ 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] riscv-basics.com
> On Jul 10, 2018, at 13:37, Luke Kenneth Casson Leighton wrote:
> interestingly the bullet-points 3 and 5 are *actuallly
> legitimate concerns*. the RISC-V Foundation is over-controlled by UCB
> Berkeley,[0] via a structure that is similar to the failed Google Project
> Ara ("it's open as long as you sign our secret agreement and don't
> publish information we don't want you to").
Are you referring to "Design Assurance"(as 3) and "Security"(as 5)?
Seems like an advertisement specifically against risc-v by and for ARM.
I'm sorry to hear about those terms on a project with any pretensions of being
"open".
Notes:
[0] UCB stands for "University of California at Berkeley" so the intermediate
form is normally "UC Berkeley".
___
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] Microdesktop v1.7
By the way, what is the status of the microdesktop design v1.7? Have you already invested in parts (specifically the 2x10 header) and/or circuit boards? ___ 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 Prototype Status
> On Jun 3, 2018, at 14:17, Luke Kenneth Casson Leighton wrote: > […] [prototypes] > arrived yesterday, testing them now, RAM's fine, checking HDMI. > dealing with RISC-V and recovering from four weeks of travelling to > six different places in four different countries. Good to hear they booted and the RAM works! Have you had a chance to recover from your whirlwind tour? Any signs of life from the uHDMI? Richard ___ 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] Testing: GPIO
Luke, thanks for the links and the instructions. I'll study them further when I get home this evening (bigger screen and keyboard!). Richard ___ 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] Testing: GPIO
On May 16, 2018, at 11:39, Richard Wilbur wrote: > Is there a place I can download the install image (boot image) you are presently using on the DS113 A20 cards? (Accidentally hit send before I finished the sentence. A less than satisfying user experience on this phone, but at least I can interact in my present physical context.) Richard ___ 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] Testing: GPIO
On Tue, May 15, 2018 at 2:30 PM, Luke Kenneth Casson Leighton wrote: > ok - hum i need to send you that card, don't i. you'll be able to > try this out. Sure, the card would be lovely. Then I could work on some other stuff, too. Like DDC over I2C over GPIO for VESA monitor detection on the VGA port. Even before you have a chance to send the card I'd be able to make some progress given a place I could download a copy of the current script.bin you are using (I'd be willing to try and download the sunxi-tools bin2fex and fex2bin and run them on this x86_64 machine) or script.fex (which is reportedly human-readable text). Is there a ___ 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] Testing: GPIO
On May 14, 2018, at 12:24, Luke Kenneth Casson Leighton wrote: > Look up sunxi-tools fex2bin bin2fex and wiki sunxi fex. I did look up and read some about those topics--and I will read more! What I'm wondering is what does the script.bin configure presently at boot? Then I can figure out whether we need to change it in order to be able to test the GPIO pins. With sunxi 3.4 kernel it looks like whatever we have configured in script.bin is what we have to work with on that load of the gpio-sunxi kernel module so I'm interested in making sure the GPIO pins we want to test are configured into the /sys/class/gpio namespace, and at what names they appear. I read in the sunxi GPIO wiki page[1] that script.bin can specify the mapping between the GPIO number NNN and PORT:BIT that determines the sysfs name /sys/class/gpio/gpioNNN_PORTBIT brought about by sudo echo NNN >/sys/class/gpio/export # A request to export control over gpio mapping NNN (as defined in script.bin) from kernel space to user space. So, to track down the pins we want, we need to know the mapping that is currently in script.bin (or specify it ourselves). There is a scheme outlined in the sunxi GPIO wiki page[1] for associating the numbers NNN with PORT:BIT that is followed on the A20/PIO page[2] and seems useful as it is consistent and reversible. So if we haven't already created a version of script.bin (for the sunxi-gpio module) that maps the A20's Programmable Input/Output pins for the DS113 card, I'd recommend we follow that scheme. NNN := (PORT - 'A') * 32 + BIT PORT:BIT NNN sysfs PI11 267 gpio267_pi11 PI10 266 gpio266_pi10 PI13 269 gpio269_pi13 PI12 268 gpio268_pi12 PI3 259 gpio259_pi3 PB4 36 gpio36_pb4 PH0 224 gpio224_ph0 PB3 35 gpio35_pb3 References: [1] https://linux-sunxi.org/GPIO [2] https://linux-sunxi.org/A20/PIO ___ 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] Testing: GPIO
On Sat, May 12, 2018 at 5:27 AM, Luke Kenneth Casson Leighton wrote: > Hi richard on phone brief. Yes 3.4, different, uses module config, works > fine. Thanks for the response. What I'm wondering is what the boot image/partition has for 'script.bin' because under kernel 3.4 that defines the set of GPIO pins that will be enabled at boot and their initial state. (Looks like it determines the initial state of all the pin multiplexors.) Probably more easily interpreted in the FEX form (human-readable text), albeit larger. > Talk to phil about ikiwiki itsvon his server Thanks for the referral. Took it up with him separately. ___ 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] Testing: GPIO
First, in adding the link to the sunxi wiki page documenting GPIO access on Allwinner chips[1] to the rhombus-tech.net "Testing" wiki page[2], I again triggered the "An error occurred while writing CGI reply" page delivered at URL: http://rhombus-tech.net/cgi-bin/rhombus/ikiwiki.cgi I clicked the "Save" button after editting the ikiwiki code and just waited for it to return. Second, the linux-sunxi wiki page refers to the interaction with the GPIO driver differently depending on whether using linux-mainline or sunxi-3.4 kernel. If memory serves it seems you mentioned we plan to ship the cards with sunxi-3.4 until we get several drivers into linux-mainline, is that so? Sincerely, Richard References: [1] https://linux-sunxi.org/GPIO [2] http://rhombus-tech.net/allwinner_a10/testing/ ___ 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] devicetree and testing
On Apr 17, 2018, at 16:17, Luke Kenneth Casson Leighton wrote: On Tue, Apr 17, 2018 at 11:12 PM, Richard Wilbur wrote: In my estimation the tasks that can be completed relatively quickly are 1 and 3 as they don't require convincing anyone else of the importance of the goal or merit of the implementation. it is slightly more complex (3 that is) because a library and associated linux kernel device-driver has to also be written that reads from the I2C EEPROM (to be added to both u-boot and the linux kernel), in order to use the devicetree fragment merging... overlay! that's what it's called. it is *not* going to be okay to just blop in one devicetree file for eoma68-a20-with-microdesktop, one devicetree file for eoma68-rk3288-with-microdesktop, one devicetree file for eoma68-a20-with-laptop-housing, one devicetree file for eoma68-rk3288-with-laptop-housing etc. etc. preventing that kind of insane O(N * M) devicetree proliferation and reducing it down to O(N + M) *IS* the entire point of the EOMA68 I agree wholeheartedly with the modular mix and match overlay fragment design but saw the software support for it in what I had labelled as priority 4. Whereas I understood priority 3 to entail creating the devicetree fragments for the EOMA hardware that already exists. 1. Hack together some tests under 3.4.104 that we can run on the extant drivers. 2. Work on getting extant A20 drivers mainlined in the linux kernel. 3. Create devicetree [fragments] for DS113 v2.7.4 and v2.7.5, … (all extant versions of DS113 and microdesktop case). 4. Work on getting devicetree with [fragment] add/remove overlay support mainlined in the linux kernel (and u-boot?). Let me restate without relying only on numbers to identify the tasks: We can create the tests to run on 3.4.104 kernel (priority 1) and the devicetree overlays or fragments for each version of the processor card and microdesktop case (priority 3) without buy in from anyone else. Getting the A20 drivers mainlined in the linux kernel (priority 2) and devicetree fragment overlay add/remove support in the linux kernel and u-boot (priority 4) will require continued collaboration with those who maintain the linux kernel and u-boot. Others have already been working on this effort for several years. ___ 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] devicetree and testing
On Apr 17, 2018, at 15:47, Luke Kenneth Casson Leighton wrote: > > On Tue, Apr 17, 2018 at 9:54 PM, Richard Wilbur > wrote: > […] >> 1. Hack together some tests under 3.4.104 that we can run on the extant >> drivers. >> 2. Work on getting extant A20 drivers mainlined in the linux kernel. > > people have been working on that for many many years. > >> 3. Create devicetree for DS113 v2.7.4 and v2.7.5, … (all extant versions >> of DS113 and microdesktop case). >> 4. Work on getting devicetree with add/remove overlay support mainlined in >> the linux kernel (and u-boot?). > > yes. I understand that people have been working on steps 2 and 4 for years and I had no diminution of their efforts in mind. In my estimation the tasks that can be completed relatively quickly are 1 and 3 as they don't require convincing anyone else of the importance of the goal or merit of the implementation. ___ 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] devicetree and testing
On Apr 16, 2018, at 22:04, Luke Kenneth Casson Leighton wrote: On Tue, Apr 17, 2018 at 4:53 AM, Richard Wilbur wrote: I am working on the devicetree for the microdesktop v1.7 and the DS113 v2.7.5 as it sounds like that is the natural prerequisite to auto-configuration and more-automated testing. awesome. remember though that testing will be done with 3.4.104+ as it's where 100% of the functionality is present. If I'm understanding you correctly the 3.4.104 kernel is the most recent kernel to have free support for all the promised functionality of the DS-113, but lacks devicetree support to make that functionality autoconfigurable? That is a beastly spot to be in! In that case I'll make the manual tables from which we can initially code up some tests by using the gpio driver and later write up the devicetree. So, sorry for being a bit thick headed, it just dawned on me what our priorities have to be and why: 1. Hack together some tests under 3.4.104 that we can run on the extant drivers. 2. Work on getting extant A20 drivers mainlined in the linux kernel. 3. Create devicetree for DS113 v2.7.4 and v2.7.5, … (all extant versions of DS113 and microdesktop case). 4. Work on getting devicetree with add/remove overlay support mainlined in the linux kernel (and u-boot?). --Richard ___ 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] Testing: GPIO
On Sat, Mar 3, 2018 at 12:11 AM, Richard Wilbur wrote: > Has anyone created a VESA DDC driver that will get the EDID from any > connected monitor given when given access to an I2C device (as exposed by our > bit-banging I2C driver). > > VESA DDC is a standard that specifies a protocol on top of I2C for obtaining > monitor information (supported resolutions and timings, color gamma, etc.). Looks like ddcutil[*] provides (reasonably up-to-date) VESA DDC functionality. Reference: [*] http://www.ddcutil.com/ ___ 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] Testing: GPIO
On Mar 2, 2018, at 15:43, Jonathan Neuschäfer wrote: >> On Fri, Mar 02, 2018 at 03:26:32PM -0700, Richard Wilbur wrote: […] > I'm not actively working on any of this, but I'm interested in the > devicetree side of things. To what does your interest in devicetree extend? Are you interested in helping create the devicetree mappings for EOMA68 hardware, or following developments, etc. How would you like to be involved? Thank you for imparting your knowledge below. >> From what I'm hearing, once the device tree is ready we could work on >> "automagically" configuring the VESA DDC driver to bit-bang the >> correct GPIO pins. Does the bit-banging VESA DDC driver exist already? >> (I wrote a bit-banging I2C driver in VxWorks at a previous position so >> the topic is not foreign.) > > Mainline Linux has a driver[1] for I2C-over-GPIO. It's been there since > 2.6.22, albeit initially without devicetree support, which came in 3.4. > > There's also a generic devicetree binding[2] for I2C-over-GPIO in > Linux's Documentation/devicetree/bindings directory. That's wonderful news! So with the devicetree for the micro-desktop we should be able to setup the I2C driver. Next question: has anyone created a VESA DDC driver that will get the EDID from any connected monitor given when given access to an I2C device (as exposed by our bit-banging I2C driver). VESA DDC is a standard that specifies a protocol on top of I2C for obtaining monitor information (supported resolutions and timings, color gamma, etc.). >> If none of this is underway I'll continue mapping things out so we can >> create the device tree for the micro-desktop. If I remember correctly >> we also should create a device tree for the DS-113 v2.7.4 and v2.7.5? > > What is DS-113? EOMA68-A20 the CPU card. ___ 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] Testing: GPIO
On Mar 2, 2018, at 03:07, Luke Kenneth Casson Leighton wrote: > > btw i'm tempted to suggest treating the SPI pins as straight GPIO. if > they can do 0 and 1 (input and output) then they're not > short-circuited and/or disconnected and that's... good enough. So test them as GPIO for now? ___ 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] Testing: GPIO
On Mar 1, 2018, at 20:40, Luke Kenneth Casson Leighton wrote: > > On Thu, Mar 1, 2018 at 10:42 PM, Richard Wilbur > wrote: > >> Luke, have you tested the D/A circuit on the micro-desktop board? > > yep it works great up to 1024x768. i haven't yet been able to get it > to sync at anything greater than that, because you have to manually > convert the signals into A20 timings... and of course if you can't > read the EDID data you don't know *exactly* what the settings are in > the first place for any given monitor. > > 1024x768, being a common VESA standard, has worked consistently on > every monitor i've tried. So if we could read the EDID the driver would figure out the A20 timings? Does the A20 already have a graphics driver capable of that? (In which case the bit-banging VESA DDC driver becomes very important.) How much of this infrastructure already exists? I'm bringing my tools, where do we start building? I have a collection of VGA monitors with different aspect ratios and sizes (3 CRT and 3 LCD). I'd be happy to test resolutions above and below 1024x768. >> Only thing I would worry about is the hold time on the data lines. If >> the A20 sets up the data quickly (relative to the pixel time) and >> holds it until the next setup, we should be in good shape. > > sigh yeah i thought about that... using buffer ICs with a "hold", and > linking up the clock line to it never got round to it. i'd prefer > to just skip the entire circuit and use a TFP410 (or maybe it's a > TFP401a), or a Chrontel RGB/TTL to VGA converter IC. CH7036 i think > it is. Are you thinking of octal D flip-flops? I'll have to look up those datasheets. What do those chips offer over the flip-flops? How do the prices compare? […] > yyup. exactly. remember, you can't do more than one interface on > any given set of pins, so i had to pick one (RGB/TTL or LVDS or MIPI > or eDP), that then means you have to have a conversion IC in-place on > the Card if a particular SoC doesn't *have* that interface... and many > of the lower-cost SoCs don't because they're not part of the MIPI or > DisplayPort cartel(s) Yes, that's the awful thing about so many industry standards: you can't get the text without signing documents and paying a handsome price, you can't use them without paying royalties to the patent owners. > ... and even if you had LVDS, the cost on the other side (Housing > side) of having an LVDS-to-RGB/TTL converter is so high relative to > the cost of the LCD itself that companies would rebel and not bother > with the standard at all. > > so, bizarrely, RGB/TTL, by being both "free" and also unencumbered by > patents *and* by being lowest-common-denominator, wins out on all > fronts. except for the fact that you need a 125mhz clock-rate for > 1920x1080@60fps, which is a bit... high. but hey. Will the A20 clock the RGBTTL interface that high? ___ 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] Testing: GPIO
On Mar 1, 2018, at 20:31, Luke Kenneth Casson Leighton wrote: > On Thu, Mar 1, 2018 at 10:02 PM, Richard Wilbur > wrote: >> If we did decide to roll a v1.8 micro-desktop board, it would afford >> us the opportunity to bring two of the presently unconnected GPIO18-21 >> lines to the expansion header in place of VESA_SCL and VESA_SDA (which >> are after all available on pins 15 and 12 of the VGA connector). If >> VESA_SCL and VESA_SDA are more useful on the expansion header then, by >> all means, forget this suggestion. > > the reason i brought those out is just in case someone decided they > wanted to use them as plain GPIO. Having the most available GPIO pins sounds like a great goal for the micro-desktop. But at the expense of a fully operational VGA interface when we have four more GPIO pins that we could choose from--seems like maybe we could take a better tradeoff? >> The other option to accommodate all our GPIO goodness would be to >> replace J5 (2x10 header) with a 2x11 or 2x12 header > > yep. I would vote for a 2x11 header with the four other GPIO's connected and the VESA DDC lines not connected to the expansion header. That only requires the expansion to extend in length by 10%. ___ 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] Testing: GPIO
On Mar 1, 2018, at 20:30, Luke Kenneth Casson Leighton wrote: Sent from my iPhone > On Thu, Mar 1, 2018 at 9:46 PM, Richard Wilbur > wrote: >> It looks to me like the fastest way to test the GPIO lines connected >> on the micro-desktop board to VESA_SCL and VESA_SDA would simply be to >> connect a VGA monitor to the micro-desktop and make sure it is >> properly detected and a test image looks right on it. > > yep, pretty much... with one slight fly in the ointment: the SCL and > SDA lines are straight GPIO and will need a bit-banging I2C linux > kernel driver. once that's configured, doing i2cdetect _should_ be > enough to test the circuit, although scanning the data and running > read-edid on it would be awesome and amazing: it would mean being able > to *really* do proper VESA detection. Is someone already working on that? Sounds like we need the device tree for the micro-desktop to be populated. If we did it for micro-desktop v1.7 it would be something to build off for micro-desktop v1.8 and also a good place to begin for the laptop. From what I'm hearing, once the device tree is ready we could work on "automagically" configuring the VESA DDC driver to bit-bang the correct GPIO pins. Does the bit-banging VESA DDC driver exist already? (I wrote a bit-banging I2C driver in VxWorks at a previous position so the topic is not foreign.) If none of this is underway I'll continue mapping things out so we can create the device tree for the micro-desktop. If I remember correctly we also should create a device tree for the DS-113 v2.7.4 and v2.7.5? I'd be happy to work on that if you think that is the highest priority right now. It sounds like it will help both testing and deployment. ___ 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] Testing: GPIO
On Mar 1, 2018, at 17:23, Christopher Havel wrote: > > Be careful... it was the replacing of the two ports on that old VGN-S360 > that killed it... VAIOs are well known in repair circles for dying of > heatstroke from even the slightest rework (and I was duly warned)... if > it's a modular jack (on a cable, so no soldering), you'll be fine. If you > need an iron... buy a board, not a port. Trust me. I'll have to open the case and take a look to see what the particulars of the situation are. Thank you for sounding the voice of experience. I consider myself forewarned. ___ 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] Testing: GPIO
On Thu, Mar 1, 2018 at 5:10 PM, Christopher Havel wrote: > Posting from my phone while making dinner, so forgive that it's a top-post > plz. > > Testing via the micro desktop works as long as you've got a known good > micro desktop and your ports haven't won through. I think the 4051 idea > might be a little better - I've worn out USB ports before, just from using > them - ask me sometime about my mother's old VAIO laptop and how it > ultimately died... the only thing in my test rig to wear out is the card > cage... > > But, I'm not in charge, so I'll defer. You make very good points about connector fatigue. I was planning to leave everything connected and only install/remove the EOMA68 card from the micro-desktop case. That works as long as we don't need to test hot-plugging anything. To my knowledge we figured the hot-plug capability would likely be conferred by the applicable standard and thus were designing a basic functionality test. (Incidentally I have a dead VAIO laptop in which the power jack center pin broke. I really need to get that ordered and replaced.;>) ___ 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] Testing: GPIO
On Thu, Mar 1, 2018 at 4:12 PM, Christopher Havel wrote: > I /designed/ that circuitry in the micro-desktop. I still have the paper > copy somewhere... Very nice! > You can also do it with a dedicated DAC chip, which is the > easy-but-expensive way I hinted at. > > But we aren't testing /that/ part -- the micro-desktop -- are we? If we're > testing the /card/, the card does not output anything remotely like VGA, > and, therefore, some kind of conversion is necessary in order to attach it > to a VGA cable as was being proposed in the email I replied to about that. We aren't planning to test the micro-desktop. The planning is for tests of the card mounted in a micro-desktop case to use as a test fixture. We are planning to use your good work on the micro-desktop case to our advantage and connect the VGA cable to the micro-desktop VGA connector in order to see that the EOMA68 RGBTTL (with EDID) works as advertised! > All you really need for this is a laptop PCMCIA or CardBus card cage, an > IDE cable or two, a couple 4051s and toggle switches on a slice of > perfboard, a 9v battery with connector and switch, and a cheap USB logic > analyzer attached to a laptop. You use the 4051s, switched manually, and > powered by the 9v battery, to act as input expanders for the logic > analyzer. Each 4015 turns one channel into eight and requires three "on-on" > switches -- with one "on" wired to +9v, one to ground, and the common to > the chip. You use the IDE cable for the wires ;) If you hook it up so that > you have one 4051 mux per logic analyzer channel, that'll give you 128 (!) > channels to switch with -- most USB logic analyzers, even the super cheap > ones, are 16-channel... > > Heck, if you wanted to make the circuit "complicated" -- I could draw up > something that automatically iterated through the channels for you at the > press of a single button, switching at variable speed with a pot, a 555, a > resistor and cap, and a couple 4017s and 4051s. You'd only need /one/ > channel for that -- so you could even use an o-scope there. Heck, I could > do it with that circuit and my old, old Tektronix 422... > > I'm honestly surprised that this sort of idea hasn't been mentioned yet. That is a cool way to set up a very wide logic analyzer. We were planning to use a little specialized hardware and less elbow grease to make our test fixture: * USB devices connected to the micro-desktop case USB ports, * SD peripheral connected to the micro SD slot, * VGA monitor connected to the VGA connector, * serial terminal connected to the UART pins in expansion header ___ 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] Testing: GPIO
On Thu, Mar 1, 2018 at 3:05 PM, Christopher Havel wrote: > ...BTW, those SCL and SDA lines on a VGA connector are for a nifty signal > coming from your monitor. It's called EDID and it's basically how every > modern OS magically knows what to do with the monitor it wants to display > on, regardless of the specs or origin of said monitor. > > If you've ever had a cheap VGA cable where all the pins are present on the > connectors but those two lines are disconnected internally, you have > experience with what happens when you eff with those wires. Best to leave > them alone! Christopher, you are quite correct about the usefullness of untarnished VESA EDID. Turns out I've worked with it before and respect its utility with respect to VGA/DVI/HDMI monitors. We are simply talking about how to test the DS-113 EOMA68-A20 processor cards when they come to the end of the assembly line. In that regard, our discussion is mainly about how to create a test jig/fixture that has the most complete coverage of the signals available on the EOMA68 interface and some of the possible use scenarios. We also have an interest in time efficiency as a matter of economy. ___ 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] Testing: GPIO
On Thu, Mar 1, 2018 at 2:54 PM, Christopher Havel wrote: > Oh LOL. > > VGA is analog, and has six wires for color (red signal, red ground, ditto > each for blue and green). It's not /exactly/ serial (serial as I understand > it is inherently digital, which VGA is *ahem* very much not) but the > paradigm sort of fits. RGBTTL is parallel. You have one wire per bit of > color. So that's 18 wires. Plus your sync lines... which may or may not > match VGA signal standards, I'm not sure. > > If you actually manage to figure out how to get that hooked up correclty, > let me know ;) > > (Hint, it's doable, but you need additional components. There's a cheap > way, and there's an easy way, and they are two *very* different ways...) Looking at the micro-desktop schematic it seems Luke has this issue well in hand. Christopher have you seen the micro-desktop schematic? The VGA conversion is on page 3. Luke, have you tested the D/A circuit on the micro-desktop board? Only thing I would worry about is the hold time on the data lines. If the A20 sets up the data quickly (relative to the pixel time) and holds it until the next setup, we should be in good shape. > Much easier suggestion: get a small LCD. *ANY* small LCD. Like a five or > seven inch display at the largest. Raw panel, no driver board. Get the > datasheet and a compatible connector. (If you source from eBay this is very > easy; those are almost all commodity displays with available datasheets.) > If it's a SMALL DISPLAY it *will* be RGBTTL, 90%+ of the time (I've seen > one exception to this ever and it was in an off-brand portable DVD player). > Wire it up. Wire it to the card connector. Add power. If you get a screen > that works, you've done it right. I think this is why Luke put the display signals on the EOMA68 standard in the RGBTTL format--to simplify the job of connecting to LCD's. (I'm thinking of the laptop, tablet, gaming console, phone, etc.) ___ 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] Testing: GPIO
If we did decide to roll a v1.8 micro-desktop board, it would afford us the opportunity to bring two of the presently unconnected GPIO18-21 lines to the expansion header in place of VESA_SCL and VESA_SDA (which are after all available on pins 15 and 12 of the VGA connector). If VESA_SCL and VESA_SDA are more useful on the expansion header then, by all means, forget this suggestion. The other option to accommodate all our GPIO goodness would be to replace J5 (2x10 header) with a 2x11 or 2x12 header allowing us to bring all the GPIO pins to the expansion header (the only difference being whether we would prefer to retain VESA_SCL and VESA_SDA in the header). ___ 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] Testing: GPIO
It looks to me like the fastest way to test the GPIO lines connected on the micro-desktop board to VESA_SCL and VESA_SDA would simply be to connect a VGA monitor to the micro-desktop and make sure it is properly detected and a test image looks right on it. This would leave 6 GPIO lines to test. So we get better test coverage for the EOMA interface and shorter GPIO test at the same time! ___ 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] Testing: GPIO
On Thu, Mar 1, 2018 at 1:50 PM, Luke Kenneth Casson Leighton wrote: > On Thu, Mar 1, 2018 at 8:33 PM, Richard Wilbur > wrote: >> We could obviously create a v1.8 schematic for the microdesktop and >> connect these EOMA nets to a header, if desired. > > yes. damn. i think it's probably that i didn't update the > micro-desktop schematic when i changed the EOMA68 spec from 24-pin to > 18-pin RGB/TTL. Maybe you didn't update the micro-desktop schematic as much as you intended to when you changed the EOMA68 spec from 24-pin to 18-pin RGB/TTL but in v1.7 you did at least connect only the 6 high bits of each color to the D/A convertors. The new pins are all connected to useful sub-circuits on the micro-desktop board: SPI (expansion header), SD0 (SD slot), and PWRON (power switch). ___ 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] Testing: GPIO
On Wed, Feb 28, 2018 at 2:41 PM, Luke Kenneth Casson Leighton wrote: > On Wed, Feb 28, 2018 at 9:09 PM, Richard Wilbur > wrote: >> After realizing that you mentioned all 8 GPIO lines were on the 20-pin >> expansion header J5 in the microdesktop case, I consulted the >> microdesktop schematic for clues. >> >> I suspect the UART and EOMA I2C pins should be left to those functions. > > yehyeh. UART implicitly tested "if console works it's probably > good" and I2C with a bus scan, i2c-utils, if 0x51 EEPROM shows up, > it's good. > >> I have added tables to the "Testing"[*] page under the "GPIO" section >> with my nominations for which pins to test and their mapping back to >> A20 register bits. > > awesome. it'll have to be done manually for now, Are you suggesting that the testing "will have to be done manually"? What is the time frame of "for now"? I'm trying to figure out which pins of the expansion header we want to test, which pins of the processor those correspond to, and thus which registers and bits of those registers we need to manipulate. That determines how I need to interact with the GPIO driver. >> Luke, does this match your understanding of the GPIO pins to test? > > yep - GPIO_19,20,21 missing. In the following table (created while I was trying to figure out which GPIO were connected in the EOMA standard) you will see that EOMA nets GPIO(18)/EINT3, GPIO(19), GPIO(20), and GPIO(21) are not connected on the microdesktop schematic v1.7 from J14. Thus they are at J14 but not available anywhere else in the microdesktop v1.7. 1342 Fri 23 Feb 2018: EOMA A20 DS113 microdesktop Net Name ball register CON15 pin J14 pin PWMB19 PI3 43 22 GPIO(10) EINT0 A6PH0 63 32 GPIO(11) EINT1 B6PH1 17 9 GPIO(16) EINT2 B2PH14 44 56 PWFBOUT GPIO(17) EINT3 C2PH18 39 20 NC GPIO(18) GPIO(19) A1PH15 40 54 NC GPIO(20) C1PH17 41 21 NC GPIO(21) B1PH16 42 55 NC We could obviously create a v1.8 schematic for the microdesktop and connect these EOMA nets to a header, if desired. ___ 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] Testing: GPIO
After realizing that you mentioned all 8 GPIO lines were on the 20-pin expansion header J5 in the microdesktop case, I consulted the microdesktop schematic for clues. I suspect the UART and EOMA I2C pins should be left to those functions. I have added tables to the "Testing"[*] page under the "GPIO" section with my nominations for which pins to test and their mapping back to A20 register bits. Luke, does this match your understanding of the GPIO pins to test? Reference: [*] http://rhombus-tech.net/allwinner_a10/testing ___ 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] Error trying to edit rhombus-tech wiki
Trying to edit wiki page to add my name to list interested in pre-production board, et cetera. Is that page privileged? Sincerely, Richard ___ 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: Your FOSDEM 2018 talk titled 'Crowdsupply EOMA68 Progress Report'
I just tried the link again and the status is 'Transcoding' so it sounds like maybe the review is complete and processing is underway? ___ 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] updates from eoma68-a20
Sent from my iPhone On Jan 29, 2018, at 20:35, Richard Wilbur wrote: > Are there enough 2.7.4 cards and microdesktop housings that I could buy one > of each to use for test development and software integration/porting? So I'd be interested in: Libre Tea Card (v2.7.4), $65 on CrowdSupply (prototypes typically more expensive, please let me know how much) Microdesktop Housing, $55 on CrowdSupply PCMCIA/EOMA68 Breakout Board, $20 on CrowdSupply USB + HDMI Cable Set for Standalone Operation, $15 on CrowdSupply Should I (pre-?)order them on CrowdSupply? What arrangements will work (shipping, et cetera)? I realize some of these may not be currently available. ___ 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] updates from eoma68-a20
On Jan 28, 2018, at 12:22, Luke Kenneth Casson Leighton wrote: > > folks, gotta do another update, i'm leaving for brussels in 16 hours > time. i have about *six* different things / meetings to do from the > 2nd-4th, i'm then going to the UK from the 7th to the 20th and back > again to Taiwan. Best wishes with all the travel and meetings. > i'm hand-couriering the remaining 2.7.4 Cards and > the Microdesktop Housings there, and will leave them there and get > them sent on. adam i'm thinking of you particularly. Are there enough 2.7.4 cards and microdesktop housings that I could buy one of each to use for test development and software integration/porting? I know we reworked the HDMI layout and changed the connector. You also changed a lot of the power supply decoupling capacitors. What other differences were there between 2.7.4 and 2.7.5? ___ 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] Testing: GPIO
On Fri, Jan 26, 2018 at 12:43 PM, Richard Wilbur wrote: [...] > I added some more details and selected "Save" and after awhile my > browser came back with a page that says only: > "An error occurred while writing CGI reply" I don't know whether this is a cause of the error but I had forgotten to type anything in the comment section. If that causes problems, sounds like it would be a fine candidate for input data validation. ___ 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] Testing: GPIO
On Tue, Jan 23, 2018 at 3:43 AM, Luke Kenneth Casson Leighton wrote: [...] > if it happens again please take a screenshot, it's important as it > means there's a bug in ikiwiki that is essential to report and get > fixed. I added some more details and selected "Save" and after awhile my browser came back with a page that says only: "An error occurred while writing CGI reply" ___ 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] Testing: GPIO
On Jan 23, 2018, at 03:43, Luke Kenneth Casson Leighton wrote: > if it happens again please take a screenshot, it's important as it > means there's a bug in ikiwiki that is essential to report and get > fixed. I will do so. Thank you for helping sort this out. By the way, do you happen to know in what language ikiwiki is written? ___ 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] Testing: GPIO
On Jan 23, 2018, at 02:08, Luke Kenneth Casson Leighton wrote: > On Tue, Jan 23, 2018 at 7:40 AM, Richard Wilbur > wrote: […] > git log compared to "Recent Changes" showed that there were 4 > revisions that hadn't been applied. That may explain why the displayed version of the page didn't change but the preview did change and when I logged out and back in all of my previous edits showed back up in the page source. > did you get at any point a failure of the "page updated" thing or at > any point interrupt the cgi script whilst it was rebuilding the page? > ikiwiki works by generating static HTML using cgi-bin perl scripts > that pull markdown (etc.) out of the git repository. it can be... a > little fragile. I got an error message that said there had been a failure of the CGI script--I don't remember the exact wording. If I did interrupt something I'm not sure how I accomplished that as I was trying to be patient and wait till it was done before initiating anything new. ___ 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] Testing: GPIO
On Sat, Jan 20, 2018 at 12:01 AM, Luke Kenneth Casson Leighton wrote: > anyway it's meant that i've had to ignore the pin numbers in the > schematic and go by pin positions. [...] so i left it for 3 years until i > had worked out / learned a technique to avoid that happening. I'm sorry to hear it has been such a thorn in the side! I went and read the EOMA68 specification since, as you mentioned, it is normative. I then tried to update the testing wiki page and it didn't seem to want to save my changes. I saved them off locally here so I can try to figure out the problem and then reapply the changes. ___ 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] EOMA Standard
As I was reading the EOMA standard[*] in the section entitled "Interoperability Restrictions imposed by height limits", I came across a statement Type III 8.0mm cards must be actively prevented from slotting into Type I (5.0mm) Housings by ensuring that there is a physical slot in the casework that is no more than 5.5mm in height. which I think would probably reflect your meaning better if rewritten as follows: Type III 8.0mm cards must be actively prevented from slotting into Type II (5.0mm) Housings by ensuring that there is a physical slot in the casework that is no more than 5.5mm in height. Because the previous paragraph dealt with restrictions on Type I Housings (which accept 3.3mm high cards) and this mentions 5.0mm cards (which correspond to Type II). Reference: [*] https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Pinouts_.28version_1.0.29 Sent from my iPhone ___ 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 SoC
That's awesome news on so many fronts! (libre LPDDR3 PHY, working relationship with MOSIS, possibility of funding, VHDL glue logic for interfaces, multiplexer GPIO bank, performance tuning a libre GPU, video coprocessors with DMA) Sounds like lots of fun! ___ 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] Testing: GPIO
Having taken a closer look I did find an equivalence mapping: DS113 microdesktop CON15 Net J14 pin name pin 1 SPI_MISO 1 2 SPI_MOSI 35 3 LCD0-D2 2 (LCDD2) 4 LCD0-D3 36 (LCDD3) 5 LCD0-D4 3 (LCDD4) 6 LCD0-D5 37 (LCDD5) 7 LCD0-D6 4 (LCDD6) 8 LCD0-D7 38 (LCDD7) 9 SPI_CLK 5 (SPI_SCK) 10 SPI_CE 39 (SPI_CS) 11 LCD0-D10 6 (LCDD10) 12 LCD0-D11 40 (LCDD11) 13 LCD0-D12 7 (LCDD12) 14 LCD0-D13 41 (LCDD13) 15 LCD0-D14 8 (LCDD14) 16 LCD0-D15 42 (LCDD15) 17 EINT1 9 (SC0-DETN) 18 POWER 43 (POWERON) 19 LCD0-D18 10 (LCDD18) 20 LCD0-D19 44 (LCDD19) 21 LCD0-D20 11 (LCDD20) 22 LCD0-D21 45 (LCDD21) 23 LCD0-D22 12 (LCDD22) 24 LCD0-D23 46 (LCDD23) 25 LCD0-CLK 13 (LCDCLK) 26 LCD0-VSYNC 47 (LCDVSYNC) 27 LCD0-HSYNC 14 (LCDHSYNC) 28 LCD0-DE 48 (LCDDE) 29 TWI1-SCK 15 (EOMA68-I2C-SCL) 30 TWI1-SDA 49 (EOMA68-I2C-SDA) 31 SD0-D3 16 32 SD0-D2 50 33 IR-RX 17 (VESA_SDA) 34 IR-TX 51 (GPIO_3) 35 SD0-CMD 18 36 SD0-CLK 52 37 SD0-D0 19 38 SD0-D1 53 39 NC 20 () 40 NC 54 () 41 NC 21 () 42 NC 55 () 43 PWM 22 (VESA_SCL) 44 PWFBOUT 56 (ETH_TAP) 45 UART0-TX 23 (EOMA68-UART_TX) 46 UART0-RX 57 (EOMA68-UART_RX) 47 ACIN-5V 24 (EOMA68-VCC-5V0) 48 ACIN-5V 58 (EOMA68-VCC-5V0) 49 NC 25 () 50 NC 59 () 51 EMAC-RDP 26 () 52 EMAC-RDN 60 () 53 EMAC-TDP 27 () 54 EMAC-TDN 61 () 55 NC 28 () 56 NC 62 () 57 ACIN-5V 29 (EOMA68-VCC-5V0) 58 ACIN-5V 63 (EOMA68-VCC-5V0) 59 DP1 30 (EOMA68-DP0) 60 DM1 64 (EOMA68-DM0) 61 GND 31 62 GND 65 63 EINT0 32 64 TTLREFOUT=VCC-3V3 66 (VREFTTL) 65 GND 33 66 GND 67 67 DP2 34 68 DM2 68 0 (GND) 0/2 (GND) 71 (GND) 72 (GND) 73 () 74 () ___ 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] Testing: GPIO
After looking at the schematics for the DS113 v2.7 2017-02-17 and the microdesktop v1.7 I feel the need to ask whether there are more up-to-date schematics available? Results of my sleuthing thus far attached. GPIO (General Purpose Input / Output) DS113 Schematic v2.7 2017-02-17 page 3, lists PA(18) with PA7-PA16 used as GPIO. PA7 ETXD0 PA8 ERXCK PA9 ERXERR PA10ERXDV PA11EMDC PA12EMDIO PA13ETXEN PA14ETXCK PA15ECRS PA16ECOL Datasheet page 13, lists these all as Type = I/O, Reset State = Z, Default Pull Up/Down = NO PULL, Buffer Strength (mA) = 20 Ball # PA7 ETXD0 E8 PA8 ERXCK D9 PA9 ERXERR E9 PA10ERXDV D10 PA11EMDCE10 PA12EMDIO D11 PA13ETXEN E11 PA14ETXCK D12 PA15ECRSE12 PA16ECOLD13 DS113 Schematic page 6, shows the U1-C pins for PA7-PA16 connected to the signals ethernet signals listed above. But DS113 Schematic page 13, which shows the 68-pin connector CON15, doesn’t mention any of these signals and has at least 8 pins named “NC”? The microdesktop housing board schematic v1.7 page 1 shows the 68-pin connector as J14 with pins labelled as PIN#NameConnected Net 16 GPIO_0 SD0-D3 50 GPIO_1 SD0-D2 17 GPIO_2 VESA_SDA 51 GPIO_3 GPIO_3 18 GPIO_4 SD0-CMD 52 GPIO_5 SD0-CLK 19 GPIO_6 SD0-D0 53 GPIO_7 SD0-D1 20 GPIO_8 54 GPIO_9 21 GPIO_10 55 GPIO_11 22 GPIO_12 VESA_SCL I haven’t yet found an equivalence mapping between the pinouts of the two 68-pin connectors of the two schematics. ___ 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] HDMI High-Frequency Layout: Recommendations
On Sep 20, 2017, at 13:27, Richard Wilbur wrote: > On Wed, Sep 20, 2017 at 1:57 AM, Luke Kenneth Casson Leighton > wrote: >> On Tue, Sep 19, 2017 at 11:26 PM, Richard Wilbur >> wrote: >>> I'm interested in >>> tracking down the power supply pins for the differential HDMI signals >>> as that is where our return path for common-mode signal has to go. >> >> there's no specific power pin for HDMI. the GND pins are grouped in >> with a whole stack of other GND pins, there's absolutely no way it's >> practical to get a special GND plane to it: the board is extremely >> full already. > > I'm not looking to provide any special connection to the power or > ground pins. I just want to make sure we don't obstruct the return > current path any more than necessary on its way from bottom reference > ground plane (layer 5) to top reference ground plane (layer 2) to the > power supply pins of the differential drivers: > 1. ground plane (layer 2) via to SoC ground pin land (layer 1) > 2. ground plane (layer 2) via to power supply decoupling capacitor > ground land (layer 1), through decoupling capacitor to land on power > supply trace (layer 1), through trace to SoC power supply pin land > (layer 1). > > The goal is to avoid unnecessarily impeding this return current path. > I'm trying to avoid making the path >~200mil and putting any major > obstruction (like a huge layer void) in the way. While browsing the A20 datasheet, I found that the HDMI section does have a power pin but not labelled the way I was asking you about. Page 18 mentions that VCC-HDMI is a power pin on ball #T13. On the schematic it is connected to net HVP which has power decoupling capacitor C108 which looks like "104" => 0.1uF. Looks like the path from the copper on layer 2 below the HDMI pins (balls #TUVW 22,23) on the SoC (processor) to the VCC-HDMI power pin (#T13) is ~300mil. It doesn't look overly impeded. ___ 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] Crowsupply update
On Jan 13, 2018, at 15:11, Luke Kenneth Casson Leighton wrote: > On Sat, Jan 13, 2018 at 10:05 PM, Richard Wilbur > wrote: >> I was just wondering whether there were more GPIO lines we could test (by >> hook or by crook). My goal is the best test coverage. > > i also have to think how to minimise testing time, as it will be > chargeable by the minute. either that or i do it... get *everything* > shipped to my apartment i always wanted an ultra-low-power > beowulf cluste... o :) From what I've seen, I think we can automate a lot of this so it takes a second or two per card. I expect our tall tentpole (the thing that's holding everything up) will be booting the card. Do you know how long it takes the bootloader to come up from power on? How long does it take GNU/Linux to get to user login after that? ___ 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] Crowsupply update
I am sorry if any of my comments came across with any flavour of criticism. I meant none towards anyone but myself. Thank you for the pointer to the Allwinner A20 documentation. I didn't know how easily available it was. I was just wondering whether there were more GPIO lines we could test (by hook or by crook). My goal is the best test coverage. No complaints about the EOMA specification or your design decisions on the microdesktop case. ___ 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] Crowsupply update
Last time I asked these questions I succeeded in hiding them in the middle of a bunch of other text. On Jan 9, 2018, at 06:26, Richard Wilbur wrote: > What kind of logic are these GPIO pins? (CMOS, TTL, etc.) The type of logic determines the input and output voltage and current source and sink characteristics (both capabilities and expectations). Do you have the Allwinner documentation for the A20--specifically for the GPIO pins? > So there are 4 pairs or 8 GPIO lines to test? (I thought we had more lines > dedicated to GPIO and two more that were going to be used as I2C for VGA? > Are only 8 easy to test?) ___ 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] Crowsupply update
On Jan 8, 2018, at 08:47, Luke Kenneth Casson Leighton wrote: > On Mon, Jan 8, 2018 at 3:32 PM, Neil Jansen wrote: >> Does the current housing design break EVERYTHING out? > > the microdesktop 1.7 brings everything out. as it's only 68 pins, 24 > of which are RGB/TTL, 4 are power, 8 are unused USB3, 7 are for > micro-sd and 4 are for USB2, there's actually not a lot left. 68 - (24 + 4 + 8 + 7 + 4) = 68 - 47 = 21 What are the remaining 21 pins? ___ 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] Crowsupply update
> On Jan 8, 2018, at 17:23, Luke Kenneth Casson Leighton wrote: > > On Mon, Jan 8, 2018 at 11:24 PM, Richard Wilbur > wrote: > >> It all sounds like fun! What can I help with first? > > well... perhaps... something simple like.. a simple program that tests > GPIO, assuming that say 4 hard-wires are connected between 8 GPIOs in > pairs, turning one into an input and the other an output, then setting > 0 and 1 and seeing if it's read correctly... then inverting each pair > (out becomes in, in becomes out) and re-running the test. I'd recommend resistors instead of wires. Something like 10KΩ because then if they are accidentally misconnected, Vcc(5V?) to ground would only amount to 0.5mA which is unlikely to stress anything unduly. What kind of logic are these GPIO pins? (CMOS, TTL, etc.) > something in either c or python that uses the sunxi-3.4 gpio driver: > > https://github.com/linux-sunxi/linux-sunxi/blob/stage/sunxi-3.4/drivers/gpio/gpio-sunxi.c > > that _should_ be exposed as /dev/gpio which should in turn appear in > either /sys or /proc... it should be a standard interface, with a > standard way to set which banks are activated... you might have to do > some digging. So there are 4 pairs or 8 GPIO lines to test? (I thought we had 14 lines dedicated to GPIO and two more that were going to be used as I2C for VGA? Are only 8 easy to test?) I'll assume I either get the connected pairs via an environment variable, the command line, or a file (filename passed on command line). ___ 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] Crowsupply update
It all sounds like fun! What can I help with first? ___ 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] Crowsupply update
On Jan 8, 2018, at 07:57, Luke Kenneth Casson Leighton wrote: >> On Mon, Jan 8, 2018 at 2:28 PM, Neil Jansen wrote: >> I do completely agree with his >> decision to get a few boards produced and tested before doing a complete >> run. Even with all the review, there are still plenty of possibilities for >> show-stoppers. > > the 2.7.4 board is the fallback. it'll be... without an HDMI > interface. that's just the way it'll be. One downside of the 2.7.4 board at this point is the changes in capacitor pricing that have been ameliorated only on version 2.7.5. Here's hoping the 2.7.5 board works! […] > software-wise i need something that does nothing more complex than > mount stuff on a micro-sd card, show boot messages on both screens, > and maybe has 2 keyboards plugged in (one into each USB socket) so > that they can bash some keys and see that crud comes up on-screen for > each. > > going beyond that... testing I2C, UART and the GPIO *sigh*... > that involves writing some software. I'd be happy to write some test software for I2C, UART, GPIO, etc. I've worked on drivers for those interfaces on embedded machines in the past. I also have experience creating and implementing software and hardware test designs. One example, I modified my employer's PCI VGA BIOS to test the card at boot which significantly streamlined testing of our cards. Another example, in order to test a design I created I2C driver and test code to demonstrate feasibility on a prototype and then incorporated it into production code in the BIOS and driver. Happy to collaborate on board bring up as well. I've worked on bringing up in-house boards for two employers: PCI graphics cards (for which we used oscilloscope and completed someone else's programmable logic design), embedded computers in different modules of high-speed wireless communications links (tools used: spectrum analyzer, oscilloscope, logic analyzer, PCI bus analyzer, MPEG protocol analysis software, processor In-Circuit Emulator, serial terminal). If you've got that covered, I'm happy playing the role of the ally you can describe the problem to and who, through listening to your description, helps you see the solution! Sincerely, Richard ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Jan 5, 2018, at 23:49, Luke Kenneth Casson Leighton wrote: > > On Sat, Jan 6, 2018 at 6:35 AM, Richard Wilbur > wrote: >> So the trick is how to choose a faster chip and integrate successfully into >> a system running at lower speed than it is specified for? > > yyup. have to use the 1800mhz 1.5v x8 DDR3 IC, which fortunately > happens to be down-compatible with 667mhz. the 1.35v DDR3L variant of > the same chip is *not*. I was doing a little reading about DDR3 and noticed the 1.35V DDR3L memory chips are happy talking/running with 1.5V DDR3 systems.[1] So are you saying the 1800mhz 1.35v x8 DDR3L IC is not happy running at 667MHz? (Clock rate incompatibility versus voltage incompatibility?) References: [1] https://en.m.wikipedia.org/wiki/DDR3_SDRAM ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Jan 5, 2018, at 23:49, Luke Kenneth Casson Leighton wrote: > > On Sat, Jan 6, 2018 at 6:35 AM, Richard Wilbur > wrote: >> So the trick is how to choose a faster chip and integrate successfully into >> a system running at lower speed than it is specified for? > > yyup. have to use the 1800mhz 1.5v x8 DDR3 IC, which fortunately > happens to be down-compatible with 667mhz. the 1.35v DDR3L variant of > the same chip is *not*. Your changes to the power supply capacitors and vias should help accommodate faster edges, etc. from the faster chips. > still, i cannot risk just relying on one possible DDR3 IC, so i will > have to source 1600mhz as well... and also last resort a 2gigabit IC > which will total, qty 4, only 1GBYTE of RAM. > > the budget's fixed... it's just the way it's going to have to be. > make adjustments that fit within the budget, end of story. Here's hoping the faster ones fit the budget and the circuit as I'm a big fan of providing as much RAM as possible! ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Jan 5, 2018, at 22:37, Luke Kenneth Casson Leighton wrote: > ok gerbers sent. waiting for confirmation from mike. Cheers! > with DDR3 > prices being insane i'm not going to push hard for the PCB to be made, > nor the assembly done in a hurry. Not having a rush on PCB fabrication or assembly may help control costs. Do you see DDR3 prices relaxing after Chinese New Year? ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Jan 5, 2018, at 23:27, Luke Kenneth Casson Leighton wrote: > On Sat, Jan 6, 2018 at 6:24 AM, Richard Wilbur > wrote: >> I am happy with the HDMI but I was going to ask about silkscreen on pads--I >> saw several instances of silkscreen on areas you'll want covered in solder. >> Sorry I didn't bring it up earlier. Not a problem if you aren't having the >> silkscreen printed. Your board fab may also do the right thing and move the >> offending notations. > > they do. they exclude silkscreen from solder mask areas. Wonderful! One less problem to worry about. ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Jan 5, 2018, at 21:50, Luke Kenneth Casson Leighton wrote: >> On Fri, Jan 5, 2018 at 4:02 PM, Richard Wilbur >> wrote: >> On Fri, Jan 5, 2018 at 4:05 AM, Luke Kenneth Casson Leighton >> wrote: >>> On Fri, Jan 5, 2018 at 8:27 AM, Richard Wilbur >>> wrote: >>>> On Fri, Jan 5, 2018 at 1:00 AM, Luke Kenneth Casson Leighton >>>> wrote: > > it's not. basically the trick has been, due to cramped space, to put > at least 2 VIAs around power decoupling capacitors (not done by me), > and they're just on the edge. space is pretty crowded and all > previous boards worked fine (and there's been a *lot* of > pre-production boards now). In that case, no problem. >> But I would definitely check out C3 on layer 1 as there seems to be a >> via in the middle of one of the pads. (Marked with red arrow in >> attached picture.) > > yehyeh good call that one was me, i had to reorganise the nearby > (East) power capacitors, and shuffle (West) the components next door, > in order to fit two (horizontal) 0603 4.7uF where there was previously > one (vertical) 0805 10uF. > > shuffled that VIA up as there's plenty of space. > > think we're good. Well I'm glad I looked and you had chance to fix it! > now the only concern is, blasted frickin apple, has sucked world-wide > demand not just for the entire supply of 0.1 10 and 100uF capacitors > but f*g DDR3 and eMMC *as well*. > > i now have to be extremely careful on selecting the right DDR3 RAM > ICs... *sigh*. So the situation is the chips at the speed you designed for are much more expensive while faster ones are cheaper? So the trick is how to choose a faster chip and integrate successfully into a system running at lower speed than it is specified for? ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Jan 5, 2018, at 21:28, Luke Kenneth Casson Leighton wrote: > > still doing these tiny little changes, it's just the way it goes: > every time you look at the board in close zoom, it's like... "hmmm, > yeah that could be improved" and this latest one, it's the (now pair > of) capacitors for the main DDR3 power stabilisation. > > previously this was a single 0805 capacitor lined up vertically. > there was plenty of connecting VIAs down to layer 4 DDR3 1.5v power > plane but because there were a MASSIVE array of tracks underneath > the GND pads there were no GND vias. whoops. and when replacing with > two 0603 4.7uF capacitors, i maintained that mistake. > > i decided to turn both 0603 capacitors horizontal and then to beef up > the number of GND vias. this has the unintended side-effect of > drilling quite a lot of holes into the layer 4 DDR3 1.5v power plane > however as the GND vias are at the edge of the plane i consider this > acceptable. i have however made sure that the plane is free of holes > for getting the actual 1.5v power *in* to the plane, if that makes any > sense. Good stuff. Should make the power supply more stable for the DDR3 RAM chips! > anyway a few more things like this... richardt if you're happy with the > beginning of the HDMI area i'll send the gerbers off straight away. I am happy with the HDMI but I was going to ask about silkscreen on pads--I saw several instances of silkscreen on areas you'll want covered in solder. Sorry I didn't bring it up earlier. Not a problem if you aren't having the silkscreen printed. Your board fab may also do the right thing and move the offending notations. ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Fri, Jan 5, 2018 at 4:05 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Jan 5, 2018 at 8:27 AM, Richard Wilbur > wrote: >> On Fri, Jan 5, 2018 at 1:00 AM, Luke Kenneth Casson Leighton >> wrote: >>> rectangular all-layers keepout, showing 1 and 3 here... damn layers 2 >>> and 5 have a weird shape (not enough clearance auto-generated) let me >>> make it an oval all-layers keepout instead... >> >> Those do look very nice, indeed! > > did the trick. pain doing them by hand, had to do the flood-fill, > then adjust the keepout, then write down by hand the distances that > the keepout fitted cleanly to the edges, _then_ throw that file away, > _then_ go back and put the rectangle left-right... bletch :) > > anyway i moved the PWM via up a bit, left the 3V3 VIAs where they > were - sorted. The results are great! Thanks for all the hard work to make it happen. So I'm happy with the layout of the HDMI! I checked for vias in component pads (manufacturability issue) and since the gerber viewer I'm using complains about all the tools in the drill file when I load it, I can't see the via holes. So there may be several false alarms in this list. Could even be mostly false alarms. But I would definitely check out C3 on layer 1 as there seems to be a via in the middle of one of the pads. (Marked with red arrow in attached picture.) Component Pads Encroach Vias? Layer 1 C59, C60, C71 *C3 Layer 6 C139 C341 C340 C345 C332 C343 C335 C43 C69 C70 C99 C86 C106 C107 C57 C45 C50 C105 C108 C85 C96 C54 C38 C55 C85 C40, C41, C44 C305, C307, C308 ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Fri, Jan 5, 2018 at 1:00 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Jan 5, 2018 at 7:44 AM, Luke Kenneth Casson Leighton > wrote: > >> there's a few more like that back at the source diff-pair vias, i'll >> think about whether to drop a plain square keepout in place (to >> preserve 15mil) or a straight manual track. track would cut clearance >> to around 12mil. thoughts? > > rectangular all-layers keepout, showing 1 and 3 here... damn layers 2 > and 5 have a weird shape (not enough clearance auto-generated) let me > make it an oval all-layers keepout instead... Those do look very nice, indeed! ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Fri, Jan 5, 2018 at 12:44 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Jan 5, 2018 at 7:32 AM, Richard Wilbur > wrote: >> Any >> chance we could use another trace to even up the little dimples that >> are left in the edge facing the differential pairs? > > always best to screenshot / arrow-mark it, richard. round-trip > delays getting critical here, we're up to 5th january already. I have attached a screenshot with red arrows. It is taken from the long straight differential microstrip transmission lines on layer 6. These are otherwise so clean and straight. > attached green arrows, i am guessing you mean, i remember you said > that causes... something-or-other... capacitance-related? The ones you marked weren't the ones I was looking at. I think they are probably fine as they aren't too sharp, they mind the 15mil clearance, and we are turning 90 degrees out of some signal vias onto the top of the board. (If they were pointing at a straight side I'd be more worried.) > there's a few more like that back at the source diff-pair vias, i'll > think about whether to drop a plain square keepout in place (to > preserve 15mil) or a straight manual track. track would cut clearance > to around 12mil. thoughts? It is kind of tumultuous with the pairs coming from close quarters on layer 1 and still to be sorted through the intra-pair skew-compensating wiggles. What you've done at that end looks much better. >> I glanced at parts of the rest of the board but it would be much more >> straightforward with the schematics. > > not so concerned about the rest of the board, it's mainly the HDMI. > PDF version of schematics should be here > http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf I'll concentrate on the HDMI, then. >> Do you have a way to compare >> changes with previous versions of the board to see if PADS did >> anything surprising behind your back? > > the only way would be visual pdf diffs, and i've made several minor > changes as well that would show up and need to be reviewed, one by > one, and eliminated. i've found it's easier just to go over the board > making minor tweaks, because each time i do so i find one more "little > thing" such as a place where there's a capacitor that doesn't have a > nearby GND via and so on. Sounds good. ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Wed, Jan 3, 2018 at 10:20 PM, Richard Wilbur wrote: > I notice that north of the long east-west transmission line, at the > northern keepout boundary on layer 6, there are a couple of vias that > have almost complete ground shield between the vias and the HDMI TX2 > pair. > > Question: What is the fill polygon width for ground fill on layer 6? > > I can see two fairly simple solutions to complete the ground shield > around these vias: > 1. Add traces to complete the ground shield between vias and HDMI > differential pair. > 2. Adjust trace/fill polygon width for ground fill on layer 6 till > the ground shield is complete. > > I'll sleep on it and take another look tomorrow morning. Looks like you already addressed this in the latest gerbers! Any chance we could use another trace to even up the little dimples that are left in the edge facing the differential pairs? I glanced at parts of the rest of the board but it would be much more straightforward with the schematics. Do you have a way to compare changes with previous versions of the board to see if PADS did anything surprising behind your back? Sincerely, Richard ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Wed, Jan 3, 2018 at 9:53 PM, Luke Kenneth Casson Leighton wrote: > On Thu, Jan 4, 2018 at 12:22 AM, Richard Wilbur > wrote: > >> My initial feedback is it looks pretty nice. I sat down, read the >> documentation >> for the gerber viewer that comes with KiCAD and started getting my feet wet. > > good god. you read documentation?? :) I scanned it fairly quickly to get a good idea of how to interact with the program. That way I had some idea what the icons meant and what functions were available in the user interface. (Okay, I've written documentation before so I figured since it was available I'd look it over. It gave me a pretty quick idea of how the user interactions are structured.) >> One recommendation for now as I have to leave for choir rehearsal--do >> the same thing with additional ground traces north and south of the ESD >> pads on layer 6 as you did on layer 1 to bring the distance between pad >> and ground down from 15mil to around the same as the pad-to-pad spacing >> of the ESD component pads. > > yep sorted. will send you new gerber set, for anyone else to see > (and also make it easier for you, richard) attached screenshot. Beautiful! I think that was the most important change I noticed. I am mainly looking at the HDMI which we have been laboring over the last few months. My next suggestion has an associated question: I notice that north of the long east-west transmission line, at the northern keepout boundary on layer 6, there are a couple of vias that have almost complete ground shield between the vias and the HDMI TX2 pair. Question: What is the fill polygon width for ground fill on layer 6? I can see two fairly simple solutions to complete the ground shield around these vias: 1. Add traces to complete the ground shield between vias and HDMI differential pair. 2. Adjust trace/fill polygon width for ground fill on layer 6 till the ground shield is complete. I'll sleep on it and take another look tomorrow morning. ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Jan 3, 2018, at 05:03, Luke Kenneth Casson Leighton wrote: > > ok i'm done with the 0805 10uF capacitors, and mostly-done messing > about looking at the gerber files for areas where ground tracks are > missing. currently i've added a keepout area around the DDR3 lines > because that's what i've seen done in other designs. > > gotta get moving on this, richard - it'll be another 5-6 weeks if we > miss the window of opportunity before chinese new year. My initial feedback is it looks pretty nice. I sat down, read the documentation for the gerber viewer that comes with KiCAD and started getting my feet wet. One recommendation for now as I have to leave for choir rehearsal--do the same thing with additional ground traces north and south of the ESD pads on layer 6 as you did on layer 1 to bring the distance between pad and ground down from 15mil to around the same as the pad-to-pad spacing of the ESD component pads. ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Dec 25, 2017, at 05:52, Luke Kenneth Casson Leighton wrote:
>
> On Sun, Dec 24, 2017 at 10:29 PM, Richard Wilbur
> wrote:
>> Concerning the keepouts under the connector:
>> 1. At the north boundary I would pull the edge up a little further north
>> away from the northwestern differential pair.
>
> oh! ha, i just made it the opposite direction :) reason: HHPD acts
> (kinda) as a GND for that top (HTX2P) and when i did the flood-fill it
> looked really weird. i'm switching to a couple of different viewing
> styles (one of them is actually the gerbers, there's an "X-Ray"
> option.
Looks like a good resolution of the issue.
> the top 2 VIAs right next to HTX2P are too far away, and the
> 15mil-to-GND-keepout condition makes things unbalanced. see proposed
> GREEN new via placements and YELLOW track to correct that.
I see how it is unbalanced with respect to the two differential pairs--the
outside conductors had close to 15mil clearance to ground but the inside
conductors had only the distance to the next pad (which was considerably less,
~7mil?). So I applaud the change to make it more symmetric.
> when i show X-ray-mode gerbers layers 1 & 2 i mark in yellow at top a
> proposed modification, look good? you can see to pin 4 there is that
> GND via, the shape of the hole gets really weird / sharp edges there.
I'm not seeing the weird / sharp edges so you must have fixed them?
> also i'm aware that the layer 2 and 5 bottom-most
> curved-shaped-keepout-holes are about 1 mil too far to the left, see
> yellow (SE corner) where i'll move them both over.
Again, I'm not seeing a problem so you must have fixed it.
>> 2. At the west boundary I see your point regarding layers 4 and 5.
>> Looks like you have made a good solution.
>> I suppose you could add 5mil additional overlap.
>> How much overlap does it currently have?
>
> currently arouuund 9mil roughly.
>
>> How much opening from the edge of the keepout
>> on layer 4 to the edge of the closest connector pads?
>
> around 4mil. tracks are 5mil so can use that as a scale.
In that case I think you have done enough. The overlap looks good.
>> Some of the adjustments on layer 6 might be taken care of by
>> modifying the net groups to create an "HDMI High-Frequency"
>> group which contains only the differential pairs {HTX2P, HTX2N, HTX1P,
>> HTX1N, HTX0P, HTX0N, HTXCP, HTXCN}, apply the 15mil conditional
>> clearance rule to that group.
>
> that's what's already done :)
>
> oh, except to VIAs i kept it at 5mil, now i remember. 15 mil to
> landing pads, 15 mil to tracks, 5mil to VIAs i think this was because
> i didn't want the holes made by VIAs to be too large. what you think?
> make them 15mil too?
I'm not as worried about the holes left by the vias on the east (connector) end
as the west (processor) end of the differential pairs if we expanded clearance
to 15mil. I'm guessing we have more current flowing through layers 2,4,5 over
there. I guess the question boils down to, "Where are the power sources and
sinks (including decoupling capacitors) relative to the HDMI high-frequency
signal vias?" If the vias make holes on a line connecting power sources to
sinks, then we need to either make sure there is plenty of copper providing a
path around the holes or minimize the size of the holes.
___
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] HDMI High-Frequency Layout: Recommendations--Taper
Thanks again for the pictures and the video.
Concerning the keepouts under the connector:
1. At the north boundary I would pull the edge up a little further north away
from the northwestern differential pair.
2. At the west boundary I see your point regarding layers 4 and 5. Looks like
you have made a good solution. I suppose you could add 5mil additional
overlap. How much overlap does it currently have? How much opening from the
edge of the keepout on layer 4 to the edge of the closest connector pads?
I would vote to keep the layer 5 holes under the layer 6 ESD pads for the same
reason we added them to layer 2 for the ESD pads on layer 1.
Some of the adjustments on layer 6 might be taken care of by modifying the net
groups to create an "HDMI High-Frequency" group which contains only the
differential pairs {HTX2P, HTX2N, HTX1P, HTX1N, HTX0P, HTX0N, HTXCP, HTXCN},
apply the 15mil conditional clearance rule to that group. Then see what issues
remain.
___
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] HDMI High-Frequency Layout: Recommendations--Taper
On Dec 22, 2017, at 20:38, Luke Kenneth Casson Leighton wrote: > On Fri, Dec 22, 2017 at 10:32 PM, Richard Wilbur > wrote: >> Here's another view of the connector end with some slight revisions of >> the ground fill and keepout boundaries between the ESD and connector >> components. >> >> Summary: >> >> 1. I moved the East extent of the layer 3 ground fill east to the >> edge of the connector pads. > > ok remember that ground flood-fill is the entire layer 3, i'm not > creating a *specific* area for ground "fill", it's done by default > according to the (specified) design rules. with the new "conditional" > rule added, layer 3 now looks like this: > http://hands.com/~lkcl/eoma/a20/275_hdmi/layer3.jpg > > so there's a few things i need to sort out, which i'll get to: main > reason for showing that image is: the clearance to the VIAs has also > extended to 15mil now. i believe it's not so much the vias though as > the tracks connected *to* the vias. if there has to be a 5 mil > clearance to those i can... maybe sort something out :) 15mil clearance to HDMI nets and vias won't hurt anybody's feelings! Looks good (minus the keepout under the connector). […] >> 3. The layer 2,3,4 ground keepout West edge moved with the East edge >> of the layer 3 ground fill to the edge of the connector pads. > > oh wait... i haven't put in a keepout *at all* on layers 3 and 4. > you think it would be best to punch the hole *right* down so that it's > only layer 5 providing a GND plane for both sides? it makes sense, i > just want to confirm. Yes, that is what I was asking for under the high-frequency differential signals at the connector. If you have reservations about it, let me know. I'm happy to get feedback from another perspective. ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Dec 22, 2017, at 20:22, Luke Kenneth Casson Leighton wrote: > On Fri, Dec 22, 2017 at 9:37 PM, Richard Wilbur > wrote: >> >> The reason for dropping the ground plane under the connector pins >> (layer 1) from layer 2 to layer 5 is that the pins are so close to each >> other. > > yyeahhh but so are the pins on the bottom layer ESD... which are > covered by the layer 5 GND keepout hole... it was under the connector > i was concerned about, with the VIAs on pins 4 10 and 16 (right-hand > row of 9) being guard VIAs that are within 5mil of HTX1P/N and > THXCP/N... Those ground vias I'm not so worried about as they don't look so much different to the proximity of neighbouring connector pins. ___ 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] HDMI High-Frequency Layout: Recommendations--Taper
On Dec 22, 2017, at 07:51, Luke Kenneth Casson Leighton wrote: > On Fri, Dec 22, 2017 at 8:54 AM, Luke Kenneth Casson Leighton > wrote: […] >> this is a pain! i might see if i can set a clearance to GND on >> individual tracks / connections as opposed to NETs. > > ok that worked. just uploading a video here: > > https://youtu.be/LfQc89CS4m0 > > turns out that there's a feature i'd not used before, called > "conditional rules". you can specify that *if* GND meets HDMI Group, > clearance rules shall be different. ordinarily you have to forcibly > set the *entire* GND plane to specific clearances (to ALL objects), or > the *entire* HDMI group to specific clearances (to ALL objects)... > this "conditional" rule does the trick. Nice work! That certainly simplifies things! > richard i go over it in the video but i believe the layer... 5 > keepout needs to also be extended under the layer 6 (blue, bottom) > tracks leading to the VIAs that jump up to the DC3 connector pads. > also i believe that i should be adding some tracks (pink) which, > particularly if there is to be a hole in layer 5 underneath, should be > around a 5 mil clearance, to match the fact that it's swapping > vertical distance for horizontal distance, what do you think? I believe that the right thing is to not extend the layer 5 ground keepout under the differential nets on their way out to the connector because it is the ground plane for layer 6. The reason for dropping the ground plane under the connector pins (layer 1) from layer 2 to layer 5 is that the pins are so close to each other. But we are still interested in the shielding effect of ground plane below the high-frequency signals (on the differential pairs) on layer 1 and between the signals on layer 1 and those sneaking under on layer 6. That's my reason for keeping layer 5 ground fill everywhere except under the layer 6 high-frequency pads of the ESD (where he drop to ground on layer 4). ___ 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
