arm-netbook

arm-netbook@lists.phcomp.co.uk

1079 discussions

Re: [Arm-netbook] RK3399
by ronwirring＠Safe-mail.net 20 Jan '18

20 Jan '18

-------- Original Message -------- From: Christopher Havel <laserhawk64(a)gmail.com> Apparently from: arm-netbook-bounces(a)lists.phcomp.co.uk To: Linux on small ARM machines <arm-netbook(a)lists.phcomp.co.uk> Subject: Re: [Arm-netbook] RK3399 Date: Thu, 18 Jan 2018 22:49:12 -0500 > BTW -- not *everything* is nearly as complex as Luke would have you > believe. If I ask about how to build a libre software mainboard into the cabinet of a common notebook, lkcl gets rather … [View More]hectic on rebuffing such option. Some of his arguments I accept. Others I do not. One lkcl argument is, I should not spend thousands of usd on making an attempt with an uncertain outcome. I agree on that. For now I have spent 50usd on getting an asus 7inch eeepc. I like the size of it. It has a full keyboard. It is bulky. Therefore more likely to have space for building in another mainboard. Lkcl says, should I succeed in building one, only I would benefit. I disagree. I would tell others how to make a similar computer, should they want to. Then lkcl has this argument about reverse engineering a lot of computer devices. I do not understand it. Apart from the display all devices should be usb. Sound, touchpad, keyboard, ethernet, wifi, storage. Display should be hdmi. Rather I believe getting a battery and powersupply solution would be difficult. I would also like to make a libre software computer looking like the pocketchip. I have bought this generic 6usd keyboard. https://images-na.ssl-images-amazon.com/images/I/51q2r5Jvu2L.jpg I do not like the feel of the keys. Apart from that it is adequate sized. The keyboard does not work via usb wire. It would require the keyboard to get modified. > Keyboards are invariably a passive switch matrix (look it up if you don't > know About the asus eeepc's keyboard. I have. I am not clever enough. Lowpriced on ebay I found an ATMEGA328P-PU Microcontroller. A GPIO kit Extension Board Adapter Breadboard. A flat cable Ribbon connector socket 30pin 1.0mm Pitch. Apparently using a raspberry pi, you should be able to program the microcontroller. How to make the keyboard's matrix, I do not know. > Touchpads are almost always either USB or PS/2 What I have been told. > It's the screen and battery interfaces that are going to get you This rk3399 mainboard https://www.cnx-software.com/2016/12/05/firefly-rk3399-rockchip-rk3399-deve… has a hdmi port. What should be the difficulty in connecting the mainboard to a hdmi display? > arm-netbook mailing list arm-netbook(a)lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook(a)files.phcomp.co.uk [View Less]

1 0

[Arm-netbook] http://www.emff.urjc.es/members/arrayas_files/Articles/PhysRep.pdf
by Luke Kenneth Casson Leighton 18 Jan '18

18 Jan '18

hi theo, been talking to the mathematician behind that paper on knots, he explained that the "null condition" is where the EM field is... zero, and that the E is perpendicular to M at all points. it's not the same thing as the "non-radiating condition" for which you have to take a fourier transform. he sent a link to the above paper which he said may have some clues about non-radiating conditions. l.

1 0

Re: [Arm-netbook] RK3399
by ronwirring＠Safe-mail.net 18 Jan '18

18 Jan '18

-------- Original Message -------- From: Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> Apparently from: arm-netbook-bounces(a)lists.phcomp.co.uk To: Eco-Conscious Computing <arm-netbook(a)lists.phcomp.co.uk> Subject: Re: [Arm-netbook] RK3399 Date: Wed, 17 Jan 2018 20:26:32 +0000 > use the rk3399 in a libre fashion? Can you make a fsf compliant notebook based on the rk3399 mainboards I have seen for sale? All libre software is available except the gpu one? > arm-netbook … [View More]

2 1

