arm-netbook May 2017

arm-netbook@lists.phcomp.co.uk

47 participants
94 discussions

Re: [Arm-netbook] firefly 3399 all source software disclosed?
by ronwirring＠Safe-mail.net 09 May '17

09 May '17

Best knowledge is, that new intel and amd processors cannot be reverse engineered. What in regard of the latest mali gpus? If you have the money, they can be reverse engineered? -------- Original Message -------- From: Lauri Kasanen <cand(a)gmx.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] firefly 3399 all source software disclosed? Date: Mon, 8 May 2017 17:52:45 +0300 > On Mon, 8 May 2017 17:39:17 +0300 > Bill Kontos <vkontogpls(a)gmail.com> wrote: > > > Imagination is far from dead yet. They did a mistake when they based all of > > their gpu income on apple, but their ip is rather advanced. Also on the > > plus side there has been discussion about them open sourcing their drivers > > a few months back and afterwards they hired new developers. I wouldn't be > > surprised if they actually saw this coming and reacted before it happened. > > They're openly considering selling MIPS, as well as other parts of > them. That goes against knowing things would go this way. > > - Lauri > > _______________________________________________ > 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

3 3

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP
by doark＠mail.com 08 May '17

08 May '17

I apologize for DOS'ing the list, I can only get online about once a week. On Thu, 4 May 2017 17:13:23 +0200 "mike.valk(a)gmail.com" <mike.valk(a)gmail.com> wrote: > > 2017-05-04 9:04 GMT+02:00 John Luke Gibson <eaterjolly(a)gmail.com>: > > > Since it seems like a trivially simple task that for some reason no > > one has taken up, I would like to take the opportunity to exercise a > > learning experience and simultaneously benefit the community, by > > liberating PocketCHIP by deblobbing the source and re-compiling. > > > > The PocketCHIP is powered by their SoM: > http://linux-sunxi.org/NextThingCo_CHIP > > That is apparently a Allwinner R8 pared with an external rtl8723bs > Wifi/BT chip. > > The R8 is a rebranded A13. What? I own one of those and I'm almost certain that the CPU is an A7. Let's boot the PocketCHIP up... The processor is detected as an A7. I'll attach the output, it would probably be interesting to see all of it... Done, it's compressed bzip2 since it's ~300KiB decompressed which is large for an email. <aside> I'm not too clever with gpg yet, so please tell me if the compressed file is also signed (I wanted to do that so that you could be certain that it was not infected en-route like happens to MS .cab files far to frequently (even though I don't have my key signed by anyone yet \me grumble grumble)). </aside> Unless your saying that the WiFi has a built in ARM R8 (Why)? which would really surprise me considering how large the processor chip is compared with the WiFi chip. > If you look at > https://getchip.com/pages/chip > > You'll see: > On the left image the RAM (Hynix) and Wifi+BT (Realtek) and Power module > (Allwinner AXP209) > On the right the SoC (R8/A13) and NAND (Samsung) > > The A13 does not need blob's to run anymore, the WiFi+BT chip does. > AFAIKT > > Display output needs some checking in Linux and U-boot mainline. But > most should be available or somewhat easily hacked in. > > GPU needs a BLOB which does not work on mainline AFAIKT. Luc Verhaegen > did get quite far before he burned out. <snip> You're not giving us enough details. Who is Verhaegen? What did he burn out on? When I first considered purchasing a PocketCHiP I read about the GPU not having 3D capabilities because of a binary blob. So, the CHIP folks hired (I think it was an extended goal of the kickstarter campaign), a kernel dev to add support to the Linux kernel for the GPU. I was going to mention this on this list before, but it's been so active... Sincerely, David

5 5

Re: [Arm-netbook] first prototype microdesktop casework
by doark＠mail.com 08 May '17

08 May '17

