arm-netbook January 2018

arm-netbook@lists.phcomp.co.uk

27 participants
38 discussions

EOMA Standard
by Richard Wilbur 22 Jan '18

22 Jan '18

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#Pinou… Sent from my iPhone

2 1

Re: [Arm-netbook] RK3399
by Pičugins Arsenijs 22 Jan '18

22 Jan '18

> 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. > ... > 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 have some EEE PCs (2 working and 2 spares), and I absolutely love them, I spent lots of time growing up with them, and learned to properly use command-line Linux while I was at it. My question - would you be interested in re-making it for EOMA-68 or something similar? I definitely am. EEE 701 has been thoroughly reverse-engineered, there are schematics available, as well as lots of interesting replacement parts. So, my plan: we'll need to re-place the motherboard, with something much more simple and much less power-guzzling. We'll also need to mod the chassis a little bit (to make an opening for an EOMA68 card). That's the extent of what we'll need to do - we won't need to replace anything in the upper half, and we'll be able to reuse many parts from the lower half. Here's how it goes: Screen: * The screen is RGBTTL, which is the same interface that an EOMA68 card has on its pinout. If my understanding is correct, it should be trivial to interface to. LVDS is used internally (for decreasing EMI, if I understand it correctly), and the upper half has a small board with LVDS2TTL IC - SN75LVDS86A. So, interfacing that to EOMA68 (specifically, the hardware side) would simply require using a TTL2LVDS IC - something like SN75LVDS84A, to convert EOMA's RGBTTL into LVDS. We'll be able to re-use the original LCD cable that way, too! * The LCD panel also has I2C, which is likely used for just interfacing to an EEPROM containing panel's resolution. If it's not only an EEPROM and there's some kind of control data going over there, it is likely sniffable using a 5$ logic analyzer (using all OSS software, too!). * I've got no idea if there's any kind of initialization sequence sent over TTL, but I think it's unlikely. If so, we might still be able to sniff it with a more advanced analyzer, or try to get a panel datasheet&init sequence somewhere (it is a popular panel, after all). So, we should be able to re-use the screen and all the surrounding parts - win! Battery: * Connector pinout is known, and desoldering the connector from the board is tricky but not too hard. * It uses a fuel gauge chip accessible over I2C, indeed. Thankfully, as I have two working EEEs (and three batteries), we should be able to sniff enough communication to determine which commands correspond to which data. Alternatively, it's very likely the fuel gauge's datasheet is available somewhere. * Charging the battery and powering the system will be a problem, indeed. Fortunately, the EEE's solution to this is documented, and we could, at the very least, learn from it - it's going to be an interesting journey for me, but nothing that's not been done by somebody else already. So, we should be able to re-use the battery - another big win! Other things we can re-use: * Camera is USB indeed, dead simple to interface. * Touchpad is PS/2, but that's not a big problem, PS/2 to USB converters are available cheaply. * Keyboard is a matrix one - but the pinout is known (the matrix isn't known though, but shouldn't be hard to figure out). Again, matrix-to-USB converters are both available cheaply, and DIY-able easily. * Speakers and microphone should be easily re-usable. Parts we won't be able to re-use: * Original Intel CPU, south and north bridges... We won't miss them, though =) * Embedded controller - the part that controls the power states, power button, LEDs, peripheral power (like, turning off the camera or the SD reader when they're not used). We can, and likely will, replace it with a microcontroller. * SD reader - it's too tightly integrated in the motherboard, even though it's USB. Desoldering lots of chips & support passives, as well as the connector, would be tricky, so it'd be best if we don't go that path. We might be able to use the SDIO from EOMA68 connector, though (alternatively, we could use that SDIO for WiFi). Also, we can simply add a USB SD reader, yay! * Ethernet - luckily, USB-ethernet chips are cheap and accessible, so if we need to add Ethernet, we can. * Audio - either an AC97 solution or a USB one will be suitable. * MiniPCI-E interface - no PCI-E on EOMA, maybe that's for the best, we don't need it for much (PCB layout would be tricky, too). Though I have to admit that a full-size WiFi would be nice to have. * SATA and IDE - again, godspeed, and we absolutely can use a converter chip if need arises. > 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. Totally agree. Once one does something, others can follow. The EEE PC was popular enough so that lots of other people can follow. Broken laptops and replacement parts are still available, too. > How to make the keyboard's matrix, I do not know. Interfacing to a keypad matrix is very easy nowadays. There are a lot of ready-to-go hardware and software solutions from the DIY keyboard community. > 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? As a rule of thumb, using HDMI internally, or converting high-speed interfaces into similar-but-not-quite high-speed interfaces, comes with an increased power consumption. You don't really want that - and it seems that EOMA68 should work without it, allowing us to use the HDMI for an additional display instead =) So, here's my summary - it's doable. If you're ready to work for this, we can have it done in half a year. I'll be more than happy to help (and I know some people that could help, too). However, there are a lot of parts that are small and easy, but time-consuming, and time is something I don't have much of, so expect there to be plenty of work for you =) Let me know (maybe email directly) if you're interested and ready to start working on this project together. Cheers! Arsenijs

2 1

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

22 Jan '18

-------- Original Message -------- From: Pičugins Arsenijs<crimier(a)yandex.ru> Apparently from: arm-netbook-bounces(a)lists.phcomp.co.uk To: "arm-netbook(a)lists.phcomp.co.uk" <arm-netbook(a)lists.phcomp.co.uk> Subject: Re: [Arm-netbook] RK3399 Date: Mon, 22 Jan 2018 18:47:02 +0200 > Pičugins Arsenijs<crimier(a)yandex.ru> Thank you for your email. There are a lot of pieces of information about this task. In this email I may forget to address some of them. I wanted a small eoma pc card notebook. That is why I obtained the asus 7inch eee pc 4g. When I got the notebook, I took out the mainboard because I wanted to see how much space is in the cabinet. As I mentioned, I wanted to convert the notebook to an eoma pc card notebook. Because shipping of the pc card keeps being delayed I have not done more about it. I mentioned the rk3399 mainboard, because it maybe would be an option if the pc card does not get made. > If you're ready to work for this Yes, but we have to set some references. I am not skilled on electronics. I will have to move on instructions. Costs may spiral. I am not going to accept that. If I am asked to buy a 100usd device, I will answer no. If I am asked to buy a 50usd device, I will likely answer no. I will comment briefly on what you wrote about various computer devices. > The screen is RGBTTL, which is the same interface >that an EOMA68 card has If we in a low priced way can get to use the build in display, that is what we should do. I mentioned getting a 7inch hdmi display if that was the only workable solution. My notebook is an asus 7inch eee pc 4g. I do not know the precise name of the build in display. Camera is not important. We will use the camera as an usb camera. Else we will not use it. About wifi card, I have small usb ar9271 wifi cards. They work on debian 9 64bit main. Saying the source software is available. We should use an usb ar9271 wifi card. About sound. I have an usb soundcard. It works on debian 9 64bit main. Saying the device's source software is available. We should use an usb soundcard. About sdcard reader. I have usb sdcard readers. They work on debian 9 64bit main. Saying the devices' source software is available. We should use an usb sdcard reader. About storage. My information is, the pc card will have an sdcard port on the pc card for storage. > matrix-to-USB converters are both available Turning the keyboard into an usb keyboard is an important move. I suggest we make turning the notebook's keyboard into an usb keyboard our first step. About a battery supplying power. I suggest we wait until we have a notebook, which will run on a power supply. > maybe email directly Maybe this modification of a notebook is of interest for other people. We should use this email list. > 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

1 0

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 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

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 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

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 Design has twin 32-bit-wide LPDDR3 ICs so there is the possibility of getting not just decent performance but also low power at the same time. l.

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. This would make early debugging harder, because EEPROM detection has to be integrated in very early code, and early code can't simply use the UART as an unconditional debug channel, that's guaranteed to reach the outside of the card, anymore. The section "Requirements for UART"[2], however, states: "As this problem is to be taken care of on the I/O Board[3] it is worth observing that CPU Cards do not require UART buffering.", suggesting that the "Start-up procedure" section simply left out UART as one of the interfaces that do not need to be tri-stated by mistake. But I am unclear about the part "CPU Cards do not require UART buffering": - Does it mean that CPU cards do not require the housing board to perform UART buffering, because they do it themselves? - Or does it mean that CPU cards are not required to perform UART buffering? So, can a CPU card assume that it may use the UART right after reset, without first consulting the EEPROM? (I understand that if a housing board has, for example, a Bluetooth module connected to the UART, something must make sure that none of that early debug output reaches the BT module, but I guess one could easily enough have a GPIO pin that controls whether the UART is cut off from the BT module, and the OS could toggle this pin once it knows that it won't send debug output anymore. The same GPIO pin might also control if the Bluetooth module is powered up at all.) Best regards, Jonathan Neuschäfer [1]: https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Start… [2]: https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Requi… [3]: As a side-note, the term "I/O Board" is a little bit unclear to me: Both CPU cards/boards and housing boards perform I/O. I figured that "I/O board" means "housing board", but I (personally) think the spec would be clearer if it talked about "housings" or "housing boards" in the first place.

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 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.

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook January 2018