RK3399
by Luke Kenneth Casson Leighton 17 Jan '18

17 Jan '18

thank you very much to the anonymous person who pointed me at a *FULL* Rockchip RK3399 Reference Design including Technical Reference Manuals, full schematic file and full PCB CAD design files. using that design it will be possible to create an amazing CPU Card... unfortunately running MALI. http://rockchip.wikidot.com/rk3399 this shows that it has USB3 however it does not have RGB/TTL, so it will be necessary to do a conversion from MIPI to RGB/TTL with an SSD2828 or similar. the Reference … [View More]

3 6

Early UART output vs. housing board discovery
by Jonathan Neuschäfer 17 Jan '18

17 Jan '18

Hi, what follows are a few questions/remarks/misunderstandings regarding the UART pins during early boot. In the EOMA68 specification, the section "Start-up procedure"[1] specifies that "It is required that all pins be disabled (floating tri-state) with the exception of the I2C Bus, the 5.0v Power and the Ground Pins.", which would mean that *any software* running on a CPU card is required to check the housing board's EEPROM before it may output any data on the UART, if I read it correctly. … [View More]

3 17

HDMI High-Frequency Layout: Recommendations
by Richard Wilbur 17 Jan '18

17 Jan '18

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Thu 3 Aug 2017 Recommendations for this Layout Source (processor) end: Could we shrink the via pitch between constituents of a differential pair (bring the vias of a differential pair closer to each other) and combine the anti-pads into an oval shape on each layer? This reduces fringing fields and thus parasitic capacitance. I like the ground vias close to the signal vias between differential pairs. It would be lovely to get a ground … [View More]via close to the via on HTX2P and possibly move the one between HTX2N and HTX1P closer to the signal vias (if the signal vias of pairs can be moved closer with combining the anti-pads). What is the intra-pair skew from the processor lands to the first signal vias? I wonder if we could move the vias on the short lines a little further from the processor and make up some of the skew in that segment before we leave it? Sink (connector) end: Same thing for differential pair vias--HTX0 and HTX2--it would be lovely to shrink the via pitch and combine anti-pads (if possible). Again, I like the ground vias close to the signal vias HTX2P, HTX2N, and HTX0P. It would be lovely to be able to either put a new ground via closer to the signal via on HTX0N or move the one on the ground shield trace closer. I like what you were showing on the video with the signal vias at the connector lands: putting a neck on the trace between the via and the land should dampen the spirits of the solder but not the signals. If we could reduce the signal via pitch by combining anti-pads at the connector, we might be able to move the HTX1P and HTXCN signal vias to the other side of the lands next to the other side of the differential pair, thus equalizing the skew on the segment between the ESD chip pads and the connector pads. If that worked the final touch might be to add a ground via between DC3 pin 10 (GND) and the board edge for return current paths. Other than that, I would try and move as much of the skew compensation close to the source of the skew as possible. I'm not sure what I'm looking at as you mentioned the ground reference planes were solid under the HDMI differential pairs, but it looks like they have voids under the signals in the pictures. Am I seeing a negative, that there are only little strips of conductor in the ground reference plane directly under the high-frequency lines? Neither of these interpretations is very satisfactory, nor do they seem to represent reality. Please let me know what can and can't be done and I will adjust recommendations accordingly. [View Less]

4 143

http://www.nano-di.com/dragonfly-2020-pro
by Luke Kenneth Casson Leighton 10 Jan '18

10 Jan '18

oooo i want one! this can do 4 mil track widths and 5 mil clearance... it could handle the EOMA68-A20 PCB no problem whatsoever! that's 5mil tracks, 5mil clearance. for the RK3288 however it would not do the job: that has 0.6mm pin-pitch BGA and eMMC and you need 3mil track widths and 3mil clearance for that.... this is getting really exciting, this 3D printing of PCBs. l.

2 1

Re: [Arm-netbook] Crowsupply update
by Pičugins Arsenijs 09 Jan '18

