Re: [fedora-arm] EOMA68-A20 CPU Card and Improv Engineering Board available for sale
> On Tue, Nov 26, 2013 at 9:38 AM, Richard W.M. Jones wrote: >> I think this project could do with some sort of "what on earth is >> this?" introduction for people who know absolutely nothing about what >> you're trying to do. http://hardware.slashdot.org/comments.pl?sid=4485207&cid=45523195 http://hardware.slashdot.org/comments.pl?sid=4485207&cid=45525715 does that help? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedzaxy-natqqjnqc_i-zfxsbdtg7-zahnrzevrn2c5f...@mail.gmail.com
Re: [fedora-arm] EOMA68-A20 CPU Card and Improv Engineering Board available for sale
On Tue, Nov 26, 2013 at 9:38 AM, Richard W.M. Jones wrote: > On Tue, Nov 26, 2013 at 09:18:16AM +0000, luke.leighton wrote: >> On Tue, Nov 26, 2013 at 9:10 AM, Richard W.M. Jones >> wrote: >> > On Mon, Nov 25, 2013 at 09:23:30PM +, luke.leighton wrote: >> >> hoooray, hooray, finally we're on to a non-CE/non-FCC beta run. $75 >> >> plus tax & shipping via our 3rd party partners. specs at the link >> >> below. anyone on debian-arm or fedora-arm who would like to order one >> >> and would like a preorder code so as to be able to jump the first-come >> >> first-served queue (i have a few available) please contact me directly >> >> for instructions ok? >> >> >> >> http://eoma68-a20.qimod.com/improv.html >> > >> > I have to admit this website and the ones linked from it leave me >> > more confused than when I started. >> >> awesome! there's a lot of history behind this project - it's been in >> development for over 2 years. >> >> > Is this a PCMCIA card? >> >> no. >> >> > That sounds like an interesting form factor, >> > but in that case how does the serial console work? >> >> http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 > > So it's a PCMCIA form factor that fits into some sort of backplane? reuse of legacy PCMCIA housings sockets connectors and assemblies to create a mass-volume modular upgradeable environmentally-conscious computing "appliance" eco-system that happens to also invite free software developers to participate in it from day 1. > I think this project could do with some sort of "what on earth is > this?" introduction for people who know absolutely nothing about what > you're trying to do. create a mass-volume modular etc. etc. where software libre developers are invited to participate at every step of the way. front page of http://rhombus-tech.net. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDwoi6eYZy2nWHxxyxhHNGUwNppCXL+rPOkdt=cwfcc...@mail.gmail.com
Re: [fedora-arm] EOMA68-A20 CPU Card and Improv Engineering Board available for sale
On Tue, Nov 26, 2013 at 9:10 AM, Richard W.M. Jones wrote: > On Mon, Nov 25, 2013 at 09:23:30PM +0000, luke.leighton wrote: >> hoooray, hooray, finally we're on to a non-CE/non-FCC beta run. $75 >> plus tax & shipping via our 3rd party partners. specs at the link >> below. anyone on debian-arm or fedora-arm who would like to order one >> and would like a preorder code so as to be able to jump the first-come >> first-served queue (i have a few available) please contact me directly >> for instructions ok? >> >> http://eoma68-a20.qimod.com/improv.html > > I have to admit this website and the ones linked from it leave me > more confused than when I started. awesome! there's a lot of history behind this project - it's been in development for over 2 years. > Is this a PCMCIA card? no. > That sounds like an interesting form factor, > but in that case how does the serial console work? http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 > Assuming it's a development board, not a PCMCIA card: good call. > - Why not give it more RAM? because when we put out a call for funding nobody answered. as i am not a PCB design expert we had to go with what was practical and available, and that meant going with a reference design. that reference design, at the time, nobody had ever tried 2gbyte of RAM, it was with an A10 not an A20, and we were not about to risk what money *was* available on the offchance that 2gb of RAM *might* work. later we will do a 2gb version with a 1gbit ETH PHY. but for that to happen we will need sales of _this_ card first. you can always upgrade, and either reuse the old one in other products or sell it on ebay. > The A20 can address up to 2GB which >I consider to be an absolute minimum for serious work. then i recommend you get a cubieboard2. same CPU, same features, roughly same size. > - Why not include a CP2102-type UART-USB chip so you can just plug it >directly into USB to get a serial console. IMHO serial ports are >requirements for development boards, not something that everyone >should be forced to buy separately. that is a decision that is made by I/O Board designers. if you would like a CP2102-type UART-USB chip on-board then you can, in this particular case, download the schematics and PCB design files which will be released under the GPL and you can make the necessary modifications yourself, then either submit them back to the designers or you can sell the boards yourself. > - Precisely what patches are required to get the upstream kernel to work? see http://linux-sunxi.org/Linux_mainlining_effort > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedzfh8avdl+59xgzsafnkxzcgm86cbzts+ahdao-jfd...@mail.gmail.com
EOMA68-A20 CPU Card and Improv Engineering Board available for sale
hoooray, hooray, finally we're on to a non-CE/non-FCC beta run. $75 plus tax & shipping via our 3rd party partners. specs at the link below. anyone on debian-arm or fedora-arm who would like to order one and would like a preorder code so as to be able to jump the first-come first-served queue (i have a few available) please contact me directly for instructions ok? http://eoma68-a20.qimod.com/improv.html -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedyhjb4jucgfqrtpuoioh11elqmmwuv9zei0fm7cjrs...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sun, Jun 9, 2013 at 11:31 PM, Russell King - ARM Linux wrote: > On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote: >> this is all a rather round-about way to say that for those people who >> heard and are thinking of heeding russell's call to "be silent and to >> ignore me" > > Okay, so you've just misrepresented me in the above comment. I never > said anything of the sort. The closest that I've come to a comment like > that is asking you to stop wasting people's time. close enough. > So, given your displayed inability to properly convey what people have > said to you in a discussion in your own replies, is there *any* reason > that anyone should trust you to communicate their position to any other > third party? trust is always something that has to be given, russell. respect is earned, but trust is given. many make the mistake of believing that trust is earned [people who seek to defeat others as "enemies" know this and exploit it to devastating effect]. so i can't answer your question directly, but consider this: the people that i work with have known me for a long time. they know i'm a bit of a live wire (you saw that wookey called me "crazy luke") and they often go as completely spare at some of the spanners i throw in the works just as everyone else does. it's *they* who will be doing all the talking, and i will be advising them in the background over the next week so that *technically* they're prepped. everyone has a different role to play here. /peace l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedx2m800s+ptmd3vmmkv1odz0sojp-ydvjnrny5j7oc...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ok, so the deadline's almost up but the discussions of the past two or so days have basically i think everything that needs to be said, and i'm extremely grateful to everyone who's contributed, privately and publicly, especially on such short notice. i've passed it over to my associates who will turn it into executive-level-speak: they understand that the situation is sensitive and have far more sense than i, which is good. i'm not sure if i should admit this, but there's some irony here that needs to be shared. i passed the collation of input from people - most of it verbatim - over to my associate who is used to dealing with executive-level people, and he said it couldn't possibly go as-is to them, not even to their assistant. when i asked why he said it was because it sounded too much like ordering them what decisions to make. if you've been following the shit-storm criticism that's been directed at me, and you've also noticed the bit about "most of it being verbatim" you have to appreciate the irony, really. so *sigh* we have to trust my associates and their experience in dealing with executives to work out a way to get the message across: i understand the things about public communication on-list(s) being important and so on and will fight to make sure those are got across in some clear form. the good news is that they *have* asked for advice and for a report, so there *is* an opening, it's not an unwelcome cold-call that we're engaging in, here. the last thing i'd like to say is this: free (libre) software developers and advocates are in an extremely... odd position of not really being fully or adequately monetarily compensated for the true level of service that they truly provide. i mention "service" because regardless of whether it's business or whether it's spare-time work just for the heck of it, we *are* acting as servants to a great many people, and in many cases those people who directly receive the benefit of our work - millions if not hundreds of people now that the linux kernel has made its way into android - have absolutely no way of being able to identify us and pay us for that service. i've never thought about giving up, but i *have* been thinking "what the hell am i doing wrong i.e. why have i only received direct donations of about $300 in *total* for all work done for the free software community since 1995 including samba and exchange 5.5 reverse-engineering and much more", up until recently when i learned some new insights that i thought it important to share, here. the insight is this: that there is a separate tally which is inviolate that keeps a *true* account of the level of service that we *truly* provide to others, of which monetary compensation is only a partial reflection [subtracted from that inviolate account, in some cases resulting in a DEBT in the inviolate and true account - which will need to be repaid - if the monetary compensation was too high or the service provided too poor]. so, for anyone reading this who has seen the shit-storm of the past few days and felt either embarrassed, or for any other reason has felt that they should quit working with free software, please don't: remember that the work itself is not necessarily the reward (although that's important too), nor that you're providing service to others and that that itself should be the reward, but that you *will* or *are* receiving true and accurate compensation: believe it, because it's true. this is all a rather round-about way to say that for those people who heard and are thinking of heeding russell's call to "be silent and to ignore me", to do so would be a significant dis-service both to yourself and to the hundreds of millions of end-users whom you are serving, if the long-term and immediate-term projects that i have embarked on are the success that i envision them to be. even with that having been said, it is, indeed, entirely your choice, that nobody but you should make. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDw0U-djVaVzWoNnvhWvwOP=LXc=ac97zztyb6akf+j...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sat, Jun 8, 2013 at 9:28 AM, Tomasz Figa wrote: > Now that the discussion went off from "you stupid kernel developers *lol*. i get that summary ["you said people were stupid!!!"] a lot. i don't quite understand where it comes from, otherwise i would stop doing it :) > adopted DeviceTree without even asking a closed company about their > proprietary solution, which does the same" to something a bit more > constructive, let me point some of the benefits. > [snip...] ahh, magic. these have gone straight into that proposal. i think the best ones - the gems - are the test-coverage and formally allowing public interaction. the test coverage because it will reduce the risk of errors in the silicon [you never know when developing both hardware and software where the bug might be] as well as reduce the development time and development costs. the public interaction (which i was going to ask thomas and maxime about, this morning) because it means a much faster feedback loop. i've been trying to think of ways to link "if you do X it will result in more sales and reduce risk" to the discussion, and i think you finally hit it tomasz, so thank you. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedwon7x-frqurvkdnxu3ncyogrezy9v5q8zxvoe6kwk...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sat, Jun 8, 2013 at 12:09 AM, Dennis Lan (dlan) wrote: > > > On Saturday, June 8, 2013, luke.leighton wrote: >> >> right - too many people contributed to this, input from jon smirl, >> wookie, maxime, tomasz, henrik, i've made a start here and will >> continue editing: this is notes for me to put forward an agenda for >> discussion: >> >> http://hands.com/~lkcl/allwinner_linux_proposal.txt >> >> i'm setting a rule that each section *has* to have a list of clear >> benefits, otherwise it'll have to be removed before it goes on to >> their Directors. >> >> so - even if there are any allwinner engineers reading this who would >> like something put forward please also speak up! :) >> >> l. >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > Hi luke > I'm not a allwinner employer :-)$. but pretty much in the same position > as they are. thanks for chipping in. > I'd like to add a few comments about the risk of adopting the device > tree(from allwinner side) > 1) current using fdt in bootloader(uboot) is not mature, I'm not saying > about passing the fdt data to kernel. fdt. could you provide some context here? what is it? (apart from being a TLA) > But the bootloader itself need information from device tree, say boot0/1 > phase (boot device type, DDR initialization...) > since fdt is not ready, and SRAM space is very limited ... I'm afraid > 'fex' may co-exist with device tree. > still, they receive benefits if they can adopt device tree, at least > minimal the kernel side migration effort > Generally this info already been pointed out by steppen warren in previous > email... ... which i have to admit i may have missed the significance of or possibly just missed it entirely. what's the main concern you have, here; what's the potential solution, and what's the benefit of that potential solution, to allwinner [direct or indirect]? > 2) device tree may not been understood by third vendors (who previus produce > shoes or ? :-$), :) > they are real old 'Fex' scheme user, they like edit the data in windows > with dos format > So, how to fill this gaps, make them happy? Creat another tool to handle > device tree modification? > Then it's another price they have to pay... yehh... that kinda looks unavoidable, although it would ultimately only inconvenience the developers of the proprietary firmware-flashing tools [livesuite, phoenix] and so would be transparent to the factories and so on. i've mentioned the idea of having an in-kernel translation tool rather than an external (pre-runtime) one, i've yet to get some feedback on that. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDyv=uN8_Ts4miXCGsCrNwYkovLpF_PYF7D1=n2_azh...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 11:08 PM, Maxime Ripard wrote: > On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote: >> maxime: we need to talk :) >> >> please tell me in 4 or 5 sentences what you've managed to do so far, >> expanding a little on what thomas says below, more specifically what >> it achieves and/or allows rather than technically what it does >> (suitable for managers and directors in other words), and what plans >> you'd like to see happen. > > You mean something like http://linux-sunxi.org/Linux_mainlining_effort ? ahh, fantastic. with references too. magic. exactly what i need. thank you. listed now at http://hands.com/~lkcl/allwinner_linux_proposal.txt > You should really do a bit of research before starting a thread like > this one. then that gives you some idea of how busy i've been and still am, to not be aware even of things like this, to have kicked a project off some 18-24 months ago and not be able to keep up with one of the many branches and initiatives that it's spawned. when i said i've been caught off-guard by this opportunity i meant exactly what i said. > This webpage has been around for like 9 monthes now on the wiki > of a community you pretend to represent i pretend no such thing and apologise for giving any impression of such. > (even though I fail to get how > you can pretend such thing, but that's another topic). i have a different focus: a meta-project of sorts, where allwinner happened to be the first. look up rhombus-tech and EOMA68 and it'll become a bit clearer. >> > is the maintainer of the mainline Allwinner sunxi >> > effort. It already supports a number of boards, has a pinctrl driver, a >> > GPIO driver, serial port is working, network is working, I2C is >> > working. >> > >> > All in mainline, completely Device Tree based. >> >> great. which version did it first hit, i.e. what will the first >> signs of this be when allwinner begin doing "git pulls"? > > 3.8, as shown in the wiki page got that. >> and which boards. bear in mind that one of those "boards" should >> really be "the total range of products available across hundreds of >> chinese tablet clone manufacturers". >> >> specific question: is one of the "boards" the one that tom cubie >> submitted, which covers virtually every android tablet product >> manufactured in the millions by chinese tablet clone manufacturers? > > Again, wiki. yep, am there now. >> > So isn't this entire discussion completely moot? >> >> no because it's totally in isolation from allwinner. i need to give >> them a heads-up, and get them involved, giving them specific >> incentives [which nobody's yet given!!] for following a particular >> path [or paths] yet to be recommended. >> >> > The mainline support >> > for sunxi has already started since 6 months or so, and has been Device >> > Tree based from day one. >> >> to clarify: the *community-driven* mainline support for sunxi. ok - >> which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i >> (Dual-Core Cortex A7)? which ones are in? > > A10, A13 for the moment. I just received hardware with A10s, A20 and A31 > that I need to work on, but support should come quite soon. superb. question: what help or other resources could you do with? what additional information? > I already > have some patches pending to be tested on an A31 board, but didn't have > as much time as I wanted lately to actually set a proper environment to > test them. ok - good to know. btw when you get to it please note a bug found in the "vanilla" [allwinner-released] A20 3.3 tree where they reduced a 128 byte buffer to 78 bytes for spurious reasons; the critical fix is at line 989, of the following patch: http://git.rhombus-tech.net/?p=linux.git;a=commitdiff;h=refs/heads/lkcl-3.3-a20;hp=6c5753e5dc1fafff288d522c94b40a7dd2a81adc i found this by running a diff -u of sun4i_usb from the 3.4 sunxi community tree against the sun7i_usb tree from the allwinner 3.3 release. amongst the desperate attempts to disable DMA (probably due to stack corruption of the above bug) and various renaming attempts of *SUN4I* to *SUN7I*, that one stuck out like a sore thumb. the other bits - which may or may not be relevant - are the spinlock protection and the call to sw_udc_enable which is present in the sun4i_usb 3.4 code but not the A20 3.3 code. mileage may vary, and the buffer overrun only happens if you enable the OTG interface as "dual" (auto-detect) because that's enough features in the bitfield to cause there to be enough strcpy's... oops :) l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedwfhy_abbxjspm7bvfdfhsxl5h594cfn4zvc6qfpu4...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 8:30 PM, Russell King - ARM Linux wrote: > On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote: >> well, tough. get me up to speed, *fast*. > > No, not unless you're willing to *pay* someone to spend time teaching you, there's not enough time. 2 days left. > because you are asking to be *taught* about the current situation, so > you're asking someone to do some _work_ _for_ . for the benefit of free software, russell. for the benefit of free software. for the BENEFIT of free software. > _you_. NO. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedxmtnpfbapiacpig0g3zhvmwljpopdz6tbd-fn5hkd...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni wrote: > Maxime will reply to this in more details, but I believe the status is: > > * Interrupt controller is working. > * Clock drivers are working. > * Pinctrl is working. > * GPIO is working. > * Timer is working. > * UART is working > * Watchdog is on its way (patches posted) > * Ethernet is on its way (patches posted) > * I2C is on its way (patches posted) ok so i've got this now in http://hands.com/~lkcl/allwinner_linux_proposal.txt - that leaves... well there's quite a bit: usb, sd/mmc (both variants: they changed the data structures around sun5i), nand (probably both - the allwinner one and the mtd one being done, reminds me: we need full documentation on the NAND chip), scsi, g2d - cedarx and more. what else should be raised, and to what benefit? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedxtc+oamcpveq3bulbn88hsjzkoi0fknlbadzd04lq...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
right - too many people contributed to this, input from jon smirl, wookie, maxime, tomasz, henrik, i've made a start here and will continue editing: this is notes for me to put forward an agenda for discussion: http://hands.com/~lkcl/allwinner_linux_proposal.txt i'm setting a rule that each section *has* to have a list of clear benefits, otherwise it'll have to be removed before it goes on to their Directors. so - even if there are any allwinner engineers reading this who would like something put forward please also speak up! :) l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedxg4zpidvhten+pegbsfmzpkqj-iy3x0vbgj7ib7pt...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni
wrote:
> Hello,
>
> On Fri, 7 Jun 2013 19:26:49 +0100, luke.leighton wrote:
>
>> > Have you noticed that it is already the case in mainline?
>>
>> i knew there was a little bit, but not the extent of the commits.
>
> Then you could probably use a bit of your time to read the kernel
> commit logs rather than writing hundreds of e-mails, no?
not now, thomas. i need summaries. bear in mind i type faster than
i can read/find. very very grateful for your summaries, it's exactly
what i need.
>> > My colleague Maxime Ripard (Cc'ed)
>>
>> maxime: we need to talk :)
>>
>> please tell me in 4 or 5 sentences what you've managed to do so far,
>> expanding a little on what thomas says below, more specifically what
>> it achieves and/or allows rather than technically what it does
>> (suitable for managers and directors in other words), and what plans
>> you'd like to see happen.
>
> Maxime will reply to this in more details, but I believe the status is:
>
> * Interrupt controller is working.
> * Clock drivers are working.
> * Pinctrl is working.
> * GPIO is working.
> * Timer is working.
> * UART is working
> * Watchdog is on its way (patches posted)
> * Ethernet is on its way (patches posted)
> * I2C is on its way (patches posted)
>
> Cubieboard (A10), Hackberry (A10), Mini XPlus (A10) And OLinuxino (A13)
> are supported.
>
> See arch/arm/boot/dts/sun{4,5}i* for a good overview.
>
>> > All in mainline, completely Device Tree based.
>>
>> great. which version did it first hit, i.e. what will the first
>> signs of this be when allwinner begin doing "git pulls"?
>
> The very first support landed in 3.8.
>
>> > So isn't this entire discussion completely moot?
>>
>> no because it's totally in isolation from allwinner. i need to give
>> them a heads-up, and get them involved, giving them specific
>> incentives [which nobody's yet given!!] for following a particular
>> path [or paths] yet to be recommended.
>
> You really believe you're more important than you really are, I'd say.
no, i don't. i'm just a messenger. under-informed one, at the
moment. please bear that in mind rather than saying "you seem
dreadfully underinformed" - i got caught off-guard by this opportunity
and need to get up-to-speed rather fast.
> My colleague Maxime is in contact with Allwinner, he has regular
> discussion with them, started reviewing some of the kernel code they're
> writing, has received datasheets from them, and evaluation boards.
_great_. that's brilliant to hear.
> So this work is definitely not done in isolation from Allwinner, and
> they have received much more than an heads-up from Maxime.
>
>> > The mainline support
>> > for sunxi has already started since 6 months or so, and has been Device
>> > Tree based from day one.
>>
>> to clarify: the *community-driven* mainline support for sunxi. ok -
>> which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i
>> (Dual-Core Cortex A7)? which ones are in?
>
> So far, A10 and A13. Maxime has received a A31 evaluation board from
> Allwinner very recently, and also A10S and A20 boards. I suppose he
> will be working on those fairly and posting the corresponding patches
> fairly soon.
great. you've got the A20 3.3 kernel source drop?
http://git.rhombus-tech.net/?p=linux.git;a=tree;h=refs/heads/lkcl-3.3-a20;hb=refs/heads/lkcl-3.3-a20
> In other words, it looks like you've started an entire discussion about
> the mainline support for Allwinner SoCs without having a look at what
> "git log" tells you...
absolutely correct. dived into this the moment i got word of a
potential meeting on extremely short notice, having had zero time to
review the logs prior even to then.
> Which by itself is a very good indicator that
> you're probably not the best interlocutor for Allwinner as far as
> mainline development is concerned.
the meeting's going ahead, regardless of your concerns. please help
get me up to speed, for the benefit of the linux community. take
advantage of the opportunity, please: take it at face value without
judgement.
l.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAPweEDzaWBYEOpDNCkxGyHzewTAVgD6v=jjm-t46uw_jypb...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 7:57 PM, Wookey wrote: > OK, this sounds good. Could you say who the allwinner engineers are? [cross-over: i asked him if he'd be happy to let me know privately, so i have at least some context when speaking to the Directors] > I > guess it's quite a large organisation, so if Crazy Luke can say 'the > work of mainline integration using device-tree is already being done > by $these $people, please talk to them to help move it along', that > might help get everyone on the same page. *mull*, *mull*... yes exactly! > If it's like many large organisations, some bits of it will 'get it' > and see why, in the long term, mainline integration is worthwhile, but > other bits will look at what they have now and their android focus, > and decide it's easier to keep doing what they are doing. > > There is a lot of hardware using these socs, and I'd love to be able > to use that with mainstream stuff, rather than random vendor piles, > and specific android kernels, so anything we can do to help make that > happen is good. > >> So yes, Allwinner has an evil vendor tree (c), with a solution similar yet >> inferior (because not generic enough) to the device tree, but they show >> interest on going down the mainline road. > > So, luke: mainline is not going to support fex directly, whatever you > or allwinner do. The advantages to allwinner of working with mainline > are: > 1) Ability to use whatever (kernel supported) hardware they like with > new designs, with no driver work > 2) Ability to use latest kernels and thus whatever shiny goodies those > include > 3) No need to do fex-ready drivers for new hardware > 4) No need to keep backporting new kernels to add fex integration > forevermore hooray - thank you wookey, this is exactly what i need. cut/paste, straight into the report. > If they want to keep existing tools and fex workflow then a fex<->DT > translation tool will be needed. in-kernel or external tool? > (It's not clear to me to what degree > DT can simply be used instead directly) TBD. input here, anyone? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDw3_M_5e_B2HueCNcfXjO9_4_oiCJuEfTERetyoOx=+v...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson wrote: > Luke, > > I want only one thing from you at this time. See below. > > > On Fri, Jun 7, 2013 at 11:45 AM, luke.leighton > wrote: >> but the Directors of Allwinner aren't been kept in the loop, >> here: that's my job, to get them up-to-speed. > > The one job I would love for you to do instead of all this trolling > and time-wasting that's being done by _everybody_ involved, is to just > extract yourself from the situation and let us go on with our work. > You're causing nothing but confusion and extra work. Literally. You > represent nobody that matters in this discussion. absolutely correct. i am nobody, who is in the right place at the right time. i'm just a messenger. so - what message do you wish to take to the Directors of Allwinner (if any). > By demanding a-a-ah, no demands made. > us to spend time and effort bringing you personally up to > speed on a subject that both we (ARM kernel community) and them > (Allwinner) are already having discussions about, it's nothing but a > distraction and waste of energy. > > And yes, Allwinner knows about this public email thread that's good! -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzeyJh+DKX=8tzrt9ang9nqlp8nwkwfmb2wy+jnbkq...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 9:57 AM, Tomasz Figa wrote: >Seeing from your posts you don't have any knowledge on how Linux kernel > development works check back to 2004. > and even on how Allwinner's cooperation with our > community looks (and seem to be completely closed to our effort of showing > you the reality), no - just f*g busy, tomasz > so I'm not sure if you are the right person to take any > of those roles... well, tough. get me up to speed, *fast*. please stop wasting time like this: get me up to speed. i may not be the best person but i am in the right place at the right time, and nobody else is going to be able to step into this role in time. so i may not be the best person that you *think* i am, but i'm the person you've got. time's ticking. can we get on please? > I'd suggest Maxime Ripard or someone else from Free Electrons to be > responsible for communication with Allwinner instead. you're welcome to suggest, however they do not have the contacts that i have (many of which are indirect anyway), and i am not going to introduce him to them either, in case they jeapordise the critical business relationships that took my associates 4 years to establish. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDwmgr2JbH+txDDjR_gDA2R2C1v=auvcuvts7rrimhz...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 9:22 PM, Arnd Bergmann wrote: > On Thursday 06 June 2013, Maxime Ripard wrote: >> So yes, Allwinner has an evil vendor tree (c), with a solution similar yet >> inferior (because not generic enough) to the device tree, but they show >> interest on going down the mainline road. > > Right, and of course there is nothing special about that, everybody starts > out with they own even vendor tree (c), and as hardware support gets merged > upstream, the diff gets smaller, even though the code in the mainline > kernel is normally very different from what they started out with. *sigh* except if that idiot manager [whom we're keenly aware of] orders them to delete absolutely everything (find . -name '*sunxi*' | xargs git rm) and overwrite it with their internally-managed tree, causing absolute mayhem in the process... > Chances are actually that the Allwinner (A10/A13/A20, not A31) platform may > end up being the first modern one that is fully supported upstream including > a GPU driver, since it is one of the obvious targets for the > reverse-engineering efforts. yes. http://libv.livejournal.com/24735.html > Ironically (given NVIDIA's reputation), the > Tegra platform is the strongest competitor I see in that race at the moment. at $7.50 for a dual-core processor, and i am *not* going to tell you the quad-core price, i don't believe it can be considered to be a race, or even a competition. they're *OUT*, man. really. oh wait - did you mean for "1st to have fully supported upstream GPU driver"? that would be veery nice. > For all I can tell, things are progressing nicely, given that it's currently > a volunteer effort. If anyone needs things to move faster, I'd recommend > them to send money to free-electrons.com. i'll put that on the list of recommendations, but - again - i need a list of clear benefits and returns as to why that should happen. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDyfrA9z55Yqt8jC8j=e=g_gah_fa0xrolxexajwqxn...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 6:28 PM, Maxime Ripard wrote: > I should also add that Allwinner not only talked to us already, oo! great! can you please [privately, not publicly] let me know who that is, so i can let the Directors know, so that they can follow up? > but also > expressed interest in doing actual modern kernel development (like using > "recently" introduced kernel frameworks, like the clk framework). awesome. > I've received patches from them already for private reviews, they began > to show up on the kernel mailing lists, they asked to be CCed on the > patches I send upstream, they're even the one that reached out to me > when the early support for their chips was released. So, like Olof said, > they aren't in a vacuum, they are very aware of the mainline kernel and > speak a decent english. good! next thing you know they'll be writing comments in english too [*1] > So yes, Allwinner has an evil vendor tree (c), with a solution similar yet > inferior (because not generic enough) to the device tree, but they show > interest on going down the mainline road. yes. i'm coming at this from the other end, via the top management, so that this is properly coordinated. so. reminder. and question. what needs to be done, and what are the benefits? l. [*1] http://git.rhombus-tech.net/?p=linux.git;a=blob;f=drivers/usb/sun7i_usb/manager/usb_manager.c;h=3775c83134efee9694789b68e85010ebc0d9938b;hb=refs/heads/lkcl-3.3-a20#l274 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDyg11k++gunqVQkbwi_-MvhexAX6Z_kjM=3rfbi7qn...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 5:00 PM, Olof Johansson wrote: > On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com wrote: >> On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton >> wrote: >>> augh. ok. solutions. what are the solutions here? >> >> Luke if you really want to fix this a good solution is to have >> Allwinner join Linaro and provide an engineer to the Linaro effort. >> That engineer will get educated on the right way to do kernel >> development and he can pass that knowledge back to Allwinner each day >> as he learns it. > > There's no need for anybody to join Linaro to contribute upstream. > That's a crazy notion. indeed. this is a company that produced a 70-page "datasheet" when freescale produced 4,500 for the iMX6. i passed on that link and i believe it'll be an eye-opener to their engineers: education is what's key here, and you don't need to pay vast sums to do it. although the quantities they're selling are just ennorrrmous, allowing them to undercut absolutely everybody because they can pay absolute best rates to the Fab Houses (TSMC etc.) their profit margins are going to be exceptionally slim. so we cannot count on them having a spare $1m per year to give to linaro, so yes, i tend to agree with what you're implying, olof, that allwinner should be encouraged to participate more in upstream contribution. so. could someone please describe to me what they should do, here? whom should they best contact, what lists, what's the procedures, where's the best-working-practices, where are the foundations with which they can participate that have the formal procedures for proposals [similar to python's PEP and debian's DEP]. that last was a not-very-subtle hint, btw. and... please... i've yet to receive *any* answers to the question "and what are the benefits that they would get by doing so"!! > Listen, Allwinner isn't working in a vacuum, believe it or not. I've > talked to them, so has Arnd and other people working on ARM, including > Maxime Ripard, who's been reimplementing upstream support for their > platform. great. > Everybody is interested in the right things happening, it's > just a matter of figuring out how to do it. The right people are > already talking. but the Directors of Allwinner aren't been kept in the loop, here: that's my job, to get them up-to-speed. >> the cost of joining. The net result will likely be a reduction in the >> amount they need to spend on in-house development since they will >> learn how to better leverage other developer's work. but you forget one thing: they only need *ever* produce *one* board/kernel. they have a registered board type, it covers *all* products and i mean *all* products. i don't mean that in the "usual" way where most companies re-use a single machine type for multiple devices and irritate the crap out of linux kernel developers when the GPL source finally "leaks", i mean "thanks to script.fex they LITERALLY only ever compile one binary and then customise script.fex on a per-customer basis". so the usual lessons really do not apply, here. the only one i spotted was that they rather foolishly made duplicates of sun5i_usb and renamed all the files (s/SUN5I/SUN7I/g) to make sun7i_usb, then started editing. one of the developers created a buffer overflow, which corrupted internal memory, and there are signs that he then started experimenting switching off DMA trying to fix various problems. if he'd done a proper job #ifdef CONFIG_SUN7I_USB #ifdef CONFIG_SUN5I_USB in the same source code etc etc. and tested on known-good [older] hardware he would have noticed that the modifications failed on previously-known-good hardware and would have spotted the buffer overflow error much sooner. that _is_ something i will be bringing to the Director's attention, that the "strategy" of cut-paste-itis has detrimental effects. ok. so. apologies, bit of a digression there. question for you olof [and others of course]: you've clearly listed some benefits, which i'm very very grateful for. in light of what i describe above [the "we only need ever write one kernel" strategy which is serving Allwinner really really well apart from the code-duplication mistake], do the benefits you list *still* apply, and if so, could you please elaborate for me, assume i'm thick or something [or at least not a programmer, which i am unfortunately so might miss something] l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedwu+rztcgb20uh7jxazjbrx_yhva4sy_atr7mwpbb4...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
thomas i _very_ briefly spotted this when i was extremely busy yesterday, and i'm grateful to the 2 or 3 people who've given me the keywords and/or links to catch up. On Thu, Jun 6, 2013 at 10:27 AM, Thomas Petazzoni wrote: > Dear Tomasz Figa, > > On Thu, 06 Jun 2013 02:01:14 +0200, Tomasz Figa wrote: > >> I don't see any other solution here than moving all the Allwinner >> code to DT (as it has been suggested in this thread several times >> already), as this is the only hardware description method supported >> by ARM Linux. > > Have you noticed that it is already the case in mainline? i knew there was a little bit, but not the extent of the commits. > My colleague Maxime Ripard (Cc'ed) maxime: we need to talk :) please tell me in 4 or 5 sentences what you've managed to do so far, expanding a little on what thomas says below, more specifically what it achieves and/or allows rather than technically what it does (suitable for managers and directors in other words), and what plans you'd like to see happen. > is the maintainer of the mainline Allwinner sunxi > effort. It already supports a number of boards, has a pinctrl driver, a > GPIO driver, serial port is working, network is working, I2C is > working. > > All in mainline, completely Device Tree based. great. which version did it first hit, i.e. what will the first signs of this be when allwinner begin doing "git pulls"? and which boards. bear in mind that one of those "boards" should really be "the total range of products available across hundreds of chinese tablet clone manufacturers". specific question: is one of the "boards" the one that tom cubie submitted, which covers virtually every android tablet product manufactured in the millions by chinese tablet clone manufacturers? > So isn't this entire discussion completely moot? no because it's totally in isolation from allwinner. i need to give them a heads-up, and get them involved, giving them specific incentives [which nobody's yet given!!] for following a particular path [or paths] yet to be recommended. > The mainline support > for sunxi has already started since 6 months or so, and has been Device > Tree based from day one. to clarify: the *community-driven* mainline support for sunxi. ok - which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i (Dual-Core Cortex A7)? which ones are in? l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzW60poOYahm31aW3_A=nvzmybpppgm9pzdvupjnju...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 9:18 AM, Alexandre Belloni wrote: > On 07/06/2013 10:06, luke.leighton wrote: >> On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic wrote: >>> luke.leighton wrote: >>>> 3 days remaining on the clock. >>> >>> what catastrophic thing will happen when the time runs out? >> no catastrophe, vladimir: all that happens is that an opportunity is >> lost, and the result of that is that the situation remains as it is, >> with a major soc vendor being divorced from and isolated from the free >> software community, who will continue to have to shoulder the >> frustrating and isolated burden of responsibility of reworking >> "over-the-fence" kernel patches as best they can with the limited >> resources that they have. > > I think the question was: what will be done in 3 days that cannot be > undone ? and you didn't answer that. apologies for not being clear. there is nothing that cannot be "undone". i trust that that answers the specific question you've asked. let me try to put it into "undo" words. this is about me (a messenger) offering you plural (the linux kernel community) an opportunity to "undo" the mess-that-is-perceived-to-be-the-case wrt one specific SoC vendor, named "Allwinner". let me try to put it another way. i cannot specifically state EXACTLY what will "be done", because i do not have authorisation to make that publicly known. i am trying hard to hint at what can be "done", and the deadline is monday 10th june 2013 to get a clear proposal in which will make its way to allwinner, by means that i cannot specifically tell you about because i do not have the specific authorisation or permission to tell you. does that point you in the right direction? can we please get on with taking advantage of this opportunity and discuss options that can be presented, instead of asking these kinds of questions? > I don't understand why your are > still stating that Allwinner will never be able to get code in the > mainline i didn't say that. apologies if that wasn't clear. > after Olof and Maxime told you that they are already working, > at least discussing with them. > apologies, i missed that. there's a lot i need to get up-to-speed, in very little time. i have some keywords to search for now i'll go find those messages. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDy3hCvusHvWMBki0ak=se51rtu-1wyid3hawoqut8w...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic wrote: > luke.leighton wrote: >> >> On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic >> wrote: >> >>> 4 days? WTF? since when did setting an ultimatum to the kernel >>> community work? >> >> >> i was only informed of the opportunity 2 days ago, vladimir. this is >> an important meeting. of course the linux kernel community is >> entirely free to: >> >> * completely ignore this opportunity >> * continue to complain that soc vendors do not follow their >> unilaterally-decided rules > > > SoC vendors are free to join the discussion, and many SoC vendors are part > of the kernel community, so calling this unilateral is plain wrong. you're free to believe that, vladimir. i've explained why that hasn't happened, in prior messages. can we move forward, please? > >> 3 days remaining on the clock. > > > what catastrophic thing will happen when the time runs out? no catastrophe, vladimir: all that happens is that an opportunity is lost, and the result of that is that the situation remains as it is, with a major soc vendor being divorced from and isolated from the free software community, who will continue to have to shoulder the frustrating and isolated burden of responsibility of reworking "over-the-fence" kernel patches as best they can with the limited resources that they have. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedxfwcv7hsduo6uc751iipg9ngdqc5ub7mbxwbespwf...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux wrote: > If companies are going to go off and invent the square wheel, and that > makes *them* suffer the loss of being able to merge back into the > mainline kernel, thereby making *their* job of moving forward with > their kernel versions much harder, then yes, we *are* happy. russell: they have more employees than sense :) they also don't have any idea of what they *should* be doing, so this is an opportunity to educate them. they're not feeling any pain: they just employ more chinese developers and substitute bodies for time and common-sense. also, in this particular case, thanks to their script.fex system when i said they only need to develop one kernel and one u-boot i really wasn't kidding around: they really have got to the point which everyone else dreams of with device-tree [admittedly by limiting the product range that their clients can play with, but that product range has huge returns, so they're still happy]. > Companies will always do idiotic things; it's *them* and their users > who have to live with the results of that bad decision making process. russell: the decision process they've made is actually an extremely effective one. > Eventually, the pain of being outside the mainline kernel will become > too great, especially if their users demand things like kernel upgrades > from them. Eventually, they will change. > > And no, this isn't an intransigent position. This is reality given > that ARM already has way too much code in the Linux kernel and we're > trying to reduce that through the use of technologies like DT. The > last thing we need right now is for another "DT" like implementation > to come along which is only used on a minority of platforms - even if > the platform it is used on is successful. > > The way this works is this: > - you either go with the policies which are set, or which they weren't consulted on, it has to be pointed out. > - you change the policy as a whole because you have a technically > superior solution i believe they have a technically more *successful* solution. whether it's more appropriate in a wider context is another matter. here we have a key to the crux of the problem: the linux kernel maintainers have to cater for _everyone_. with no funding or incentive from the major contributors to work with them. hmmm > What that means in this case is either you adopt DT, or you convince > everyone that DT isn't the solution, but your solution is, and we adopt > your solution for *everything* instead. > > If neither of those are possible, then that's really not our problem, > and it's not _us_ who are being "intransigent". indeed. ok. so. we come back to the question again: what shall i propose to them that they consider doing, and what benefit would it be to them to do so? i cannot go to them and say "you have to do this [insert proposal here]" - it has to be more subtle than that. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDyYt+pN+UaFuqWL5RrHpyuq_4So-tArmx3dr=0wls+...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 2:02 PM, Tomasz Figa wrote:
> On Thursday 06 of June 2013 13:49:38 luke.leighton wrote:
>> On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa
> wrote:
>> > Luke,
>> >
>> > On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
>> >> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa
>> >
>> > wrote:
>> >> > I don't see any other solution here than moving all the Allwinner
>> >> > code
>> >> > to DT (as it has been suggested in this thread several times
>> >> > already), as this is the only hardware description method supported
>> >> > by ARM Linux.
>> >>
>> >> i repeat again: please state, explicitly and unequivocably that you
>> >> -
>> >>
>> >> linux kernel developers - are happy that the reach of linux and
>> >> gnu/linux OSes is dramatically reduced due to this intransigent
>> >> position.
>> >>
>> >> or, tomasz, please state that you, tomasz, represent each and every
>> >>
>> >> one of the linux kernel developers so that i do not need to keep
>> >> asking.
>> >
>> > I do not represent all linux kernel developers by any means. I am just
>> > stating current policy of SoC/board support maintained by ARM Linux,
>> > which is common for all Linux kernel devlopers, or at least ARM Linux
>> > kernel developers.
>> >
>> > Personally I am happy with numerous companies backing this policy and
>> > not making problems like this with Allwinner and I am really
>> > surprised that you are supporting a troublesome company like this.
>>
>> you've not read what i've written tomasz.
>
> I have.
>
>> > There are many other SoC vendors making low cost SoCs, like Rockchip,
>> > Boxchip,
>>
>> boxchip *is* allwinner.
>
> Right, sorry. I am not really into this low cost hardware.
i've been tracking it for several years.
> There is also AMLogic, though.
they're *definitely* GPL-violators.
>> > Telechips. Maybe they would be better candidates for being
>> > promoted as vendors of choice for hardware running free software?
>>
>> no, because they're not selling at a low-enough price with
>> high-enough integration. telechips and rockchip don't have the market
>> penetration.
>
> I do not have access to any numbers, so I am left to believe in what you
> say.
well... none of us do :) that report (was it from IDC? it was in
earlier messages) is a good analysis.
> (Although here in Poland the cheap tablet market is almost evenly
> divided between all those companies, you can find almost same amount of
> tablets based on SoCs from each vendor.)
most likely.
allwinner is the one that's actually expressed an interest, at
Director (Board) Level, of being GPL-compliant. the software
engineers understand that; their immediate Manager does not [and is
causing considerable disruption].
AMLogic stone-walled and cost us money and a large client due to
their GPL violations. which they till have not resolved [in over 2
years]. i will not work with them, ever again.
Telechips are korean-based: they haven't responded to communications.
Nufront got themselves in a muddle [late on silicon] so we ruled them
out - we'll come back to them later.
there's a number of others, but allwinner's the only one that is
actively communicating.
so.
coming back to what you said earlier: i'm formulating what to say to
allwinner [and need to pre-send something by monday so that they can
consider it before the meeting]. so far, it consists of:
* device-tree is what the linux kernel community has come up with, it
is equivalent to FEX.
* the linux kernel community would like to apologise for not
consulting with you (allwinner) on the decision to only accept device
tree
[bear in mind that if this kind of thing isn't said, they risk just
continuing to make the sunxi community's life absolute hell by
continuing to work in isolation and continuing to duplicate drivers
etc. etc. ]
* work is being done by the free software community, they are
beginning to integrate allwinner's work into the upstream kernel, and
you (allwinner) will begin to see this when you get round to doing
linux kernel 3.9
* allwinner and the linux and sunxi community therefore need to work
closer together, we propose:
* {insert proposals here}
3 days left on the clock.
l.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAPweEDx_1fvAv9sROtPreoyyj_yDAuYb040fM2zPc+tf22d=y...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic wrote: > 4 days? WTF? since when did setting an ultimatum to the kernel > community work? i was only informed of the opportunity 2 days ago, vladimir. this is an important meeting. of course the linux kernel community is entirely free to: * completely ignore this opportunity * continue to complain that soc vendors do not follow their unilaterally-decided rules * to continue to its chosen course of making unilateral decisions and setting unilaterally-decided rules and to experience the consequences. i'm extremely busy, vladimir, and i'm acting as the messenger here. 3 days remaining on the clock. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedwr_nwusi-j53m8muoav1rxm4wnnxtrioa2cjndyqe...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa wrote: > Luke, > > On Thursday 06 of June 2013 13:24:57 luke.leighton wrote: >> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa > wrote: >> > I don't see any other solution here than moving all the Allwinner code >> > to DT (as it has been suggested in this thread several times >> > already), as this is the only hardware description method supported >> > by ARM Linux. >> i repeat again: please state, explicitly and unequivocably that you - >> linux kernel developers - are happy that the reach of linux and >> gnu/linux OSes is dramatically reduced due to this intransigent >> position. >> >> or, tomasz, please state that you, tomasz, represent each and every >> one of the linux kernel developers so that i do not need to keep >> asking. > > I do not represent all linux kernel developers by any means. I am just > stating current policy of SoC/board support maintained by ARM Linux, which > is common for all Linux kernel devlopers, or at least ARM Linux kernel > developers. > > Personally I am happy with numerous companies backing this policy and not > making problems like this with Allwinner and I am really surprised that > you are supporting a troublesome company like this. you've not read what i've written tomasz. > There are many other SoC vendors making low cost SoCs, like Rockchip, > Boxchip, boxchip *is* allwinner. > Telechips. Maybe they would be better candidates for being > promoted as vendors of choice for hardware running free software? no, because they're not selling at a low-enough price with high-enough integration. telechips and rockchip don't have the market penetration. and many other reasons. > (Just > saying, as I do not know anything about their view on this. There is a lot > of cheap tablets built using their products as well.) > > Best regards, > Tomasz > -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDxWW4LUeBaHLb+wHuAMq=63p88zsx4tumvb2pdp_+o...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa wrote: > I don't see any other solution here than moving all the Allwinner code to > DT (as it has been suggested in this thread several times already), as > this is the only hardware description method supported by ARM Linux. i repeat again: please state, explicitly and unequivocably that you - linux kernel developers - are happy that the reach of linux and gnu/linux OSes is dramatically reduced due to this intransigent position. or, tomasz, please state that you, tomasz, represent each and every one of the linux kernel developers so that i do not need to keep asking. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzYLDzh_-OWU61dtVhajZ40QpQgZKHFYDsh3FgF=r9...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 1:19 AM, Henrik Nordström wrote: > tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton: > >> > Not really the case. Actually the opposite. DT have this as well, and >> > integrated in device probing. Allwinner need to hack every driver used >> > to add their gpio requests to have pinmuxing triggered. >> >> augh. ok. solutions. what are the solutions here? > > What I said before. idea: hook into devicetree gpio functions to allow script-fex gpio functions to gain access in a separate module? that sort of thing. > Go with DT for the kernel. There is no need for two configuration > mechanisms doing the same thing. Disguise it in fex form (and > translator) if too hard for people with a DOS editior to configure. what methods for doing that. i need proposals. 4 days on the clock. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedypffcn9cnj10zht+azjhtrdu0lmfcgm_756uabf+n...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 1:15 AM, Henrik Nordström wrote: > conditions. I don't know what you really mean here, only that it's not > "target market". mass-volume tablet, mass-volume IPTV box. android OS, nothing else. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzrYL5c9v1T=nTcyv9RPrJ-TEnCyyjpHQnhXXJY-32=5...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 12:40 AM, jonsm...@gmail.com wrote: > I have a Cubieboard and I have a pca9532 on my desk. Now I want to > attach this pca9532 to the Cubieboard so I wire them together on I2C. > > How is the Allwinner kernel going to load the driver for the pca9532? > The mainline pca9532 driver does not understand fex so it can't read > the necessary initialization data. jon: you're immediately outside of the target market for which allwinner designed and deployed script.fex. > Luke, you of all people should see what is going on. Take an EOMA > module based on an A10. Now plug it into ten different hosts with > widely varying hardware support - like each of the ten hosts has a > different lm-sensor type chip. Where are the fex drivers for those ten > different lm-sensor chips going to come from? We already have DT > support for them. that's fantastic, because as you can see, the two systems complement each other. > fex is only supported on the small number of peripheral chips > Allwinner has blessed. Use any chip outside of that set and it isn't > going to boot. eeexactly. i did say "target market". so, we have a clear illustration that neither script.fex nor devicetree actually help solve the "chip proliferation" problem. but that's another story, and getting off-topic. what i need is a clear set of proposals, discussed and then the best one(s) that people can come up with be then summarised so that i can get them clearly and succinctly across to allwinner, along with the benefits to allwinner of each of the options. time is of the essence, speaking of which i'm pushing things to the limit including my health so i *really* have to go, i'm going to leave this up to everyone to discuss, please nominate someone to email me directly [on a different subject] so that i can read the proposals summaries should people choose to write any. thanks. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedyo+sc1aq64hbeh1oszmpnsnwmweo5kbhsan5vw_ye...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 12:40 AM, Henrik Nordström
wrote:
> tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
>
>> no john - they've only added it to the multiplexed sections of the
>> drivers which they themselves have written. such as
>> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
>> arch/arm/mach-sun{N}i and so on.
>
> And a number of SPI device drivers, USB device drivers, vendor provided
> device drivers, ..
>
>> the script.fex system deals with the pinmux issue in a very neat way that:
>>
>> a) has very little impact on the rest of the kernel tree [citation
>> needed! i'm saying that: could someone please confirm if it's true]
>
> Not really the case. Actually the opposite. DT have this as well, and
> integrated in device probing. Allwinner need to hack every driver used
> to add their gpio requests to have pinmuxing triggered.
augh. ok. solutions. what are the solutions here?
l.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAPweEDwS3tR=wh-bZJb3vqR8fVQra=3xxditowgrdh9c7wr...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 12:07 AM, jonsm...@gmail.com wrote:
> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton wrote:
>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
>> wrote:
>>
>>>> and then there's the boot0 and boot1 loaders, these *do* have
>>
>>> no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
>>> (not cache), but boot1 is on pair with u-boot in size and runs from
>>> DRAM.
>>
>> btw, please listen to henrik: he knows what he's talking about, as
>> you can see :) henrik, thank you for correcting my technical
>> misunderstandings, i'll try to remember them and not propagate
>> incorrect stuff.
>
> This is not about the fex syntax or uboot. The root problem is needing
> two sets of binding for every device driver in the kernel. Pick a
> random driver like gpio-pca953x.c and look at the source. In that file
> there are #ifdef CONFIG_OF_ sections. Those sections are directly
> reading the FDT binary via calls like of_get_property(node,
> "linux,gpio-base", &size);. If fex is added to the kernel every driver
> driver will now need both a #ifdef CONFIG_OF_ section and also a
> #ifdef CONFIG_FEX_ section. Doing that is just crazy.
yes. which is why they haven't done it.
> Is Allwinner
> going to add fex support to every single device driver in the kernel?
no john - they've only added it to the multiplexed sections of the
drivers which they themselves have written. such as
drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
arch/arm/mach-sun{N}i and so on.
even the touchscreen driver that they wrote, that's got nothing to do
with any other code in the touchscreen linux kernel source tree: it's
more of a "meta-"driver which even has the name of the linux kernel
module that needs to be loaded and what I2C address, GPIO options etc.
to pass in [normally done as modprobe options in userspace].
to be honest, there are better people to fully answer this question
(alejandro and henrik are two that spring to mind) but you're
definitely off-base, jon. the script.fex system deals with the pinmux
issue in a very neat way that:
a) has very little impact on the rest of the kernel tree [citation
needed! i'm saying that: could someone please confirm if it's true]
b) the linux kernel developers could, instead of criticising it,
actually learn a great deal from.
l.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/capweedw1babe0cmt5fxz3z9p9eh508m3nzcqk2vco0oz-qy...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström wrote: >> and then there's the boot0 and boot1 loaders, these *do* have > no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM > (not cache), but boot1 is on pair with u-boot in size and runs from > DRAM. btw, please listen to henrik: he knows what he's talking about, as you can see :) henrik, thank you for correcting my technical misunderstandings, i'll try to remember them and not propagate incorrect stuff. >> so the point is: if anyone wishes me to propose to allwinner that >> they convert over to devicetree, or any other proposal which involves >> significant low-level changes to their working practices that could >> potentially have a massive knock-on effect onto their >> multi-million-dollar clients, it had better be a damn good story. > > Calm down. i am - honest! yes it's a little past my bed-time, but hey... > It isn't really a significant difference to them outside of > the kernel. They do not need to change any of their configuraiton > methods, only a small toolchain change in how the resultig images are > built to have a corresponding device tree built. henrik, jon (smirl), can i ask you both a favour? could you write something up, preferably short, that i could put forward to allwinner? describing what's needed, who would need to do what and so on. > But it is a fair bit of one-time changes kernel side. And some > scratching to figure out how to use/improve/ignore the stuff being > mainlined. i still also - really - need a good justification for this. something which helps explain clearly what the immediate or perhaps strategic benefits would be to allwinner, as to why they should accept such changes. i cannot emphasise enough how important that is. if someone can please help come up with a good justification as to why allwinner should change their working practices, that would be enormously helpful i feel, to solving this issue. otherwise we are stuck in the current situation which nobody really likes. i'm inviting you - linux kernel developers - i'm giving you an opportunity to *fix* things. you have 2 weeks to come up with a solution, which can be presented in a simple format. that's the window of opportunity. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDxMpeJc-w=Yd7d2OT=uisrbp2rxf-mpmducog3eyjz...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 10:47 PM, Henrik Nordström wrote: > ons 2013-06-05 klockan 22:15 +0100 skrev Luke Kenneth Casson Leighton: > >> what we do not want to happen is that they see upstream patches being >> submitted, they merge them into their internal tree (which to date has >> had zero upstream changes: they're currently only just getting round >> to doing 3.4 as we speak), and they *completely* ignore *absolutely >> everything* that's being done by the community, duplicating yet >> another set of device drivers (named drivers/*/sun8i_* and so on). > > Well, that will obviously happen one or two more rounds, a bit depending > on which kernel releases Android will use. But I hope the Allwinner > kernel team will rethink when they hit more current kernels. yyyeahhh. that's the whole point, henrik: i'd like to give allwinner a heads-up *before* that happens, and to also give the linux and sunxi kernel developer teams an opportunity to hear what allwinner would like to see happen (if anything). what i *really* don't want to happen is for them to get a nasty surprise some time around 3.9 or above, along with a hell of a lot of kernel conflicts that cause them to completely abandon the entire current linux directory conventions. or worse, do "find . -name "*sunxi* | xargs git rm" on linux 3.9 [or above] prior to perging in *their* versions. >> this proposal is a start: however what you have to bear in mind is >> that you now have to convince a very busy company that it is in their >> best interests to disrupt their schedule, to drop their existing >> working practices, to tell all their customers "please stop using the >> existing tools and please use these ones instead". > > Why? taking this as a rhetorical question (kinda), what i believe jon proposed would have a knock-on effect of requiring that boot0 and boot1 be converted *away* from script.fex and onto DT. therefore, automatically, all tools must now be converted to understand DT not fex. that includes the (proprietary) equivalents of fex2bin and bin2fex [*1] but, i could be wrong. >> you also need to convince the creators of the proprietary >> firmware-flashing tools "livesuite" and "phoenix" to *also* convert >> their tools over to the new proposed idea. > > Why? > >> can you provide such a supporting argument which would convince >> allwinner to accept the modifications to their working practices that >> you propose? > > It does not really need to be such big modifications to their working > practices. Their configuration working practices is all built around the > fex file, and the new practices can be > > 0. Assuming kernel drivers gets ported over to using device tree. > > 1. Do configuration as you have always done in the .fex > > 2. Modify the build script to build a device tree from the fex + > template, in addition to script.bin. > > 3. Tell u-boot to load the device tree for the kernel. > > That's it really. > > livesuit do not modify script.bin. script.bin is compiled from the .fex > at image creation time. A couple more lines in the build script (and a > suitable translation tool) and there is also a device tree built and > installed and you get a nice and smoot transition. ok: great. so we have something that i can potentially propose to them. now: what reason can i give that they should accept this? what's the biggest incentive for them, here, to make these changes? what would they gain? >> > Device tree on ARM's goal is to achieve a single kernel across vendors, not >> > just a single kernel for a single vendor. >> >> you'll be aware that i've mentioned a number of times and have >> discussed at some length why this is a goal that is completely >> impossible to achieve [*1]. sadly. > > Here I disagree. It is possible. Not across all vendors but a > significant share. time will tell, henrik [i mean that sincerely, not in a trite way]. fortunately as you know (but many people on these various lists may not), with the eoma initiatives [*2], we bypass that possibility, and through hardware standardisation turn an N*M work problem into an N+M+2 work problem (where N is number-of-SoCs and M is number of product types). l. [*1] https://github.com/linux-sunxi/sunxi-tools [*2] http://elinux.org/Embedded_Open_Modular_Architecture -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedwrpoycfuwjvf99yua_tbooneeh8uktzvc7dtev6fa...@mail.gmail.com
Re: modifying and verifying debian installer for armhf board (a10-eoma68)
On Wed, May 22, 2013 at 10:32 AM, Arnaud Patard wrote: > Ian Campbell writes: > > Hi, > >> On Sun, 2013-05-19 at 18:48 +0100, luke.leighton wrote: >>> > But the obvious answer here is to get support for your device into the >>> > appropriate Debian kernel flavour and then integrated into the standard >>> > d-i images. If there is upstream support then this ought to be more or >>> > less trivial. >>> >>> yeees.. that would be good. what's the procedure there? someone's >>> already built one: >>> http://dl.linux-sunxi.org/users/niall/debian/ >> >> If you can identify which config options need to be enabled for a v3.9 >> kernel (which I think is due to hit Sid soon) then a wishlist bug would >> do the job. Likewise if there are some backports required etc you could >> request them in the same bug. >> >> Looks like CONFIG_ARCH_SUNXI is part of the multi_v7_defconfig upstream, >> which suggests it would be a candidate for being enabled in the new mp >> (multiplatform) kernel flavour. > > It's enabled in my local 3.9 armmp work [1] but allwinner a10 support in > mainline resume to soc/ram and watchdog support (watchdog not in 3.9) so > all you can do is booting a ramdisk and connect on the serial port to 'use' > it. ok - thanks arnaud. ok, so we stick with 3.4 for now [*1], do a local build (based on niall's work). l. [*1] stage/sunxi-3.4 with just one key fix: https://github.com/linux-sunxi/linux-sunxi/tree/b341bf8889e5e553d20f0e14115e5f4a3530ff10 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDx_R0Z=24lwozdcy9fxkr2p-xvfnsj_ctzrm_mjaya...@mail.gmail.com
Re: modifying and verifying debian installer for armhf board (a10-eoma68)
On Wed, May 22, 2013 at 9:44 AM, Ian Campbell wrote: > On Sun, 2013-05-19 at 18:48 +0100, luke.leighton wrote: >> > But the obvious answer here is to get support for your device into the >> > appropriate Debian kernel flavour and then integrated into the standard >> > d-i images. If there is upstream support then this ought to be more or >> > less trivial. >> >> yeees.. that would be good. what's the procedure there? someone's >> already built one: >> http://dl.linux-sunxi.org/users/niall/debian/ > > If you can identify which config options need to be enabled for a v3.9 > kernel (which I think is due to hit Sid soon) then a wishlist bug would > do the job. Likewise if there are some backports required etc you could > request them in the same bug. sun4i_defconfig would do the job, pretty much. cc'ing arm-netbook: does anyone know the best people to notify who can advise here? alejandro? henrik? > Looks like CONFIG_ARCH_SUNXI is part of the multi_v7_defconfig upstream, > which suggests it would be a candidate for being enabled in the new mp > (multiplatform) kernel flavour. , that'd be absolutely awesome. also it'd be nice to finally have mainline support for the processors that have according to one report [*1] have a 40% world-wide market share, eh? :) l. [*1] http://hardware.slashdot.org/story/13/05/08/1636217/chinas-allwinner-outsold-intel-qualcomm-in-tablet-processors-in-2012 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzqOJVgYB9d6uyzh0OvKwL0dUCEKqi2F=Wrb4y=0rp...@mail.gmail.com
Re: modifying and verifying debian installer for armhf board (a10-eoma68)
On Sun, May 19, 2013 at 12:04 PM, Ian Campbell wrote: > I don't know if the password thing is because ssh just doesn't let you > use no password or if it's because the normal use case here is on > regular Ethernet. In any case it doesn't seem like a blocker for a first > pass and could likely be switched easily enough to use telnet in the > future. yehh... there's another advantage: i can do absolute minimum changes to a pre-existing initramfs, by unpacking it, removing /lib/modules/*, copying over from a known-good-working initramfs, then adding in a replacement busybox (again, a verified working one), then the other path - to use the standard build procedures to create an initramfs: how do i know if it's working? remember: no JTAG, no console. that means no early debugging, no early printk, no access to syslog. so i need to go in very small increments from known-good to known-good. even going to an unknown initramfs (debian-installer one) where i'm putting in modprobe g_ether and modprobe usbnet is still a considerable jump. going to an initramfs with openssh server installed is _way_ too big a jump. at the moment i'm trying to work out how to chroot execute the files unpacked from a netboot initramfs, putting them onto an sdcard and booting from a miniroot ramfs i created earlier (and know works). i might be forced to create a small microsd card partition (or move my debian armhf files out the way) in order to minimise the number of changes / steps. >> > (obviously the bit about using the factory image to flash the firmware >> > you can ignore in favour of fel boot). >> >> yes. once running, still need to resolve what kernel to install (if >> any). is that possible with debian-installer? the procedures for >> installing a kernel (which are normally required to be in the 1st >> partition, fat-formatted) and even just _obtaining_ a kernel are >> tricky: absolutely everyone right now either custom-builds or uses >> stock ones. >> >> how do you tell debian-installer "i don't want a kernel installed >> thanks for offering"? > > If it can't determine which kernel flavour works with your hardware then > it'll ask and one of the options is "just continue". That can probably > be preseeded away. thanks ian. > But the obvious answer here is to get support for your device into the > appropriate Debian kernel flavour and then integrated into the standard > d-i images. If there is upstream support then this ought to be more or > less trivial. yeees.. that would be good. what's the procedure there? someone's already built one: http://dl.linux-sunxi.org/users/niall/debian/ > Otherwise you are looking at patching whichever udeb (looks like it > might be libdebian-installer) chooses the kernel based on the platform > to offer extra options to get a kernel from elsewhere. > > You'll probably also need to teach flash-kernel about your devices > requirements (kernel in a FAT partition etc). *grin*. ok. >> > The main thing you need to be included in the image to make it this type >> > seems to be the network-console openssh-server-udeb udebs. >> > debian-installer/build/pkg-lists/network-console also lists >> > libnss-files-udeb >> >> ah good. that's a big clue. got hold of network-console.udeb and >> openssh-server.udeb, unpacking them... ah ha! >> bin/network-console-menu and friends, _great_. >> >> hmmm... now... where's the best place to put these [for execution as >> /sbin/telnetd -l /bin/network-console-something] > > Put them? They should be unpacked in the installer initrd which you > build. yes. i was just wondering how to execute them. right now i've chosen /lib/debian-installer-startup.d/S98telnetd l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedyunog8s+pjubh8v+jfwp6idnsoku0kc3uxwpzhnub...@mail.gmail.com
Re: modifying and verifying debian installer for armhf board (a10-eoma68)
On Sun, May 19, 2013 at 11:41 AM, Arnaud Patard wrote: > "luke.leighton" writes: > Hi, > >> On Sun, May 19, 2013 at 7:49 AM, Ian Campbell wrote: >>> On Sat, 2013-05-18 at 12:18 +0100, luke.leighton wrote: >>>> * create a modified netinst-initrd that uses usb0 ethernet gadget >>>> *blind* (no console!!) which gets far enough on its own to do DHCP >>>> client >>>> >>>> * also pre-install some sort of service (ssh? busybox telnet? other?) >>>> which allows an interactive login >>> [...] >>>> * log in (somehow) to the board over usbnet >>> >>> Sounds like you want a network-console flavour image, like the ones used >>> for kirkwood, http://www.cyrius.com/debian/kirkwood/qnap/ts-41x/install/ >> >> it does, doesn't it? i've been thinking that through (and also >> looking at the source of debian-installer). the only thing that >> doesn't make sense is: it's all set up to require a password. why >> would you need a password for connecting to something that - pretty >> much without fail - is going to be sitting 1/2 a metre away on the end >> of a usb cable and nothing else? >> >> i.e. there's no guarantee on these devices especially things like the >> MK802 that there will be ethernet. there's almost certainly no >> tablets using allwinner a10 processors that have ethernet (not even >> the flying squirrel). >> >> so i'm tempted to just do an experiment - just because i can - to use >> busybox-telnetd - because the route of using openssh _has_ been solved >> already but isn't quiiite appropriate, and i think >> telnetd-over-g_ether will turn out to be a very useful combination. >> >> i'd do g_serial and it would be done already but i need the damn >> micro-usb port for a network! :) > > what about using cdc composite gadget driver ? : > > From drivers/usb/gadget/Kconfig: > config USB_CDC_COMPOSITE > tristate "CDC Composite Device (Ethernet and ACM)" ah! thank you! i hadn't noticed that one. ahh, that'd be extremely handy. >> >>> (obviously the bit about using the factory image to flash the firmware >>> you can ignore in favour of fel boot). >> >> yes. once running, still need to resolve what kernel to install (if >> any). is that possible with debian-installer? the procedures for >> installing a kernel (which are normally required to be in the 1st >> partition, fat-formatted) and even just _obtaining_ a kernel are >> tricky: absolutely everyone right now either custom-builds or uses >> stock ones. >> >> how do you tell debian-installer "i don't want a kernel installed >> thanks for offering"? >> > > it may have changed but I think that d-i will tell you that it didn't > find any kernel and ask you if you want to proceed without one. If you > accept, it'll go on finishing installing things. awesome - thanks arnaud. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedwkgymvxs_9b4g29wqpezzk9njgy6zf4k4hvsxv6u6...@mail.gmail.com
Re: modifying and verifying debian installer for armhf board (a10-eoma68)
On Sun, May 19, 2013 at 7:49 AM, Ian Campbell wrote: > On Sat, 2013-05-18 at 12:18 +0100, luke.leighton wrote: >> * create a modified netinst-initrd that uses usb0 ethernet gadget >> *blind* (no console!!) which gets far enough on its own to do DHCP >> client >> >> * also pre-install some sort of service (ssh? busybox telnet? other?) >> which allows an interactive login > [...] >> * log in (somehow) to the board over usbnet > > Sounds like you want a network-console flavour image, like the ones used > for kirkwood, http://www.cyrius.com/debian/kirkwood/qnap/ts-41x/install/ it does, doesn't it? i've been thinking that through (and also looking at the source of debian-installer). the only thing that doesn't make sense is: it's all set up to require a password. why would you need a password for connecting to something that - pretty much without fail - is going to be sitting 1/2 a metre away on the end of a usb cable and nothing else? i.e. there's no guarantee on these devices especially things like the MK802 that there will be ethernet. there's almost certainly no tablets using allwinner a10 processors that have ethernet (not even the flying squirrel). so i'm tempted to just do an experiment - just because i can - to use busybox-telnetd - because the route of using openssh _has_ been solved already but isn't quiiite appropriate, and i think telnetd-over-g_ether will turn out to be a very useful combination. i'd do g_serial and it would be done already but i need the damn micro-usb port for a network! :) > (obviously the bit about using the factory image to flash the firmware > you can ignore in favour of fel boot). yes. once running, still need to resolve what kernel to install (if any). is that possible with debian-installer? the procedures for installing a kernel (which are normally required to be in the 1st partition, fat-formatted) and even just _obtaining_ a kernel are tricky: absolutely everyone right now either custom-builds or uses stock ones. how do you tell debian-installer "i don't want a kernel installed thanks for offering"? > The main thing you need to be included in the image to make it this type > seems to be the network-console openssh-server-udeb udebs. > debian-installer/build/pkg-lists/network-console also lists > libnss-files-udeb ah good. that's a big clue. got hold of network-console.udeb and openssh-server.udeb, unpacking them... ah ha! bin/network-console-menu and friends, _great_. hmmm... now... where's the best place to put these [for execution as /sbin/telnetd -l /bin/network-console-something] l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedyessz1v8refvkcjqvxu7_ynkoym6t811m+pbjwphr...@mail.gmail.com
Re: modifying and verifying debian installer for armhf board (a10-eoma68)
i've started a page here which is the notes being collated to get this done: http://rhombus-tech.net/allwinner_a10/debian_netboot/ l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedw3-t8jl6gpadcvwjyckssdqferw0nts04apcdz7kg...@mail.gmail.com
modifying and verifying debian installer for armhf board (a10-eoma68)
i got debian/armhf up and running on the a10-eoma68 board, but i'd like to make it easier for other people to install debian on it. the generally-proven method "go download some whopping great 1gbyte random image off the internet with packages preinstalled that you don't actually want" is pretty shit, so i'd like to do a debian-installer image. previously it was frans pop, bless 'im, who created a suitable debian-installer netinst for us. the hardware we have is as follows: * no JTAG (don't ask...) * A10 processor with direct-to-memory loading and execution over Micro-USB [called FEL: front-end-loader] * NAND driver which needs some work (messy android, not mtd-compliant) so can't use it * working SDcard working (on SD3) * usb-gadget *only* (no network, no usb-host) here's what's been achieved already [thanks to help from several people]: * usb fel boot using miniroot: https://github.com/hno/miniroot * modify miniroot to get it working with g_ether and usbnet * modify miniroot to allow telnetd logins * usb fel boot using debian armhf image: http://rhombus-tech.net/allwinner_a10/boot/ * confirm HDMI working on /dev/fb0 so - here's what i'd like to achieve over the next few days * boot a board using usb felboot: https://github.com/linux-sunxi/sunxi-tools/tree/master/felboot * create a modified netinst-initrd that uses usb0 ethernet gadget *blind* (no console!!) which gets far enough on its own to do DHCP client * also pre-install some sort of service (ssh? busybox telnet? other?) which allows an interactive login * use felboot to download a kernel, netinst-ramdisk and u-boot *direct* to memory of the board * log in (somehow) to the board over usbnet * get a kernel installed e.g. from here without prompting: http://dl.linux-sunxi.org/users/niall/debian/ * do an example minimal install onto a blank sdcard. that's the main goal. preparing the boot partition (vfat) so that the sdcard will boot is *outside* the scope, here. my main concern is to get past this first stage. i apologise: it looks like a lot, but it isn't! it's just a large chain of inter-connected awkwardness that should clear up a considerable mess in the arm world where people just insist on putting out these absolutely shit 1gbyte and 4gbyte pre-installed images. or force people into a situation of using the cross-install mode debootstrap. so - another way is rather badly needed, not just for this board but for MK802 and many other bits of hardware which have micro-usb gadget. suggestions on how to proceed greatly appreciated. also, where's the best place to hold this discussion? l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedx39j3nj9jz6g47z0totzzmhas3q3znh3n2kqkvpov...@mail.gmail.com
Re: [Arm-netbook] device tree not the answer in the ARM world [was: Re: running Debian on a Cubieboard]
On Mon, May 6, 2013 at 9:22 AM, Oliver Schinagl wrote: > Note, I'm not qualified nor important or anything really to be part of > this discussion or mud slinging this may turn into, but I do fine some > flaws in the reasoning here that If not pointed out, may get grossly > overlooked. allo oliver - did a quick read, didn't see anything remotely resembling mud :) which is a pity because i am looking forward to making my next house out of compressed earth with a 3% concrete mix. but seriously: the only thing i'd say is it's a pity in some ways you replied to this message rather than to the reply that robert wrote [but i'd trimmed that], because i made a summary of the whole original message based on robert's prompting and insights, and also invited people to come up with some potential alternative solutions. and to do that, the problem has to be properly recognised, which unnnfortunately takes quite a lot of thought/reading/observations to take into account and express. i don't necessarily have the best experience to do that, which is why i asked people if they could help, and in that regard your review is really really appreciated. ok, so let's have a look... > On 06-05-13 06:09, Robert Hancock wrote: >> On 05/05/2013 06:27 AM, Luke Kenneth Casson Leighton wrote: > So yes, every single ARM SoC/platform will need its own dedicated > SPL/U-boot. Kinda like a bios? kinda like a BIOS, yes. except the differences are that a BIOS (and ACPI) stay around (ROM, TSRs), whereas SPL and u-boot merely do the board-bring-up and once done you're on your own [side-note: so there is considerable code duplication between u-boot and the linux kernel, and u-boot typically does bit-level direct manipulation of GPIO as it's simpler] so, whereas a BIOS (and ACPI) ease the pain of bringing up a system (actually multiple systems that conform to the same BIOS and ACPI standards), and help normalise it (them) to a very large extent (bugs in BIOSes and ACPI notwithstanding), in the ARM world the solutions used actually *increase* the number of man-hours required to bring up any one board! > But if you want to boot from LAN (I think > that's what this discussion was about?) you need U-boot loaded by SPL > anyway. Can you boot a generic linux install (say from CD) on arm? if u-boot has cut across sufficient parts of the linux kernel device driver infrastructure then yes! we have a call on the arm-netbooks and linux-sunxi mailing lists for example for addition of USB-OTG to SPL. that means going over to the linux kernel source code, *again* duplicating that code, and adding it to the SPL in the u-boot sources. > Usually no, the onboard boot loader only knows a very specific boot > path, often flash, mmc etc etc. yes. amazingly, the iMX6 supports a ton more boot options than i've ever seen in any other ARM SoC: SATA boot, UEFI partitions and loads more. it's yet another example unfortunately of the insane level of diversity being faced by and imposed on the linux kernel infrastructure. >Those need to be able to bring up the > memory too (SPL) so you'll need some specific glue for your platform > anyhow. yes. this is going to be interesting for when standard DIMMs become commonplace in the aarm64 world, if companies consider making standard ITX motherboards. > I'm not sure if DT was supposed to solve that problem? mmm it would help, i feel, because the RAM timings would be part of the DT. however, it *wouldn't* help because this is incredibly low-level, you'd have to have SPL (which is often extremely limited in size, typically 32k i.e. the same size as the CPU's 1st level cache no that's not a coincidence) understand DT. so it *might* be good, but it might be a very poor match. have to see. in all other cases, where the RAM is hard-wired: DT is not much use. the RAM timings have to be hard-wired, they're done by SPL, SPL is often written with a disproportionately large amount of assembly code, etc. etc. i'm waffling but you get the point? > If that where the case, was DT to replace the BIOS too? i'm sure that was partly the intention, but ARM systems don't *have* a standardised BIOS, because, i feel, there is too much diversity and fragmentation - for very very good and sound business reasons as well as pure good-old-fashioned FUBARness, for any kind of standardisation to make a dent in that mess. >>> >>> * is there ACPI present? no. so anything related to power >>> management, fans (if there are any), temperature detection (if there >>> is any), all of that must be taken care of BY YOU. > Again, I only know about 1 specific SoC, but for the A10, you have/need > an external Power Manamgent IC, basically, a poor man's ACPI if you > must. yes. exactly! this is a _great_ example. if you've seen the offerings from X-Powers and their competitors (MAXIM for example, and then ingenic recommend another company), you'll know that the actual PMIC is *customised* for a particular SoC!!! w
odroid-u2 running 5 simultaneous xrdp sessions
http://lkcl.net/articles/odroid_u2_xrdp_5users.png this is hilarious. above is a screen-shot of 5 instances of rdesktop running on the little odroid-u2 on which xrdp and xfce have been installed (size of the odroid-u2: 45mm square PCB). just a reminder: the odroid-u2 is running with 2gb of RAM and it's a quad-core 1.7ghz ARM Cortex A9. it has 3 USB ports and 1 RJ-45 for 10/100 ethernet. it takes eMMC modules and a Micro-SD card - hardkernel.com sell $25 8gb NAND eMMC modules and $80 32gb ones. only the fact that i didn't set up swap space onto a NAND partition (so as not to destroy it in short order) nor ran a USB HDD swap partition (because it's in storage somewhere) stopped me from running 10 or more sessions. each new user added about 150mbyte of RAM to "top". yes that's xfce in each of the 1024x768 rdesktop sessions. load average at idle is showing around 4 (there are 4 CPUs so that's 100% CPU on each, at idle). firefox and libreoffice are running in each session. so it's pushing the limits, but definitely doable. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedzrapnczu0ox6pjhkrqz9uq30qywrcjlggmvywhs9c...@mail.gmail.com
rhombus tech eoma-68 a10 cpu card *early* orders
apologies folks, i thought i'd sent this out already. in the interests of keeping it brief, let me link to other discussions/invites: http://lists.fedoraproject.org/pipermail/arm/2013-April/005792.html http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-April/007158.html if interested, create (or modify) preorder, minimum $100 pricing [*1] to help support the project, change status to "1stbatch": http://rhombus-tech.net/allwinner_a10/orders/ 18 confirmed already - this *should* be enough, esp. at $100, to proceed. /peace l. [*1] if you can think of a way in which, strategically, you can help us achieve the rhombus tech goals of reaching mass-volume distribution but you cannot afford $100 then please do contact me and we'll see what we can do ok? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDwoE3YcRaXokuBUrAX3pq6GF6+Z-x4wqSfEPCJ6n=3...@mail.gmail.com
Re: Mele doing A1000 (Quad Core A31) and A200 (Dual Core A20) devices for developers
On Sat, Apr 13, 2013 at 11:56 AM, Peter Bauer wrote: > Can you please ask if the offer different cases ? i've passed on the request to them. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDwzoZPBsaoFJZ6BPjhxam7YYQ4GgWajyNExoT=kshd...@mail.gmail.com
Re: [Arm-netbook] Debian GNU/Linux (armhf) on the Hardkernel ODroid-U2
> You may also try https://github.com/ssvb/xf86-video-sunxifb > Despite the poor choice of name, it should work with the ump based > mali400 blobs also on the platforms other than sunxi. yep, works perfectly well. i say perfectly: apparently you still have to recompile the entire xorg server with --disable-somethingorother i think it's eglx. interestingly the damn thing's still 1280x720, which tends to suggest it's definitely the HDMI framebugger^H^H^H^Hffer. firing up on /dev/fb0 (s3cfb) instead of /dev/fb6 (hdmi built-in output) i get a bit more info, that s3cfb's memory is set to a specific size. have to track down what that's all about. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzUhcgn8WSvg+revQ_jdDiMDHDTbm+v2uYKEPFyv+x=y...@mail.gmail.com
Re: [Arm-netbook] Debian GNU/Linux (armhf) on the Hardkernel ODroid-U2
On Fri, Apr 12, 2013 at 1:52 AM, Siarhei Siamashka wrote: > You may also try https://github.com/ssvb/xf86-video-sunxifb > Despite the poor choice of name, it should work with the ump based > mali400 blobs also on the platforms other than sunxi. oh, awesome - i'll try that. i came across it and went "oops, sunxi only" - didn't realise it'd be happy with... ok, thank you. and i'll compile it up ha, actually on the odroid-u2, which is fast enough and i have git on it and it has like a full native toolchain as debian packages, HA, no more cross-compiling for ARM silliness, and no more x86 yaayy! this is great. really great. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedxkuor19q9j_awpobvbmk1v5y_1e03y+5pxeq-t8rx...@mail.gmail.com
Mele doing A1000 (Quad Core A31) and A200 (Dual Core A20) devices for developers
http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-April/007073.html i've been contacted by mele of shenzen out-of-the-blue because it turns out they really appreciated the fact that we used and recommended their hardware with the allwinner a10 processor as a low-cost developer system, it resulted in really quite good sales for them. here's instructions on how people got Debian (armhf) root filesystems onto it, for example: http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/Building_Debian_From_Source_Code_for_Mele/ they're just about to bring out a couple of other systems, one is with the A20 (a drop-in replacement for the A10) which is a dual-core ARM Cortex A7, and the other is a more powerful Quad-Core ARM Cortex A7 with 2gb of RAM. if there's anybody who would be interested in a group buy of these boxes as low-cost debian servers, desktops, freedom box development systems etc. then now's a good time to speak up. i still have yet to find out if the A20 box has SATA, but the A31 one definitely does (how is not clear: the A31 doesn't have SATA as far as i can make out). the only caveat about the A31 system is that it uses the PowerVR proprietary GPU, for which starting the reverse-engineering is still outstanding (the engine's instruction set op codes are known though). but, as a server or if using straight framebuffer, it'll do fine. GPL Source code has already been quotes leaked quotes for both systems so is available publicly; Mele are committed to GPL Compliance so that's ok; i have copies of the stock android kernel and u-boot as well as the buildroot environment if people get _really_ stuck, but you shouldn't. pricing i've yet to find out - they _really_ should not be a great deal. A31 retail products really should not be more than $20 more than A10 retail products. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzQ=aw3m2kxpqdjs1nq4omv3efosv-0qkkbzlhelgv...@mail.gmail.com
Debian GNU/Linux (armhf) on the Hardkernel ODroid-U2
http://lkcl.net/reports/odroid-u2.html this is an install report (successful one!) with full bootstrap instructions on how to get from android to debian GNU/Linux (armhf variant) on an ODroid-U2 device. it's got quirks (the hardware) but the sheer tiny size for something that has 3 USBs and Ethernet is just... i couldn't resist. Software Freedom Caveats: a) i'm deeply unhappy to have learned that Hardkernel have enabled DRM in the bootloader, and require that, if you want to modify u-boot, you must send them the u-boot image and *they* will sign it with their private key. this is deeply unimpressive but at least they will actually sign it... unlike e.g. the fucked-up arrangement with UEFI boot and microsoft and the linux foundation. try asking microsoft "excuse me could you please sign my linux kernel i built" and see how far that gets. regardless of that screw-up-of-an-arrangement, i found that the pre-installed pre-built u-boot did not need modifying so i did not need to contact hardkernel.com: the default parameters of the default pre-built u-boot will look for a kernel on the NAND partition first, followed by looking for one on the SD Card partition. personally i feel this should be the other way round, but hey, it worked. b) the HDMI framebuffer appears to need a proprietary library (as usual) to compile up the X11 driver. as this qualifies as a "System Library" and thus is covered by the GPL Exceptions Clauses it's kinda ok, only not really if you know what i mean. i've spoken to libv on #lima and he's got an odroid-x2 which he's just started playing with, and will be getting the mali wrapper library back up-and-running in order to start tackling xorg. anyway: the process didn't need to install android developer tools under debian, and, amazingly, all the compilation was done *native* on the Odroid-U2 itself. all this "cross-compiling" bollocks, that's all out the window. kernel including modules took around 10 to 15 minutes using "make -j6", which is not bad. specifications of the odroid u2, for $85 (!) * Quad-Core 1.7ghz (!) ARM Cortex A9 * 2gb of RAM * 2 USB ports, 1 Micro-USB (OTG) * 1 10/100 Ethernet RJ45 * 1 Micro-HDMI * Micro-SD slot * Optional ($25 for an 8gbyte chip) NAND Flash module (eMMC) * Headphone socket (which i've not been able to get to work yet) limitations found so far: * Ethernet you *must* boot up with the cable plugged in, it looks like auto-detect doesn't work * the HDMI framebuffer is hard-coded in the kernel source to 1280x720 apparently. * the sound chip comes up only with switches, no volumes (!) in alsamixer. * Android's ethernet support is unstable if you push the transfer sizes a bit hard, but Debian seems fine overall conclusion: some quirks but for $85+$25+MicroHDMI cable it's not bad! l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedxafhw9zkhh7qlhsxg4pngjhbegz8m7ziy5k7xbeyi...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
On Mon, Apr 1, 2013 at 9:01 PM, Lennart Sorensen wrote: > On Mon, Apr 01, 2013 at 07:20:44PM +0100, luke.leighton wrote: >> already on the CPU Card. > > Oh yeah. :) > >> ... unless converted. i'm dithering as to whether to add a TFP410 >> [1] onto the mini-engineering board, to convert RGB/TTL into DVI (aka >> HDMI without the encryption and audio). that would give a 2nd video >> output. > > What resolution output is supported? of the TFP410? err well the datasheet says max rate is 165mhz, which can do 1080p and WUXGA apparently. 1920*1200*60 = 138.24mhz, that's excluding syncs, so i *think* you're covered l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzdXDK5VCvfLXg_S0o3XGm79A_i=+xa2nkqasj++ht...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
On Mon, Apr 1, 2013 at 7:05 PM, Lennart Sorensen wrote: > I would just want something with an HDMI port. already on the CPU Card. > LCD has no interest at all. ... unless converted. i'm dithering as to whether to add a TFP410 [1] onto the mini-engineering board, to convert RGB/TTL into DVI (aka HDMI without the encryption and audio). that would give a 2nd video output. l. [1] http://www.ti.com/product/tfp410 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDxHq3EC3sFetKO5e495+1Q2v+6zu42SgSXCA1UxOCm8=w...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
On Mon, Apr 1, 2013 at 5:15 PM, Lennart Sorensen wrote: > On Sun, Mar 31, 2013 at 12:07:34AM +0000, luke.leighton wrote: >> ok lennart, RS232 added. even with some level-shifters to put it up >> to proper voltages and protect the CPU at the same time, how's that >> for service? :) > > A real 232 port? Yay! yes lennart - specially for you. just don't ask for RTS/CTS ok? :) > Looks really neat. Are there any boards to plug the EOMA-68 card into > available? the "flying squirrel" should, all going well, be done first boards in about 2-3 weeks. a few parts to chase down from suppliers for that. have to make a custom cable for the LCD for example (argh). btw "flying squirrel" is the codename for the next version of the KDE "Vivaldi Spark" tablet. once we have that out, doing alternative versions (engineering board etc) should be on a really fast turnaround, as they're all variants on the same theme. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzR4Dg1mh2R7+-Eu11zTiBT6D=tdmlfm89dedivptl...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
On Wed, Feb 27, 2013 at 3:50 PM, Lennart Sorensen wrote: > On Wed, Feb 27, 2013 at 12:51:13AM +0000, luke.leighton wrote: >> http://rhombus-tech.net/freescale/iMX6/news/ > Well for a board to be interesting to me it has to have: > > SATA (which you have) > > Ethernet (which you have) > > serial console (in case things go wrong and nothing else works. FTDI USB > serial interface is fine, which many systems have, often including JTAG > as well on the same USB connection.) ok lennart, RS232 added. even with some level-shifters to put it up to proper voltages and protect the CPU at the same time, how's that for service? :) btw the reason for the sudden focus is because it turns out that the etna_viv project [*1] actually has something like... working. that puts the iMX6 processor family - which is modern, current, affordable and good value for money - at the top of a VERY short list as far as FSF-Endorseability is concerned. i was working on an ingenic jz4760 board (without realising that it has a GC200 2D GPU argh) and had to do a mad rush to find out if the GC200 had been reverse-engineered and found that the iMX6's 3D GPU has been done! the team (ok - one person, who could really use some help) are currently working on gallium3d integration [*2] anyway - some more lovely pictures here [*3]. anyone with actual experience in PCB design will probably be cringing at the slow pace as well as the mistakes being made - that being the case please do speak up! the files are available for you to review. l. > 2GB ram would be nice, 1GB absolute minimum. More is nice too. > > HDMI is nice to have (which you have). > > I know the iMX53 boots from SD. Not sure what the iMX6 boots from. > As long as I can use SATA for my filesystem and only have to put the > boot loader somewhere (although on SATA would be by far the most ideal), > then NAND flash is of no interest what so ever. > > -- > Len Sorensen [*1] https://github.com/imx6-dongle/wiki/wiki [*2] https://blog.visucore.com/2013/3/29/etnaviv-status-update-2 [*3] http://rhombus-tech.net/freescale/iMX6/news/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedy5+bx+kdsuicu43e7m9hzrnphrr-92jjagp32ou3o...@mail.gmail.com
Re: Bug#648325: Fwd: Bug#648325: dreamplug breakage
On Wed, Feb 13, 2013 at 11:43 PM, Marco d'Itri wrote: > On Feb 14, "luke.leighton" wrote: > >> which unfortunately doesn't help anyone who has a dreamplug which >> comes shipped as standard with a 2.6.32 <= .35 kernel. especially on > Not a showstopper, look at check_kernel_features() in preinst. > IIRC I can just add accept4 as well to the list there. that'd be fantastic. i'm in the clear, now (having found a 3.0.4 pre-built kernel where WIFI works), but for other people who may stumble into this it would make their lives a lot easier. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedyuocww-pzh8z7jc_uqre1ievnc8pmtp29vkc2+z5s...@mail.gmail.com
Re: Fwd: Bug#648325: dreamplug breakage
On Wed, Feb 13, 2013 at 11:37 PM, Steev Klimaszewski wrote: > Adding in the accept4 syscalls isn't hard at all. They were added in > 2.6.32, they just weren't wired up until 2.6.36 (for arm) - Eudev handles a > kernel that doesn't have accept4, udev claims it needs something newer than > 2.6.32, if you add the accept4 wiring up, you can just edit the udev check > for kver-min. Wiring it up takes like 3 lines change in the kernel - this > is what I did for the efikamx "linux-legacy" kernel - > https://github.com/genesi/linux-legacy/commit/a84fac75f38de592e530a2f9f982d7aafec6c288 steev: apologies, but you're not listening - or i'm not making myself clear. 1) dreamplugs come shipped with a 2.6.32 kernel as standard. 2) it is not acceptable to assume that everyone can - or will - upgrade the kernel. i managed it, but it is not reasonable to expect that everyone wishes to risk breaking their device, especially given that performing a "stock" upgrade by following standard instructions found online actually cuts you off from WIFI access. is that any clearer? so, thank you for saying "you should just upgrade the kernel" but it is not as simple as that for many people. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedy_oveo3rbpk66qzuokvdf+3pna2s9ryhdhrcsr7l0...@mail.gmail.com
Re: Fwd: Bug#648325: dreamplug breakage
On Wed, Feb 13, 2013 at 5:11 PM, Arnaud Patard wrote: > "luke.leighton" writes: > >> ok thanks marco. does anyone know what this is referring to? would >> it be the accept4 syscall as shown in dmitri's patch: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=68;filename=udev-182.patch;att=2;bug=648325 > > according to git accept4 has been added into 2.6.36 and according to the > squeeze changelog, it has been added into the 2.6.32-35 kernel. which unfortunately doesn't help anyone who has a dreamplug which comes shipped as standard with a 2.6.32 <= .35 kernel. especially on learning that the default shipped kernel just works and on learning of this dog's dinner mess don't want to go anywhere near a kernel upgrade. >> >> this is a long-standing issue, it would be good to have it sorted out. > > If you're running debian kernels (the 3.2 from wheezy or any kernel > newer than 2.6.32-35 on squeeze), it should already be fine. If you're > running any other kernel, I don't see how it can be handled. it would seem that udev would have to dynamically work out "do i have the accept4 function call, if so use it, if not then do what was being done previously". or... just don't use accept4 at all. > At least > disabling the accept4 syscall for every kernels doesn't seem a good > idea. i can't pretend to know what accept4 does, so can't say. >> i had to track down a suitable replacement kernel plus the >> installation instructions, of course it's not a kernel from debian, >> and the recommended one of course wifi didn't work. i ended up here: >> http://www.spinifex.com.au/plugs/dphowtowificl.html > > off-topic (it's not related to udev): if the wifi is not working, please > check if it's working with newer kernels it's not. the exact reason's not clear yet. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedwvmxqti2nlgwzp28nwqesymqj_n50d4gjf9h37zsk...@mail.gmail.com
Fwd: Bug#648325: dreamplug breakage
ok thanks marco. does anyone know what this is referring to? would it be the accept4 syscall as shown in dmitri's patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=68;filename=udev-182.patch;att=2;bug=648325 this is a long-standing issue, it would be good to have it sorted out. i had to track down a suitable replacement kernel plus the installation instructions, of course it's not a kernel from debian, and the recommended one of course wifi didn't work. i ended up here: http://www.spinifex.com.au/plugs/dphowtowificl.html l. -- Forwarded message -- From: Marco d'Itri Date: Wed, Feb 13, 2013 at 10:09 AM Subject: Re: Bug#648325: dreamplug breakage To: "luke.leighton" , 648...@bugs.debian.org Cc: Joey Hess On Feb 13, "luke.leighton" wrote: > cut it, because even if they "solved" the problem by "fixing" the > kernel it would still not actually result in anyone making the > immediate decision to upgrade the kernel on their embedded devices. This is why the ARM porters need to tell me which kernel version has the syscall so I can make udev refuse to install if it is not present (as usual). -- ciao, Marco signature.asc Description: PGP signature
Re: How about SAN with ARM?
On 10/25/12, Muun Dahweed wrote: > Hi again and thanks for writing. > I got pretty busy and procrastinated to reply. > Please forgive me. eyy, nothing to forgive sah: this is the internet, you're allowed to do whatever you feel! >> the nice thing about this is that web server farms already recognise >> and deploy the concept of round-robin DNS or HTTP proxy redirection in >> order to farm out the queries to individual web front-ends. > Over my head. Sorry. it's just another way of making use of several small computers to appear like it's one big one, you're talking about file storage and i was just saying it can be done [the parallelism] with certain kinds of simplistic web serving as well, that's all. >> i'm intrigued about the NDAS idea though. i looked up NDAS, there's >> a company called ximeta - they apparently released GPL linux kernel >> drivers for their proprietary protocol, but code.ximeta.com has been >> taken offline, since. > The technology was bought last year. And the new owner opens the > sources. Now it moves even to git hub and aims for submission to Linux > driver staging. superb! do you have a link at all? > However, as far as I know, the advent of the "Clouwd" > also put a kibosh on the home user personal need for storage, and the > hardware in the home seems a little less popular for now. > It is hard to know if it will change. This is why I made this inquiry. well, my take on this is as follows: a) the average intelligent debian/unix user/developer is sufficiently security-conscious that they're pretty deeply unimpressed with "da clowd". b) i'm speaking with a friend of mine for example who submitted some comments to gov.uk and was *really* unimpressed when he found that the IP address of the "clowd" service being used to store his responses was in the USA. c) bringing these two together, it's easy to conclude that the average intelligent debian/unix user/developer will still need or otherwise feel obligated to work on *secure* "clowd" computing, if not for other people then for themselves. > As for my specific problem. I could not find an cloud system readily > working with NDAS from my debian Sheevaplug. When I did "apt-cache > search cloud" there was not much to use. :) > I started on this when I saw one other NAS project running Greyhole, > from an ARM computer which seemed like a good match for many NetDISKs on > the lan, all connected to a single server and used as as pool with > redundancy via SAMBA. yeah i remember, now, that the SMB protocol as modified by microsoft has its own version of DFS - it has had, for what 18 years? it'd be interesting to know if samba actually supports that or if greyhold did something different. > However, it looks like that Arm based side was dropped. eurgh. > They are still going on Ubuntu for 86's though. well, that means it's still possible to compile up the packages yourself. have you ever done that before? also are the packages submitted to debian already? if not you can use "reportbug" to submit them. if they're available for ubuntu already then it'll be much easier for a new maintainer to pick up, they use the same packaging files after all. > That's a summary of my status. Thanks again for you encouraging words. I > will keep going, even though if only a slim chance. yeah, go for it, if it's useful to you. if not, please find something else, that's all i can say! :) l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedxl35px3oa9k7xb2wp0+szq+z0svxvjt1yzg97ekvg...@mail.gmail.com