I apologize for DOS'ing the list, I can only get online about once a week. On Sat, 29 Apr 2017 12:42:29 +0100 Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> wrote: > > On Sat, Apr 29, 2017 at 6:08 AM, Luke Kenneth Casson Leighton > <lkcl(a)lkcl.net> wrote: > > http://rhombus-tech.net/community_ideas/micro_desktop/news/ > > ok, ouch, onto the fourth revision of the corner-pieces already, and > some minor changes to the plywood are needed as well. this really > would have been awkward if someone else did it. > > the anycubic 3d printer is holding up well. the higher-quality PLA > from the company i found on aliexpress seems reasonable so far (the > "standard" quality definitely isn't: it literally crumbles under > pressure). <snip> Luke, (I can call you Luke, since you sign your name that way, right?) PLA stands for Poly-Lactic-Acid and if they are selling you something else you can complain, if not sue for false advertising. That's why we label things, so that we know what they are, right? So one PLA aught to be the same as any other. Aluminum is aluminum, titanium is titanium, why is PLA not PLA? I own a Reach3D printer. It's an all aluminum housing and z axis gear printer. I'm still in the construction phase, but if me and my caliper (it's auto-calibrating but I want it perfect :) work well together then I should be printing sometime around the 21st. I could help you with my printer at limited expense (unless something big happens in my life :) Also, I bought on Amazon 2 spools of PLA and one of PC. The PLA cost ~$20 per KG while the PC was ~$30. It seems to me that you might be better off with PC if finding a good PLA supplier and making a case that is not flimsy with PLA is such a problem. Sincerely, David

2 2

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP
by ronwirring＠Safe-mail.net 08 May '17

08 May '17

Is it common to do something like this against a person? -------- Original Message -------- From: Bill Kontos <vkontogpls(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] Side-Topic: Liberating PocketCHIP Date: Mon, 8 May 2017 12:14:50 +0300 > Verhaegen is one of those selected individuals who had the luxury of getting all the shit of the world thrown at their face for trying to do the right thing. He was one of the leaders in pushing amd into mainlining gpu drivers( which they have been successful to and keep working on) and got shit for that. He attempted to reverse engineer the arm mali drivers( look up lima driver) and he succeeded to some extend, then he run out of money becaue nobody was willing to help him and arm has put significant effort into destroying his life. The nda a company has to sign for getting the mali drivers requires 0 interaction with his work, therefor no company can hire him now. > > On May 8, 2017 8:02 AM, <doark(a)mail.com> wrote: > > > > I apologize for DOS'ing the list, I can only get online about once a week. > > > > On Thu, 4 May 2017 17:13:23 +0200 > > "mike.valk(a)gmail.com" <mike.valk(a)gmail.com> wrote: > > > > > > 2017-05-04 9:04 GMT+02:00 John Luke Gibson <eaterjolly(a)gmail.com>: > > > > > > > Since it seems like a trivially simple task that for some reason no > > > > one has taken up, I would like to take the opportunity to exercise a > > > > learning experience and simultaneously benefit the community, by > > > > liberating PocketCHIP by deblobbing the source and re-compiling. > > > > > > > > > > The PocketCHIP is powered by their SoM: > > > http://linux-sunxi.org/NextThingCo_CHIP > > > > > > That is apparently a Allwinner R8 pared with an external rtl8723bs > > > Wifi/BT chip. > > > > > > The R8 is a rebranded A13. > > What? I own one of those and I'm almost certain that the CPU is an A7. > > Let's boot the PocketCHIP up... > > The processor is detected as an A7. > > I'll attach the output, it would probably be interesting to see all of > > it... > > Done, it's compressed bzip2 since it's ~300KiB decompressed which is large > > for an email. > > > > <aside> > > I'm not too clever with gpg yet, so please tell me if the compressed file > > is also signed (I wanted to do that so that you could be certain that it > > was not infected en-route like happens to MS .cab files far to > > frequently (even though I don't have my key signed by anyone yet > > \me grumble grumble)). > > </aside> > > > > Unless your saying that the WiFi has a built in ARM R8 (Why)? which would > > really surprise me considering how large the processor chip is compared > > with the WiFi chip. > > > > > > > If you look at > > > https://getchip.com/pages/chip > > > > > > You'll see: > > > On the left image the RAM (Hynix) and Wifi+BT (Realtek) and Power module > > > (Allwinner AXP209) > > > On the right the SoC (R8/A13) and NAND (Samsung) > > > > > > The A13 does not need blob's to run anymore, the WiFi+BT chip does. > > > AFAIKT > > > > > > Display output needs some checking in Linux and U-boot mainline. But > > > most should be available or somewhat easily hacked in. > > > > > > GPU needs a BLOB which does not work on mainline AFAIKT. Luc Verhaegen > > > did get quite far before he burned out. > > <snip> > > > > You're not giving us enough details. Who is Verhaegen? What did he burn > > out on? > > When I first considered purchasing a PocketCHiP I read about the GPU > > not having 3D capabilities because of a binary blob. So, the CHIP folks > > hired (I think it was an extended goal of the kickstarter campaign), a > > kernel dev to add support to the Linux kernel for the GPU. I was going to > > mention this on this list before, but it's been so active... > > > > Sincerely, > > David > > > > _______________________________________________ > > 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 > >

3 2

Re: [Arm-netbook] firefly 3399 all source software disclosed?
by ronwirring＠Safe-mail.net 08 May '17

08 May '17

All software for the mali-t860 is open source? -------- 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: Re: [Arm-netbook] firefly 3399 all source software disclosed? Date: Sun, 7 May 2017 14:06:18 +0100 > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Sun, May 7, 2017 at 10:53 AM, <ronwirring(a)safe-mail.net> wrote: > > https://www.kickstarter.com/projects/1771382379/firefly-rk3399-six-core-64-… > > Has all source code for the computer been disclosed? > > as far as i was able to ascertain when i last checked: yes. u-boot > and linux kernel, no proprietary pieces at all. > > > Lkcl has says, he can make use of the rk3399 if he has the processor's data sheet. > > i already have the datasheet. it's the reference design that i need. > > > What data about the rk3399 does lkcl not have? > > i need a reference design. full schematics, full pcb layout. > > > What is the performance of the rk3399 processor compared to a x86 dual core 2ghz? > > the rk3288 already outperforms a dual-core intel atom. > > l. > > _______________________________________________ > 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

6 11

Re: [Arm-netbook] libre 64-bit risc-v SoC
by doark＠mail.com 08 May '17

08 May '17

I apologize for DOS'ing the list, I can only get online about once a week. On Fri, 28 Apr 2017 13:58:57 +0100 Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> wrote: > > On Fri, Apr 28, 2017 at 12:47 PM, mike.valk(a)gmail.com > <mike.valk(a)gmail.com> wrote: > > > If you're trying to trans-code something that you don't have a > > co-processor/module for you're forced to CPU/GPU trans-coding. > > you may be misunderstanding: the usual way to interact with a GPU is > to use a memory buffer, drop some data in it, tell the GPU (again via > a memory location) "here, get on with it" - basically a > hardware-version of an API - and it goes an executes its *OWN* > instructions, completely independently and absolutely nothing to do > with the CPU. > > there's no "transcoding" involved because they share the same memory > bus. > > > Would a FPGA > > still be more power huns gry then? > > yes. > > > I think/hope FPGA's are more efficient for specific tasks then > > CPU/GPU's > > you wouldn't give a general-purpose task to an FPGA, and you wouldn't > give a specialist task for which they're not suited to a CPU, GPU _or_ > an FPGA: you'd give it to a custom piece of silicon. I always thought that FPGA's were good for prototyping or small fast tasks... But that's just how I learned about them. > in the case where you have something that falls outside of the custom > silicon (a newer CODEC for example) then yes, an FPGA would *possibly* > help... if and only if you have enough bandwidth. > > video is RIDICULOUSLY bandwidth-hungry. 1920x1080 @ 60fps 32bpp > is... an insane data-rate. it's 470 MEGABYTES per second. that's > what the framebuffer has to handle, so you not only have to have the > HDMI (or other video) PHY capable of handling that but the CODEC > hardware has to be able to *write* - simultaneously - on the exact > same memory bus. > <snip> Your number seemed off to me so I did the math: 1920*1080*60*4 == 497,664,000 You're off by almost 30 MiB. Most video cameras (that I've been able to locate), do 24bpp, 640x480 at 30fps, so that would make the bandwidth requirements. 27,648,000 Which should be more reasonable for an FPGA (not that I have all the specs sitting in front of me, mind you). I am assuming that "encoding video" means encoding from a video camera or a small youtube video as opposed to encoding to send to a device over, say, an HDMI cable. > > > We can always have evolution create a efficient decoder ;-) > > https://www.damninteresting.com/on-the-origin-of-circuits/ > <snip> Sincerely, David

2 1

Re: [Arm-netbook] The open risc v idea is good
by doark＠mail.com 08 May '17

08 May '17

I apologize for DOS'ing the list, I can only get online about once a week. On Wed, 3 May 2017 11:38:26 +0100 Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> wrote: > On Wed, May 3, 2017 at 11:28 AM, zap <zapper(a)openmailbox.org> wrote: > > > > > > On 05/03/2017 01:01 AM, Luke Kenneth Casson Leighton wrote: > >> --- > >> crowd-funded eco-conscious hardware: > >> https://www.crowdsupply.com/eoma68 > >> > >> > >> On Tue, May 2, 2017 at 10:50 PM, zap <zapper(a)openmailbox.org> > >> wrote: > >>> I assume that's going to be the third series of libre cards right? > >>> you making a lowrisc based processor and graphics, etc, > >> more likely the fourth or fifth. all these things happen in > >> parallel. the one after the RK3288 to investigate is the RK3399 > >> (6-core). also i've heard that the iMX7 is out so am having a look > >> at that. > > > > RK3399... 11.0 ghz speed if you count all the four cores which are 2 > > ghz each and 1.5 for the other ones... > > > > wow... > > > > I wonder how much watts that processor uses... > > > > that is crazy fast. I mean really... 4GB ram too I see as the norm. > > which is good. > > > > on a different note though, perchance will the fourth or fifth series > > of libre cards support 8gb of ram or more? > > > > I bet you could even get it to 16gb if you wanted... though that > > wouldn't be needed. heh. > > the cost of the RAM ICs to do that are insane. the 1GB DDR3x16 ICs > are already $10 **EACH**. > > normally a DIMM would have 8 or 16 RAM ICs, meaning that for a 4GB > DIMM you need 8x 512mb ICs, or you could do 8GB by using 16 of them. But that would mean that an 8GiB stick for a desktop would cost $80 just for the ICs. I can find 8GiB of RAM for $60 and cheaper, I bet, if I poked my nose around. Or maybe desktops don't need ICs??? > normally you get 2 (matched) DIMMS totalling 8GB. > > if you want *32* GB you get 2 matched DIMMs, but nobody in > "mass-production" is shipping windows PCs or laptops with 32GB of RAM > (and if they are it's DDR4) You write that as though being dismissive of DDR4. Why is DDR4 currently unacceptable for one of your designs? > additionally, it would need either 2 pairs of x32 DDR RAM > controllers, or it would be necessary to do a cascade layout: a > daisy-chain of RAM ICs.... and i'm not sure it would be possible to > fit 8 RAM ICs onto the 43x78mm PCB anyway. > > bottom line it's far too expensive and quite impractical. 4GB is the > practical limit at the moment and even that's stupidly expensive > relatively speaking. > > l. Well, I bought a 4GiB RK3399 SOC card fro firefly for $200. Don't get me wrong, I love your effort, but I need RAM, CPU power, lots of ports, and more screen landscape. Hmm, maybe you should invent an OpenSource IC? Sincerely, David

2 1

Re: [Arm-netbook] libre 64-bit risc-v SoC
by David Niklas 08 May '17

08 May '17

I apologize for DOS'ing the list, I can only get online about once a week. On Fri, 28 Apr 2017 12:35:19 +0200 "mike.valk(a)gmail.com" <mike.valk(a)gmail.com> wrote: > > 2017-04-27 13:21 GMT+02:00 Luke Kenneth Casson Leighton >> <lkcl(a)lkcl.net>: > > > ok so it would seem that the huge amount of work going into RISC-V > > means that it's on track to becoming a steamroller that will squash > > proprietary SoCs, so i'm quite happy to make sure that it's > > not-so-subtly nudged in the right direction. > > > > i've started a page where i am keeping notes: > > http://rhombus-tech.net/riscv/libre_riscv/ and the general goal is to > > create a desirable mass-volume low-cost SoC, meaning that it will need > > to at least do 1080p60 video decode and have 3D graphics capability. > > oh... and be entirely libre. > > > > the plan is: > > > > * to create an absolute basic SoC, starting from lowRISC (64-bit), > > ORGFX (3D graphics) and MIAOW (OpenCL engine), in at least 90nm as a > > low-cost proof-of-concept where mistakes can be iterated through > > * provide the end-result to software developers so that they can have > > actual real silicon to work with > > * begin a first crowd-funding phase to create a 28nm (or better) > > multi-core SMP SoC Links? > > for this first phase the interfaces that i've tracked down so far are > > almost entirely from opencores.org, meaning that there really should > > be absolutely no need to license any costly hard macros. that > > *includes* a DDR3 controller (but does not include a DDR3 PHY, which > > will need to be designed): > > > > * DDR3 controller (not including PHY) > > * lowRISC contains "minion cores" so can be soft-programmed to do any > > GPIO > > * boot and debug through ZipCPU's UART (use an existing EC's on-board > > FLASH) > > > > Perhaps put it sirectly to an USB bridge. UART's on debugging hardware > is non existant. We all use FTDI dongles. > > Look like OpenCores has a module. https://opencores.org/project,usb2uart > > > > > * OpenCores VGA controller (actually it's an LCD RGB/TTL controller) > > * OpenCores ULPI USB 2.0 controller > > * OpenCores USB-OTG 1.1 PHY > > > > note that there are NO ANALOG INTERFACES in that. this is *really* > > important to avoid, because mixed analog and digital is incredibly > > hard to get right. also note that things like HDMI, SATA, and even > > ethernet are quite deliberately NOT on the list. Ethernet RMII (which > > is digital) could be implemented in software using a minion core. the > > advantage of using the opencores VGA (actually LCD) controller is: i > > already have the full source for a *complete* linux driver. Considering that analog was around *long* before digital I'm surprised that it is "Hard to get right", is there a reason for this? Isn't there a chip for just this kind of thing? > > I2C, SPI, SD/MMC, UART, EINT and GPIO - all of these can be > > software-programmed as bit-banging in the minion cores. > > > > these interfaces, amazingly, are enough to do an SoC that, if put into > > 40nm, would easily compete with some of TI's offerings, as well as the > > Allwinner R8 (aka A13). > > > > i've also managed to get alliance and coriolis2 compiled on > > debian/testing (took a while) so it *might* not be necessary even to Hmm, I can't seem to google that piece of SW. Do you have a link? > > pay for the ASIC design tooling (the cost of which is insane). > > coriolis2 includes a reasonable auto-router. i still have yet to go > > through the tutorials to see how it works. for design rules: 90nm > > design rules (stacks etc.) are actually publicly available, which > > would potentially mean that a clock rate of at least 300mhz would be > > achievable: interestingly 800mhz DDR3 RAM from 2012 used 90nm > > geometry. 65 down to 40nm would be much more preferable but may be > > hard to get. How would you get it in the first place? Is there a company dedicated to larger than industry standard (nm) silicon production for small businesses, or are you planning to buy a ... what would it be called? ... printed wafer producer? > > graphics: i'm going through the list of people who have done GPUs (or > > parts of one). MIAOW, Nyuzi, ORGFX. the gplgpu isn't gpl. it's been > > modified to "the text of the GPL license plus an additional clause > > which is that if you want to use this for commercial purposes then... > > you can't". which is *NOT* a GPL license, it's a proprietary > > commercial license! > > > > MIAOW is just an OpenCL engine but a stonking good one that's > > compatible with AMD's software. nyuzi is an experimental GPU where i > > hope its developer believes in its potential. ORGFX i am currently > > evaluating but it looks pretty damn good, and i think it is slightly > > underestimated. i could really use some help evaluating it properly. > > my feeling is that a combination of MIAOW to handle shading and ORGFX > > for the rendering would be a really powerful combination. <snip> What about Vulkan? I'm asking, because it is multithreaded, as opposed to OpenGL. I've also heard, though perhaps the person was wrong, that it is supposed to replace OpenCL.

2 1

Re: [Arm-netbook] libre 64-bit risc-v SoC
by doark＠mail.com 07 May '17

07 May '17

I apologize for DOS'ing the list, I can only get online about once a week. On Fri, 28 Apr 2017 19:54:43 +0200 Hannes Schnaitter <hannes(a)schnaitter.de> wrote: > Hi, > > I've done some research into this in the last couple of weeks. > > Am Fri, 28 Apr 2017 20:21:00 +0300 > schrieb Bill Kontos <vkontogpls(a)gmail.com>: > <snip> > I'm sad to say that it isn't even close to solved. The only two > concrete ideas I found are: > 1. Egoism. The driver of the car always wins. > 2. Utilitarianism. "The Greater Good". The best outcome for the most > people. > > There is also another one which ignores most of the problem. > 3. Random. Creating different possible crash cenarios and selecting one > at random. > <snip> > > Then there is the problem of who would by utilitarian cars. [2] > > Greetings > Hannes I would. It's what I'd do in real life. I've had similar choices before. I have no regrets about placing my own life on the line either. Sincerely, David

1 0

firefly 3399 all source software disclosed?
by ronwirring＠Safe-mail.net 07 May '17

07 May '17

https://www.kickstarter.com/projects/1771382379/firefly-rk3399-six-core-64-… Has all source code for the computer been disclosed? Lkcl has says, he can make use of the rk3399 if he has the processor's data sheet. https://www.kickstarter.com/projects/1771382379/firefly-rk3399-six-core-64-… What data about the rk3399 does lkcl not have? What is the performance of the rk3399 processor compared to a x86 dual core 2ghz?

3 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook May 2017