09 Jan '18

> 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. Speaking about I2C, UART and GPIO testing - it sounds easy. I don'… [View More]t yet know which defects you'd want to cover with tests (mechanical, soldering, faulty parts, maybe all of them), but, as far as my research goes, you can test both UART and GPIOs with a loopback test, and I2C could be tested using a simple device - such as an EEPROM. Now, I don't have as much testing experience, but I've done a couple of DIY jigs - not automated, but that's yet to come - and I've been thinking about a way to make testing jigs. First thing is - it's best if the test program runs on the computer card itself. I see that's what you plan to do, and, if I'm not mistaken, cards are going to boot from a MicroSD card anyway - which is what's needed. Testing GPIOs can be done easily from software - connect GPIOs in pairs using resistors (say, 470ohm, just in case one of GPIOs is shorted to ground/VCC for some mechanical reason). Set first GPIO as input, second as output, then toggle the second GPIO and check that value that's read from the input is the same as value that's on the output. With more complicated interfaces, it depends. I2C should be testable by using an I2C device - since you have an EEPROM inside the card, it makes sense to first test if that's accessible, then test another device that's located in the test header (say, a GPIO expander or an ADC, you could use both of those for testing, too.) You can test SPI in loopback mode by connecting MISO and MOSI together, though you won't test SCK and CS that way. UART should easily be testable with a loopback - though I think you won't want to have the loopback hard-wired, to make sure that U-Boot messages won't get into U-Boot input and stop the boot process, or something of that kind =) If you want to test USB, you don't even need to have engineers mash on the keyboard, attach two USB devices with unique IDs (say, CP2012 - you can program those through USB connection) and make sure they're recognized - in case of CP2012, you can make a loopback test of their UART, just to make sure data passes through... Not sure how much sense it'll make, though =) Now, speaking about SDIO and parallel video interfaces that you have in EOMA68 pinouts, I have no idea how to test them automatically =( But the test I listed cover most mechanical pins, and half of the peripherals, which is already pretty good for avoiding RMAs of cards with bad solder joints in the USB or I2C lines. They're also cheap enough in terms of hardware& software required. So, the end result could be: a MicroSD card with a stripped down image of something something Linux that boots as quickly as possible (with cruft like networking disabled), shows the boot log on HDMI monitor - then draws a table on the monitor (I imagine it being a fullscreen application working with framebuffer, to avoid having to wait for X to load). Cells of that table would be filled with green or red, depending on whether tests pass on fail - and an all-green monitor would indicate all is well =) This should make for streamlined&quick testing and avoid lots of manual work (excluding that, well, you still have to plug the card into the testing jig and plug the cables in). Now, I don't have *that* much experience, I don't know which failures you want to protect against, but if I were to test these cards, this is what I'd do. Cheers! Arsenijs [View Less]

2 1

Software as a Community Service
by Jean Flamelle 08 Jan '18

08 Jan '18

In an ideal global community, there would be distributed to every language-bearing living being a modicum of electronic networking and information rendering hardware. That isn't going to be any day soon. I identify with arguments against SaaS,---and posed them to Urbit's bugtracker in issue 911---however software as a community service, without any potential for personal or collective gain that couldn't achieved by any kek of equal mind without prior reputation or special location, will include … [View More]

1 0

Re: [Arm-netbook] EOMA68 / Libre RISC-V team financing
by ronwirring＠Safe-mail.net 07 Jan '18

07 Jan '18

-------- Original Message -------- From: Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> Apparently from: arm-netbook-bounces(a)lists.phcomp.co.uk To: Linux on small ARM machines <arm-netbook(a)lists.phcomp.co.uk> Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing Date: Wed, 27 Dec 2017 09:59:04 +0000 > i find sources of funds Have you considered talking to http://www.lowrisc.org/? I do not think they have money. Maybe lowrisc can direct you to paid tasks. > arm-… [View More]

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook