From owner-freebsd-arm@freebsd.org Sun Jul 31 01:52:51 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D10D3BA251B for ; Sun, 31 Jul 2016 01:52:51 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8982B169D for ; Sun, 31 Jul 2016 01:52:51 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x22b.google.com with SMTP id 52so87747197qtq.3 for ; Sat, 30 Jul 2016 18:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=spqewbZRH8jmDpZeLCCe1vq0c6YD+jkUvL7TLiXyP24=; b=cp9koNwDyzvUdmCESwV5z9fBpxGNPX6tdTEj683Wx5G93e3UPXRtoZat8r5ray+6QH DYiWY4ZA6pIhG1cUeSg5W/9kLqGU8a/cJutpelgFK5u514c+2FuqrgyYB4KQwUdzfHvL bXxv3k0naa8rugIzJpgMUJ3lBuCH/vQbu4Knc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=spqewbZRH8jmDpZeLCCe1vq0c6YD+jkUvL7TLiXyP24=; b=dfiW8objfwsydFbjbOlAloMMVidLCdc9jRLSYJMY9duHeNb6Pch0SROiYA02gFOrBy Deqx5AM5GXyv2y5nWZh9UZz3HkJhUjSsCfju+h0OwXaUvXG5eZqDNvBaGbJBCJI0PrTM rMa9z1zYOQCFa5LvoO1uSoTHJyfREGFeqq7Sx3gPCyxVwN9cFqWC/bw0PZ0dUa54u7JS uyVlTftVvhVPvhjgp5Xep7e2KBpADmRwlXzS4/njhbWCVMVE3hyfe1n9W4rzYH2QbMdM xyGxCWO5LcedL4VQQMZAZ/r4H5FxDQ0WWeQQnKN1KpVGBnENazGRr5VY46R4j8sooEDU 1T2Q== X-Gm-Message-State: AEkoouvFKsu+KSonsEBRpN22+wkmOmD7vbcLfXtoqqGNaXJXdrO1uOy+AT1+u4KyT+IYMg== X-Received: by 10.200.38.107 with SMTP id v40mr78732248qtv.76.1469929970222; Sat, 30 Jul 2016 18:52:50 -0700 (PDT) Received: from [192.168.0.14] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id k8sm13916366qke.39.2016.07.30.18.52.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jul 2016 18:52:49 -0700 (PDT) To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: How to create a armv6hf poudriere jail? Message-ID: <9420a1bc-4b77-0cc7-5f1a-37686ab634ab@bsd.com.br> Date: Sat, 30 Jul 2016 22:52:42 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 01:52:51 -0000 Dears Reading https://wiki.freebsd.org/FreeBSD/arm/crossbuild I found this: "The armv6 architecture is being deprecated in favor of armv6hf, which gives better floating point performance." So, I want create a pouderiere jail to cross build packages for my beaglebone black. So I type this command: poudriere jail -x -c -j 110-armv6hf -a arm.armv6hf -m svn -v 11.0-BETA3@303469 I got: [00:00:00] ====>> Cross-building ports for arm.armv6hf on amd64 requires QEMU [00:00:00] ====>> Error: You need to setup an emulator with binmiscctl(8) for armv6hf Reading binmiscctl I do not found a option to armv6hf. So how can I do to create a jail and build ports with support to hardware float point in arm? Thanks a lot []'s -Otacilio From owner-freebsd-arm@freebsd.org Sun Jul 31 06:11:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8997BA9C0E; Sun, 31 Jul 2016 06:11:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA55011EB; Sun, 31 Jul 2016 06:11:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6V6BTAl015001 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Jul 2016 23:11:30 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> Date: Sat, 30 Jul 2016 23:11:29 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <579CF7C8.1040302@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------B749752E283B3662897D27B5" X-Sonic-CAuth: UmFuZG9tSVY7JnB2hp4xwcXi2+33i82Up9sMkb7R78poh7TNRC/sop5gnkeK+TCcQg5Jo5M5noycmkDqPWgzI7KwZOyRBCsx2IhbssMPEeY= X-Sonic-ID: C;wl/enuVW5hGIlaDx2xNB0g== M;oJ45n+VW5hGIlaDx2xNB0g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 06:11:39 -0000 This is a multi-part message in MIME format. --------------B749752E283B3662897D27B5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 07/30/16 11:54, Michal Meloun wrote: [snip] > >>>>>> Or: you could skip all of that and use the fully functional mechanism >>>>>> that already exists. >>>>> The problem is, at least from my point of view, that we don't have it. >>>>> The actual MIPS code doesn't work on ARM for numerous reasons. >>>>> This is >>>>> first one -> >>>>> >>>>> https://svnweb.freebsd.org/base/head/sys/powerpc/powerpc/nexus.c?revision=297000&view=markup#l186 >>>>> The pre-r301453 ARM INTRNG doesn't support detached interrupts. >>>>> And r301453 doesn't changed nothing about this. >>>> I'm happy to write whatever code is missing. The ARM implementation of >>>> ofw_bus_map_intr() does seem fairly braindead and should be replaced. >>>> >>>> So here is where I am right now: >>>> - The perceived advantage of the new API seems to be that the mapping >>>> information (interrupt parent, etc.) ends up in a struct resource >>>> instead of in a centralized mapping table >>> True. And, in optimal case, also in RLE. See [1]. >> Your code also has a centralized table (static struct intr_irqsrc >> *irq_sources[NIRQ];), basically the same one, so I'm actually really >> confused on this point. The only actual difference seems to be that >> the firmware interrupt descriptor is stored in the RLE at >> bus_alloc_resource() time instead of in the table at bus enumeration >> time and that the new code requires some extra bus methods. > The irq_sources holds only real interrupts (all interrupts pin from all > interrupts controllers). Your effort is move all 'interrupt description > data' out of INTRNG code - > to RLE (at bus enumeration time) (see [1]) and to struct resource (at > bus_alloc_resource() time). The new bus method is only temporary > shortcut to bypass 11 release. > > But, to be fair, I was hoping it might be necessary. > > [1] This is last missing step in whole patch series and, in optimal > case, it need new filed(s) in RLE structure. So we chose to postpone > discussion about this to time after 11 release. That's a nice idea. I think it will require a big amount of API retooling, though, since we don't use RLEs consistently everywhere in the tree (the PCI code, for example). > >>>> - Additionally, it gives you a better shot at having the PIC online >>>> before the PIC's interrupts are parsed (which is not required, but >>>> nice). >>> Nope, we simply fount that detached pics is very dangerous and not >>> needed. But, if you love it, it can be added as MD extension. >> Dangerous how? I don't "love it"; it's an unfortunate necessity. > Imho, some drivers may rely on correct return code from > bus_alloc_resource() or from bus_setup_intr(). > For example to detect if interrupt exist, or if given interrupt > configuration is supported. These can be decoupled. The thing you need for sure is to be able to assign resources before the PIC attaches. I think you've convinced me that with some care in bus passes, it is possible to postpone the need for bus_alloc_resource() and bus_setup_intr() to succeed until after the PIC[s] have attached in all cases. That will require work, but it's in principle possible. >>>> - Beyond these aesthetic points, there are no concrete examples of new >>>> functionality added by this API, aside from some minor implementation >>>> bugs of the old one on ARM that are easily fixed. >>> Really? Or you just ignore it? >> Which ones? I've been asking for a week and a half now and you have >> responded with some hypothetical examples, all of which either (a) do >> not seem to occur in the real world and (b) were trivially >> implementable with the existing code. >> >>>> - There are, conversely, a number of concrete cases where this new API >>>> would not be able to do the right thing. Some of these can be worked >>>> around or fixed with significant restructuring in the MI parts of the >>>> kernel. >>> And i offer you a fix, without "significant restructuring in the MI >>> parts of the kernel". Unfortunately, you did not want to accept anything >>> other than the old API. >> For one of them, partially. For the others, not so much. For example, >> I have no idea how to implement PCI interrupts (PCIB_ROUTE_INTERRUPT) >> in this framework. I am perfectly happy to accept a new API. What I am >> not perfectly happy to accept is an API that makes it impossible for >> me to support the platforms that I need to support and that, >> simultaneously, doesn't even provide any new capabilities on other >> platforms. > From one of previous mail: > > But again, all what I want in this area is (for me) simple change of > your ofw_bus_map_intr() method to something like: > > enum intr_map_data_type { > INTR_MAP_DATA_OFW, > INTR_MAP_DATA_GPIO, > ... > }; > > int > bus_map_intr(device_t dev, enum intr_map_data_type type, uintptr_t > pic_id, void *config_data, int config_size) > >> The current API is certainly a bit of a hack and I would be pleased to >> see it go; but the replacement needs to be more functional and more >> robust. As far as I can tell, I literally *cannot* move PowerPC over >> to this architecture. > Yes, at this time, I agree. If you can accept enhancement of > (owf_)bus_map_intr() then we can move to next, significantly less > hackish, state. OK, sure. I wrote some code this afternoon (attached) to sketch this. It does not compile or run or anything useful, but it should illustrate the important parts of what I think is an API that should work for everyone. I'm happy to finish it if it looks reasonable -- I may in any case just to replace PowerPC's increasingly teetering intr_machdep.c. The OF part is essentially unchanged from how it currently works: there's a method that you pass the interrupt specifier and interrupt parent to, and it spits back an IRQ that means that combination of things in perpetuity. OFW_BUS_MAP_INTR() in nexus.c, with its current API, can be implemented in terms of it in one line. Whenever the relevant PIC attaches, it is told to use the given IRQ to refer to that opaque bytestring. I've added a set of equivalent functions for ACPI that take the contents of an ACPI interrupt specifier and do the same things. It tries to have the IRQ be human-meaningful, if possible, by matching the ACPI interrupt number. Having separate functions seemed a little cleaner than exposing the enums and unions as part of the KPI, but I'm not wedded to it -- this is just an example. PICs register (and deregister) themselves with either an OF phandle or an ACPI resource string or (god help us) both as needed. The PICs have corresponding methods for interpreting various kinds of interrupt specifiers. Whether it allows bus_alloc_resource(), bus_setup_intr(), etc. to succeed before the PICs are attached is gated on an #ifdef. That can probably be off by default on ARM. A PowerPC version of this code would have to keep it on until various bus drivers are fixed. Here's the general flow: - Parent bus enumerates children, maps IRQs as needed, adds to resource list. The struct resources involved aren't special (just a single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are trivial to implement (and already are implemented, in general, for OF/FDT drivers). - bus_alloc_resource() does nothing special - bus_setup_intr() calls into the PIC and does what is needed, as in r301453 (to within that #ifdef) This should keep all the best pieces of everything: - ACPI and OF are supported together, and easy to extend for other types of mapping technologies without breaking either KBI or KPI (just add new functions) - No APIs change for existing Open Firmware code - The support code can live entirely in machine-dependent directories, with no code changes at all required in kern/ or dev/ofw/ - bus_setup_intr() and friends behave as in r301453 and succeed or fail for real - PCI code is not an issue - No disconnected interrupt state maintained in mapping table (unless the transitional #ifdef is on) and the mapping table content is only larger than r301453 by having a copy of the original interrupt specifier. If and when we manage to fix the kernel APIs to allow non-scalar interrupt specifiers, this should also be easy to gradually transmogrify to support that case since there exists a 1:1 mapping of scalar IRQs to rich data and the control flow would be identical: interrupt specifiers are read at enumeration time and a resulting handle -- struct resource or scalar IRQ -- used afterward to refer to it. Some more comments below. >> The ideal API would be one in which the resource enumeration code >> could assign, instead of numbers, some structured information that >> contains the full firmware specifier (string parent + interrupt pin >> for ACPI, interrupt parent phandle + specifier for device tree, bare >> numbers for simple systems). > Yes, exactly. I am happy that at least we agree on something. The only > difference is that we want triplet specifier> or Which makes perfect sense and is a good idea. >> That seemed, and seems, too invasive. I think we agree on this and >> have chosen to approximate that API in two different ways. > I still think that we found way how we can realize the above idea in > non-invasive way. > From my point of view the solution is: > Put/attach the above triplet to RLE and then copy it (within > bus_resource_attach() to struct resource. > But yes, I understand that I am not able to explain clearly enough. I think we were just talking past eachother somehow. Anyway, my concern about putting this in struct resource * at bus_alloc_resource() time is basically that there are a whole bunch of cases in which (a) it's hard to reverse engineer which interrupt from the device tree (or whatever) was meant to correspond to a particular arbitrary IRQ in an allocation request unless you keep logs and (b) there are a bunch of cases, mostly involving PCI, where interrupt resource allocation doesn't proceed through struct resource * at all, so you pretty much have to keep logs. Once you start keeping logs of which IRQ corresponds to which specifier at the device level, you might as well just do it once in a centralized place. > >> When we designed the interrupt mapping code, we evaluated a large >> number of possible approaches. Something very much like this was one >> of them. It was rejected as being too fragile (it requires resource >> allocation and enumeration to be coupled) and to have too many corner >> cases (the PCI MSI and LSI APIs, for instance). The interrupt mapping >> stuff seemed at the time, and so far still seems, like the least-bad >> approximation to the ideal case: it is essentially that ideal API, in >> that it happens at bus enumeration and involves just assigning the >> firmware specifiers, but with lookup keys to that information stuffed >> into the 32-bit numbers that the rest of the system uses. > The raw PCI (or MSIX) case is relatively simple. The PCI domain uses > raw numbers and it's host-to-pci bridge job to translate raw numbers > from PCI domain to (for example) OFW based resource. > At this point, I'm still not sure about MSI... Right, you can keep a big table in the PCI driver that maps whatever IRQs you are handing out to some richer interrupt specifiers and consult that when you get a bus_alloc_resource() request. Which is basically the approach I'm advocating, except that the table is centralized, which reduces code duplication and fixes a number of weird corner cases where children assign extra interrupts to themselves, etc. and the bus parent has no ability to do something sensible. Please take a look at the attached interface and see if it (or something like it) meets your needs. It meets all of mine, at least, and I think fixes all the things you were concerned about. -Nathan --------------B749752E283B3662897D27B5 Content-Type: text/plain; charset=UTF-8; name="intr.h" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="intr.h" #ifndef _ARM_INTR_H #define _ARM_INTR_H /* Open Firmware-type mappings */ int map_ofw_irq(uint32_t iparent, uint32_t *ispec, size_t icells); void register_pic_ofw(device_t dev, uint32_t phandle); void unregister_pic_ofw(device_t dev); /* ACPI-type mappings */ int map_acpi_irq(const char *provider, int interrupt, uint8_t polarity, uint8_t trigger); void register_pic_acpi(device_t dev, const char *provider); void unregister_pic_acpi(device_t dev); /* PIC interface */ void dispatch_intr(u_int vector, struct trapframe *tf); #endif --------------B749752E283B3662897D27B5 Content-Type: text/plain; charset=UTF-8; name="intr.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="intr.c" /*- * Copyright 2016 Nathan Whitehorn * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD$ */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include static MALLOC_DEFINE(M_INTR, "intr", "interrupt handler data"); struct intr_rec { struct intr_event *event; long *cntp; u_int cntindex; device_t pic; cpuset_t cpu; u_int vector; RB_ENTRY(intr_rec) intr_rec_link; #ifdef ALLOW_LATE_PIC_ATTACH enum intr_trigger trig; enum intr_polarity pol; #endif union { struct { void *ofw_spec; size_t ofw_spec_len; uint32_t ofw_iparent; } ofw_spec; struct { uint8_t acpi_triggering; uint8_t acpi_polarity; uint32_t acpi_intline; const char *acpi_source; } acpi_spec; } ispec; enum { IRQ_TYPE_OFW, IRQ_TYPE_ACPI, IRQ_TYPE_IPI, } ispec_type; }; /* Tree of interrupts: indexes IRQ# (vector) to specifier */ static int intr_rec_compare(struct intr_rec *a, struct intr_rec *b); static RB_HEAD(intr_rec_tree, intr_rec) intr_list = RB_INITIALIZER(&intr_list); RB_GENERATE_STATIC(intr_rec_tree, intr_rec, intr_rec_link, intr_rec_compare); static struct rmlock intr_list_lock; /* Maps of PICs by ID to device_t */ struct ofw_pic { LIST_ENTRY(ofw_pic) ofw_pic_link; uint32_t phandle; device_t dev; }; static LIST_HEAD(ofw_pic_head, ofw_pic) ofw_pic_list = LIST_HEAD_INITIALIZER(&ofw_pic_list); struct acpi_pic { LIST_ENTRY(acpi_pic) acpi_pic_link; const char *acpi_source; device_t dev; }; static LIST_HEAD(acpi_pic_head, acpi_pic) acpi_pic_list = LIST_HEAD_INITIALIZER(&acpi_pic_list); static struct mtx pic_list_lock; device_t root_pic = NULL; /* * Locking semantics: * - intr_list_lock is held for reading whenever an interrupt is being * issued. No non-atomic fields can be updated when held for reading. * - intr_list_lock is held for writing whenever non-atomic fields need * to be changed. * - When entries are added to or deleted from the table, the intr_list_lock * must be held for writing *and* pic_list_lock must be held. * - pic_list_lock is outer to intr_list_lock */ static void intr_init(void *dummy __unused) { rm_init(&intr_list_lock, "intr list"); mtx_init(&pic_list_lock, "PIC list", NULL, MTX_DEF); } SYSINIT(intr_init, SI_SUB_INTR, SI_ORDER_FIRST, intr_init, NULL); /* Utility functions */ static struct intr_rec * allocate_irq(void) { struct intr_rec *rec = malloc(sizeof(struct intr_rec), M_INTR, M_ZERO | M_WAITOK); #ifdef SMP rec->cpu = all_cpus; #else CPU_SETOF(0, &rec->cpu); #endif #ifdef ALLOW_LATE_PIC_ATTACH rec->trig = INTR_TRIGGER_CONFORM; rec->pol = INTR_POLARITY_CONFORM; #endif return rec; } static int insert_irq(struct intr_rec *rec) { struct intr_rec *existing = NULL; rm_assert(&intr_list_lock, RA_WLOCKED); /* Allow code to suggest a vector ID. Honor if possible. */ if (rec->vector != 0) { existing = RB_FIND(intr_rec_tree, &intr_list, rec); if (existing == NULL) goto out; } /* Otherwise, use min(100, max_irq + 1) */ existing = RB_MAX(intr_rec_tree, &intr_list); if (existing == NULL) rec->vector = 100; else rec->vector = min(existing->vector + 1, 100); out: RB_INSERT(intr_rec_tree, &intr_list, rec); return (rec->vector); } static struct intr_rec * find_irq(u_int vector) { struct intr_rec *i, tmp; /* * Note on locking: we don't destroy any IRQ mappings once made * (just reuse them if asked for again), so below code is safe */ tmp.vec = vector; rm_rlock(&intr_list_lock); i = RB_FIND(intr_rec_tree, &intr_list, &tmp); rm_runlock(&intr_list_lock); return (i); } /* Open Firmware-type mappings */ int map_ofw_irq(uint32_t iparent, uint32_t *ispec, size_t icells) { struct intr_rec *existing, *newintr; struct ofw_pic *pic; int irq; /* * Allocate early for locking reasons. Allocation is the usual path * anyway. */ newintr = allocate_irq(); newintr->ispec_type = IRQ_TYPE_OFW; newintr->ispec.ofw_spec.ofw_spec_len = sizeof(ispec[0])*icells; newintr->ispec.ofw_spec.ofw_spec = malloc(sizeof(ispec[0])*icells, M_INTR, M_WAITOK); memcpy(newintr->ispec.ofw_spec.ofw_spec, ispec, newintr->ispec.ofw_spec.ofw_spec_len); newintr->ispec.ofw_iparent = iparent; newintr->vector = ispec[0]; /* Usually the interrupt pin. */ mtx_lock(&pic_list_lock); LIST_FOREACH(pic, &ofw_pic_list, ofw_pic_link) { if (pic->phandle == iparent) break; } if (pic != NULL) newintr->pic = pic->dev; if (pic == NULL) panic("Open Firmware PIC %#d not registered", iparent); rm_wlock(&intr_list_lock); existing = NULL; RB_FOREACH(existing, intr_rec_tree, &intr_list) { if (existing->ispec_type != IRQ_TYPE_OFW) continue; if (existing->ispec.ofw_spec.ofw_iparent != iparent) continue; if (existing->ispec.ofw_spec.ofw_spec_len != newintr->ispec.ofw_spec.ofw_spec_len) continue; if (memcmp(existing->ispec.ofw_spec, ispec, newintr->ispec.ofw_spec_len) == 0) break; } if (existing == NULL) irq = insert_irq(newintr); else irq = existing->vector; rm_wunlock(&intr_list_lock); if (existing != NULL) { /* Already had one */ free(newintr->ofw_spec.ofw_spec); free(newintr, M_INTR); } if (pic != NULL && !existing) PIC_MAP_OFW(pic->dev, irq, ispec, icells); mtx_unlock(&pic_list_lock); return (irq); } void register_pic_ofw(device_t dev, uint32_t phandle) { struct intr_rec *existing; struct ofw_pic *pic; pic = malloc(sizeof(*pic), M_INTR, M_WAITOK); pic->dev = dev; pic->phandle = phandle; mtx_lock(&pic_list_lock); LIST_INSERT_HEAD(pic, &ofw_pic_list, ofw_pic_link); begin_intr_search: /* * Associate any previously-mapped interrupts on this PIC with this * PIC. */ rm_wlock(&intr_list_lock); RB_FOREACH(existing, intr_rec_tree, &intr_list) { if (existing->ispec_type != IRQ_TYPE_OFW) continue; if (existing->ispec.ofw_spec.ofw_iparent == iparent && existing->pic == NULL) { existing->pic = dev; rm_wunlock(&intr_list_lock); /* PIC lock still held */ PIC_MAP_OFW(dev, existing->vec, existing->ispec.ofw_spec.ofw_ispec, existing->ispec.ofw_spec.ofw_icells); #ifdef ALLOW_LATE_PIC_ATTACH PIC_CONFIG(dev, existing->vec, existing->trig, existing->pol); #endif goto begin_intr_search; } } rm_wunlock(&intr_list_lock); mtx_unlock(&pic_list_lock); } void unregister_pic_ofw(device_t dev) { struct intr_rec *existing; struct ofw_pic *pic; mtx_lock(&pic_list_lock); LIST_FOREACH(pic, &ofw_pic_list, ofw_pic_link) { if (pic->dev == dev) break; } if (pic != NULL) { LIST_REMOVE(pic, ofw_pic_link); free(pic, M_INTR); } mtx_unlock(&pic_list_lock); rm_rlock(&intr_list_lock); RB_FOREACH(existing, intr_rec_tree, &intr_list) { if (existing->pic == dev) panic("Removing PIC with existing interrupt"); } rm_runlock(&intr_list_lock); } /* ACPI-type mappings */ int map_acpi_irq(const char *provider, int interrupt, uint8_t polarity, uint8_t trigger) { struct intr_rec *existing, *newintr; char *newprov; struct acpi_pic *pic; int irq; /* * Allocate early for locking reasons. Allocation is the usual path * anyway. */ newintr = allocate_irq(); newintr->ispec_type = IRQ_TYPE_ACPI; newintr->ispec.acpi_spec.acpi_triggering = trigger; newintr->ispec.acpi_spec.acpi_polarity = polarity; newintr->ispec.acpi_spec.acpi_intline = interrupt; newprov = malloc(strlen(provider) + 1, M_INTR, M_WAITOK); strcpy(newprov, provider); newintr->ispec.acpi_spec.acpi_source = newprov; newintr->vector = interrupt; /* Try for this to make dmesg nice */ mtx_lock(&pic_list_lock); LIST_FOREACH(pic, &acpi_pic_list, acpi_pic_link) { if (strcmp(pic->acpi_spec.acpi_source, provider) == 0) break; } if (pic != NULL) newintr->pic = pic->dev; if (pic == NULL) panic("ACPI PIC %s not registered", provider); rm_wlock(&intr_list_lock); existing = NULL; RB_FOREACH(existing, intr_rec_tree, &intr_list) { if (existing->ispec_type != IRQ_TYPE_ACPI) continue; if (strcmp(existing->ispec.acpi_spec.acpi_source, provider) != 0) continue; if (existing->ispec.acpi_spec.acpi_intline == interrupt) break; } if (existing == NULL) irq = insert_irq(newintr); else irq = existing->vector; rm_wunlock(&intr_list_lock); if (existing != NULL) { /* Already had one */ free(newintr->acpi_spec.acpi_source); free(newintr, M_INTR); } if (pic != NULL && !existing) PIC_MAP_ACPI(pic->dev, irq, interrupt, polarity, trigger); mtx_unlock(&pic_list_lock); return (irq); } void register_pic_acpi(device_t dev, const char *provider) { struct intr_rec *existing; struct acpi_pic *pic; char *newprov; pic = malloc(sizeof(*pic), M_INTR, M_WAITOK); pic->dev = dev; newprov = malloc(strlen(provider) + 1, M_INTR, M_WAITOK); strcpy(newprov, provider) pic->acpi_source = newprov; mtx_lock(&pic_list_lock); LIST_INSERT_HEAD(pic, &acpi_pic_list, acpi_pic_link); mtx_unlock(&pic_list_lock); begin_intr_search: /* * Associate any previously-mapped interrupts on this PIC with this * PIC. */ rm_wlock(&intr_list_lock); RB_FOREACH(existing, intr_rec_tree, &intr_list) { if (existing->ispec_type != IRQ_TYPE_ACPI) continue; if (strcmp(existing->ispec.acpi_spec.acpi_source, provider) == 0 && existing->pic == NULL) { existing->pic = dev; rm_wunlock(&intr_list_lock); PIC_MAP_ACPI(dev, existing->vec, existing->ispec.acpi_spec.acpi_intline, existing->ispec.acpi_spec.acpi_polarity, existing->ispec.acpi_spec.acpi_triggering); #ifdef ALLOW_LATE_PIC_ATTACH PIC_CONFIG(dev, existing->vec, existing->trig, existing->pol); #endif goto begin_intr_search; } } rm_wunlock(&intr_list_lock); } void unregister_pic_acpi(device_t dev) { struct intr_rec *existing; struct acpi_pic *pic; mtx_lock(&pic_list_lock); LIST_FOREACH(pic, &acpi_pic_list, acpi_pic_link) { if (pic->dev == dev) break; } if (pic != NULL) { LIST_REMOVE(pic, acpi_pic_link); free(pic->acpi_source, M_INTR); free(pic, M_INTR); } mtx_unlock(&pic_list_lock); rm_rlock(&intr_list_lock); RB_FOREACH(existing, intr_rec_tree, &intr_list) { if (existing->pic == dev) panic("Removing PIC with existing interrupt"); } rm_runlock(&intr_list_lock); } void dispatch_intr(u_int vector, struct trapframe *tf) { struct intr_rec *i; struct intr_event *ie; i = find_irq(vector); KASSERT(i != NULL, ("Dispatching unmapped vector %d", vector)); ie = i->event; KASSERT(ie != NULL, ("%s: interrupt without an event", __func__)) intr_event_handle(ie, tf); /* XXX strays? */ } --------------B749752E283B3662897D27B5-- From owner-freebsd-arm@freebsd.org Sun Jul 31 07:36:59 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A3D6BAA4BE for ; Sun, 31 Jul 2016 07:36:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 006FD144E for ; Sun, 31 Jul 2016 07:36:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.81.13]) by kabab.cs.huji.ac.il with esmtp id 1bTlIk-000GMM-C8; Sun, 31 Jul 2016 10:36:46 +0300 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: How to create a armv6hf poudriere jail? From: Daniel Braniss In-Reply-To: <9420a1bc-4b77-0cc7-5f1a-37686ab634ab@bsd.com.br> Date: Sun, 31 Jul 2016 10:36:48 +0300 Cc: "freebsd-arm@freebsd.org" Message-Id: References: <9420a1bc-4b77-0cc7-5f1a-37686ab634ab@bsd.com.br> To: =?utf-8?Q?Otac=C3=ADlio?= X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 07:36:59 -0000 hi, according to: https://wiki.freebsd.org/FreeBSD/arm/hardabi = the armv6hf was a temporary thing, so maybe some clarification is = needed? > On 31 Jul 2016, at 04:52, Otac=C3=ADlio = wrote: >=20 > Dears >=20 > Reading https://wiki.freebsd.org/FreeBSD/arm/crossbuild I found this: >=20 > "The armv6 architecture is being deprecated in favor of armv6hf, which = gives better floating point performance." >=20 > So, I want create a pouderiere jail to cross build packages for my = beaglebone black. So I type this command: >=20 > poudriere jail -x -c -j 110-armv6hf -a arm.armv6hf -m svn -v = 11.0-BETA3@303469 >=20 > I got: >=20 > [00:00:00] =3D=3D=3D=3D>> Cross-building ports for arm.armv6hf on = amd64 requires QEMU > [00:00:00] =3D=3D=3D=3D>> Error: You need to setup an emulator with = binmiscctl(8) for armv6hf >=20 > Reading binmiscctl I do not found a option to armv6hf. So how can I do = to create a jail and build ports with support to hardware float point in = arm? >=20 > Thanks a lot >=20 > []'s >=20 > -Otacilio >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Jul 31 08:18:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 830CCBAAE48 for ; Sun, 31 Jul 2016 08:18:58 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 192F8169F for ; Sun, 31 Jul 2016 08:18:58 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id i5so203820202wmg.0 for ; Sun, 31 Jul 2016 01:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=7rg4KRrJx/x17fvHpZsQr0f8koYgy44ZhOk07vjh1ok=; b=nXhryBKk23VtdEVUr8mGnkBjqx/Ee1LoWqDcDu7VxgoP7C4EttOg8bybXPmceov9sX 3u1RKppWER5QnqMZv/nomDTRd5GmXN2azwmR1jVj7raHFsbaLGCoECvvcXIYsDYCk25c pweTbr1uPjYZ0+bo8TfusU6NYU3VZKry/R3ciKSz6FG/iQcsPj5gzp+l5qZ5qVTxAbDz I3Ud2JM6WVnloD8ARvubD8soB8KFM5tQvYcWckC8m4w1kw05x/2zFuUhPZQkNFRskWBy k0ptyt0+cH7PJDL5qgJcX7opz0lxtSHXRPN6HfW81Yg65i0xZZmLy3hZfcjLM9tUffj3 kHww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=7rg4KRrJx/x17fvHpZsQr0f8koYgy44ZhOk07vjh1ok=; b=UiDyRuAAwFshlQF44Aj8YMMRBOdHs2cZ9inX1V3Z+Kyf1Q7hxJ9Vq5DD6i6u4InN+0 N4ZannZbG/DMwPPSSmQ4bTjKiSrKCo29T5Aylf0GF69ezCtbce3Fbg5mqF1m0UPuSx6o g6cgTxm9d7Ad7cTbssprMHbx6wMdX4BaE8MeGpEbUzdKZvJbOFKeAFd2R2ckV6wKeok3 U74uYkml4NvyxlpzB/uA61aQ6LBaIxeM8fladdsk3i2cW9wWsVY0WqQfg8HwrjkS+fbj TKRchDfKdprOwUznMVPC1vWDlJev/QBywOIrTI1SBx6JrF2TbChEgGet49FVFozqw9Gy sjAg== X-Gm-Message-State: AEkooutPzVE531KyldLpabzQTjmRmat4PUy3+aZhKSyQ665DKOkV/2hQSd70QwGW2lw+WQ== X-Received: by 10.194.221.232 with SMTP id qh8mr45827866wjc.117.1469953135884; Sun, 31 Jul 2016 01:18:55 -0700 (PDT) Received: from [192.168.0.5] ([81.56.235.196]) by smtp.gmail.com with ESMTPSA id p4sm24535546wjq.27.2016.07.31.01.18.54 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 31 Jul 2016 01:18:54 -0700 (PDT) From: Sylvain Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: sonewconn: pcb 0xc442c9c0: Listen queue overflow: 193 already in queue awaiting acceptance (19 occurrences) Message-Id: <350A9EA6-2812-4882-B39B-1F32805AC9C8@gmail.com> Date: Sun, 31 Jul 2016 10:18:53 +0200 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 08:18:58 -0000 Hello, I have many messages like this one: sonewconn: pcb 0xc442c9c0: Listen queue overflow: 193 already in queue = awaiting acceptance (18 occurrences) in my dmesg log, on a raspberry pi 2. I=E2=80=99m pretty sure the culprit is my bittorrent client.=20 I suppose I can=20 a) tune my transmission client not to accept so many connections b) tune my kernel to have a bigger listen queue I=E2=80=99m writing here in case someone could point for me the right = sysctl I need to tune for case b) Thanks! Sylvain= From owner-freebsd-arm@freebsd.org Sun Jul 31 10:21:53 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF84ABA9DF3 for ; Sun, 31 Jul 2016 10:21:53 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9376B11B2 for ; Sun, 31 Jul 2016 10:21:53 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-io0-x236.google.com with SMTP id q83so164643590iod.1 for ; Sun, 31 Jul 2016 03:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nBhLgqCEvXchB0Bj4f97JQs4XSUKUfdeSHu4xrM2g6M=; b=eB/mZkjvwDW7abKPFHU1IvSQjLfB/FcXQ/wDcUk2wTh1UptPN83A7cZB/XqGu4tbEJ XlF17kDS3Z4dJuvUbdqLD2/6iGKYQMYktqI6Ocmnjbk0fX2+3IH5aXAs7SQW+BaeoNTv TGf1Dntjyz/kAwcuNIT56y9/V++Qhwr2FrbJk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nBhLgqCEvXchB0Bj4f97JQs4XSUKUfdeSHu4xrM2g6M=; b=J5YySAe8kVJEwQDDvS+fQaLh+woZiUthvHy1UkpMoT56jITGzGo1zRzsYKdaEoSl4t kJXhFkWyvlIsC3S7WJzj8wdd46kkNHxxcm5UUMcIO9m8f8yf+9KnOALZC0IQyPl/ApY0 79+U4qHQF8oKSYf8Vpwqd2IBudbdGsWyOP8waIbl175x/vLzWoFfimDW+xyw+ItpHDXV gWnsxTEQzG3baANNq3kUpi3HoEEbQwr85YzKgsqNqLGIm9NgBe5qMtkWALhib+I1VhEN cW8VPbR1J+TtJJjyQVRQuoDaZzgFFY/1hB+gkyBP37TLBwnPROt52RnO7x2wqp/nNl0J U1HA== X-Gm-Message-State: AEkoout/2k8Xpjw47mZl+/n7QtUkL4QzyftjDGbHWRxiiokVYmjfo3pZ0KTHo2atu+/ZJOfanlmjhN8OX9O6uQ== X-Received: by 10.107.147.138 with SMTP id v132mr52322148iod.27.1469960512440; Sun, 31 Jul 2016 03:21:52 -0700 (PDT) MIME-Version: 1.0 References: <9420a1bc-4b77-0cc7-5f1a-37686ab634ab@bsd.com.br> In-Reply-To: From: =?UTF-8?Q?Otac=C3=ADlio_de_Ara=C3=BAjo_Ramos_Neto?= Date: Sun, 31 Jul 2016 10:21:42 +0000 Message-ID: Subject: Re: How to create a armv6hf poudriere jail? To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 10:21:53 -0000 Em dom, 31 de jul de 2016 04:36, Daniel Braniss escreveu: > hi, > according to: > https://wiki.freebsd.org/FreeBSD/arm/hardabi > > the armv6hf was a temporary thing, so maybe some clarification is needed= ? > > No. Thanks a lot []'s -Otacilio > > On 31 Jul 2016, at 04:52, Otac=C3=ADlio wrote: > > Dears > > Reading https://wiki.freebsd.org/FreeBSD/arm/crossbuild I found this: > > "The armv6 architecture is being deprecated in favor of armv6hf, which > gives better floating point performance." > > So, I want create a pouderiere jail to cross build packages for my > beaglebone black. So I type this command: > > poudriere jail -x -c -j 110-armv6hf -a arm.armv6hf -m svn -v > 11.0-BETA3@303469 > > I got: > > [00:00:00] =3D=3D=3D=3D>> Cross-building ports for arm.armv6hf on amd64 r= equires > QEMU > [00:00:00] =3D=3D=3D=3D>> Error: You need to setup an emulator with binmi= scctl(8) > for armv6hf > > Reading binmiscctl I do not found a option to armv6hf. So how can I do to > create a jail and build ports with support to hardware float point in arm= ? > > Thanks a lot > > []'s > > -Otacilio > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > From owner-freebsd-arm@freebsd.org Sun Jul 31 11:19:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A2F2BA10C9 for ; Sun, 31 Jul 2016 11:19:04 +0000 (UTC) (envelope-from benny.goemans@belgacom.net) Received: from mailsec112.isp.belgacom.be (mailsec112.isp.belgacom.be [195.238.20.108]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0ECB1585 for ; Sun, 31 Jul 2016 11:19:03 +0000 (UTC) (envelope-from benny.goemans@belgacom.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DNAQDI3Z1X/9HaUlFdhRe5C4F9gmaDN?= =?us-ascii?q?4FeFAEBAQEBAQFdJ4UMEQJTO4ECCIgtkyyNFp9khiqIbgVGhS8FiB2HLYkiR4F?= =?us-ascii?q?gjRiBcoRagzGFSYwwg3ceNoFBAQtCAxyBTjoyAQEBhj0NFweBGAEBAQ?= Received: from d5152dad1.static.telenet.be (HELO roundcube.malavon.com) ([81.82.218.209]) by relay.skynet.be with ESMTP/TLS/DHE-RSA-AES128-SHA; 31 Jul 2016 13:17:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 31 Jul 2016 13:17:51 +0200 From: Benny Goemans To: freebsd-arm@freebsd.org Subject: 11.0-BETA2: PWM on Beagle Bone Black kernel panic? Message-ID: <8564a38f541adda22c9aaafa8ed856f0@roundcube.malavon.com> X-Sender: benny.goemans@belgacom.net User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 11:19:04 -0000 All, I've tried enabling PWM on a Beagle Bone Black (tried both PWM 1 & 2) by modifying the DTS. Once I reboot the boot ends with a kernel panic. Now, I might simply be doing something wrong which is why I haven't created a bug for this yet. I haven't used PWM with FreeBSD in quite a long time. Kernel output is attached below. No other changes were made to the default BETA2 image, downloaded from ftp://ftp.freebsd.org/pub/FreeBSD/releases/arm/armv6/ISO-IMAGES/11.0/FreeBSD-11.0-BETA2-arm-armv6-BEAGLEBONE.img.xz). If anyone needs more information, please ask. What I added in the default beaglebone-black.dts: &am33xx_pinmux { /* other stuff snipped here */ ehrpwm2_pins: pinmux_ehrpwm2_pins { pinctrl-single,pins = < AM33XX_IOPAD(0x820, PIN_OUTPUT | MUX_MODE4) /* gpmc_ad9.ehrpwm2a */ AM33XX_IOPAD(0x824, PIN_OUTPUT | MUX_MODE4) /* gpmc_ad8.ehrpwm2b */ >; }; } /* other stuff snipped */ &ehrpwm2 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&ehrpwm2_pins>; }; Recompiled with 'make builddtb' and then copied to /boot/dtb Kind regards, Benny Goemans Full output from serial console: U-Boot SPL 2014.10 (Jul 22 2016 - 09:57:50) MMC: block number 0x100 exceeds max(0x0) MMC: block number 0x200 exceeds max(0x0) *** Error - No Valid Environment Area found Using default environment reading u-boot.img reading u-boot.img U-Boot 2014.10 (Jul 22 2016 - 09:57:50) Watchdog enabled I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 reading u-boot.env ** Unable to read "u-boot.env" from mmc0:1 ** Using default environment Net: not set. Validating first E-fuse MAC cpsw, usb_ether reading uEnv.txt ** Unable to read file uEnv.txt ** Hit any key to stop autoboot: 0 Booting from: mmc 0 ubldr reading ubldr 271821 bytes read in 31 ms (8.4 MiB/s) ## Starting application at 0x88000098 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x9e731510 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@releng2.nyi.freebsd.org, Fri Jul 22 10:12:56 UTC 2016) DRAM: 512MB Number of U-Boot devices: 3 U-Boot env: loaderdev='mmc 0' Found U-Boot device: disk Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel data=0x6cbfe4+0xc401c syms=[0x4+0x7e0f0+0x4+0x9120e] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/dtb/beaglebone-black.dtb size=0x8566 Loaded DTB from file 'beaglebone-black.dtb'. Kernel entry at 0x0x88200100... Kernel args: (null) Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-BETA2 #0 r303168: Fri Jul 22 10:19:10 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0 ) VT: init without driver. CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB enabled LABT branch prediction disabled LoUU:2 LoC:3 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 514383872 (490 MB) Texas Instruments AM335x Processor, Revision ES1.2 random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 simplebus1: on simplebus0 simplebus2: mem 0x210000-0x211fff on simplebu s1 ti_scm0: mem 0-0x7ff on simplebus2 aintc0: mem 0x48200000-0x48200fff on simplebus0 aintc0: Revision 5.0 cpulist0: on ofwbus0 cpu0: on cpulist0 pmu0: on ofwbus0 am335x_prcm0: mem 0x200000-0x203fff on simpl ebus1 am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz ti_pinmux0: mem 0x800-0xa37 on simplebus2 gpio0: mem 0x44e07000-0x44e07fff on simpl ebus0 gpiobus0: on gpio0 gpioc0: on gpio0 gpio1: mem 0x4804c000-0x4804cfff on simpl ebus0 gpiobus1: on gpio1 gpioled0: at pin 21 on gpiobus1 gpioled1: at pin 22 on gpiobus1 gpioled2: at pin 23 on gpiobus1 gpioled3: at pin 24 on gpiobus1 gpioc1: on gpio1 gpio2: mem 0x481ac000-0x481acfff on simpl ebus0 gpiobus2: on gpio2 gpioc2: on gpio2 gpio3: mem 0x481ae000-0x481aefff on simpl ebus0 gpiobus3: on gpio3 gpioc3: on gpio3 uart0: mem 0x44e09000-0x44e0afff on simplebus0 uart0: console (115384,n,8,1) iichb0: mem 0x44e0b000-0x44e0bfff on simplebus0 iichb0: I2C revision 4.0 FIFO size: 32 bytes iicbus0: on iichb0 iic0: on iicbus0 am335x_pmic0: at addr 0x48 on iicbus0 iicbus0: at addr 0xa0 tda0 at addr 0xe0 on iicbus0 tda1 at addr 0xe0 on iicbus0 iichb1: mem 0x4802a000-0x4802afff on simplebus0 iichb1: I2C revision 4.0 FIFO size: 32 bytes iicbus1: on iichb1 iic1: on iicbus1 iichb2: mem 0x4819c000-0x4819cfff on simplebus0 iichb2: I2C revision 4.0 FIFO size: 32 bytes iicbus2: on iichb2 iic2: on iicbus2 iicbus2: at addr 0xa8 iicbus2: at addr 0xaa iicbus2: at addr 0xac iicbus2: at addr 0xae sdhci_ti0: mem 0x48060000-0x48060fff on simplebus0 mmc0: on sdhci_ti0 sdhci_ti1: mem 0x481d8000-0x481d8fff on simplebus0 mmc1: on sdhci_ti1 ti_wdt0: mem 0x44e35000-0x44e35fff on simplebus0 ti_mbox0: mem 0x480c8000-0x480c81ff on simplebus0 ti_mbox0: revision 4.0 am335x_dmtimer0: mem 0x48040000-0x480403ff on simplebus0 Event timer "DMTimer2" frequency 24000000 Hz quality 500 am335x_dmtimer1: mem 0x48042000-0x480423ff on simplebus0 Timecounter "DMTimer3" frequency 24000000 Hz quality 500 am335x_rtc0: mem 0x44e3e000-0x44e3efff on simplebus0 am335x_rtc0: AM335X RTC v1.0.6 spi0: mem 0x481a0000-0x481a03ff on simplebus0 spi0: scheme: 0x1 func: 0x30 rtl: 1 rev: 2.11 custom rev: 0 spibus0: on spi0 usbss0: mem 0x47400000-0x47400fff on simplebus0 usbss0: TI AM335X USBSS v0.0.13 musbotg0: mem 0x47401400-0x474017ff,0x47401000-0x474011ff on usbss0 usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus0 on musbotg0 musbotg1: mem 0x47401c00-0x47401fff,0x47401800-0x474019ff on usbss0 usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus1 on musbotg1 am335x_pwmss0: mem 0x48304000-0x4830400f on simplebus0 am335x_ehrpwm0: mem 0x48304200-0x4830427f on am335x_pwmss0 cpswss0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a1007ff,0x4a101200-0x4a1012ff on simplebus0 cpswss0: CPSW SS Version 1.12 (0) cpswss0: Initial queue size TX=128 RX=384 cpsw0: on cpswss0 miibus0: on cpsw0 smscphy0: PHY 0 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cpsw0: Ethernet address: 1c:ba:8c:a8:8c:1c fb0: mem 0x4830e000-0x4830efff on simplebus0 ti_adc0: mem 0x44e0d000-0x44e0dfff disabled on simplebus0 ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0 ti_pruss0: mem 0x4a300000-0x4a37ffff on simplebus0 ti_pruss0: AM33xx PRU-ICSS cryptosoft0: Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 am335x_pmic0: TPS65217C ver 1.2 powered by AC tda0: TDA19988 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 uhub0: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered tda0: failed to read EDID tda1: TDA19988 tda1: failed to read EDID mmcsd0: 8GB at mmc0 24.0MHz/4bit/65535-block mmcsd1: 2GB at mmc1 48.0MHz/8bit/65535-block Trying to mount root from ufs:/dev/ufs/rootfs [rw]... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately Setting hostuuid: 1662bbe9-4ff6-11e6-8cda-1cba8ca88c1c. Setting hostid: 0x4d53055b. Starting file system checks: /dev/ufs/rootfs: 32999 files, 283298 used, 1594709 free (325 frags, 199298 blocks, 0.0% fragmentation) Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/perl5/5.20/mach/CORE random: unblocking device. Soft Float compatibility ldconfig path: Setting hostname: beaglebone. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . cpsw0: link state changed to DOWN cpsw0: link state changed to UP Starting Network: lo0 cpsw0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 cpsw0: flags=8843 metric 0 mtu 1500 options=8000b ether 1c:ba:8c:a8:8c:1c media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 Starting devd. Fatal kernel mode data abort: 'Translation Fault (L2)' on read trapframe: 0xde3bdc48 FSR=00000007, FAR=00000000, spsr=20000013 r0 =00000001, r1 =00000000, r2 =00000001, r3 =c2c7d6e0 r4 =de3bddb8, r5 =c29e5cc0, r6 =00000001, r7 =c0960424 r8 =00000000, r9 =c2c7d6e0, r10=de3bddb8, r11=de3bdcf8 r12=fefefeff, ssp=de3bdcd8, slr=00008080, pc =c04f8b74 panic: Fatal abort Uptime: 17s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. From owner-freebsd-arm@freebsd.org Sun Jul 31 11:45:11 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E266DBA1767 for ; Sun, 31 Jul 2016 11:45:11 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95FAE1EFE; Sun, 31 Jul 2016 11:45:11 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.81.13]) by kabab.cs.huji.ac.il with esmtp id 1bTpB0-000J7H-VY; Sun, 31 Jul 2016 14:45:03 +0300 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: allwinner h3 From: Daniel Braniss In-Reply-To: Date: Sun, 31 Jul 2016 14:45:02 +0300 Cc: freebsd-arm , Emmanuel Vadot Message-Id: <412A27AE-BCE3-415C-B76E-E756673544A8@cs.huji.ac.il> References: <0BDCC879-CE88-411B-88C3-2960BA756759@cs.huji.ac.il> To: Jared McNeill X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 11:45:12 -0000 after much find/grep/google(*) i have an orange-plus.dtb that includes = ehci2 but: ... gpioc0: on gpio0 aw_wdog0: mem 0x1c20ca0-0x1c20cbf on simplebus0 ehci0: mem 0x1c1c000-0x1c1c0ff = on simplebus0 ehci0: Could not get phy panic: vm_fault: fault on nofault entry, addr: deadc000 ... so I need a pointer to the missing phy. (I=92m again grepping/find but if some warm hearted person =85) cheers, danny *: got an orange-plus.dts from Jared - thanks!, but was missing ehci2 = stuff, I found it in a newer sun8i-h3.dtsi, and blindly added an include for = it. > On 28 Jul 2016, at 16:18, Jared McNeill wrote: >=20 > Hi Danny! >=20 > Here's the dts for my Orange Pi Plus 2E: = https://github.com/jaredmcneill/freebsd/blob/allwinner-h3/sys/boot/fdt/dts= /arm/orangepi-plus-2e.dts = . You should be able to use that as a = template for the Orange Pi Plus, I think the boards are fairly similar. >=20 > The Linux dts files (last I checked) didn't include ethernet support, = so you'll see that I've added it there. >=20 > Also make sure you are using 12.0-CURRENT for proper H3 ethernet = support. >=20 > Cheers, > Jared >=20 > > From: danny@cs.huji.ac.il > > Subject: allwinner h3 > > Date: Thu, 28 Jul 2016 15:41:38 +0300 > > CC: manu@freebsd.org > > To: jmcneill@freebsd.org > >=20 > > Hi, > > I have an Orange pi plus, and managed to boot it, it=92s missing the = ethernet, > > and I suspect the dtb (which I took from ? ), any chance of getting = the *.dts files? > >=20 > > In any case, I need the SPI to work (and the ethernet), I can = contribute some time with > > coding/testing/reverse-engeneering. My SPI/RFID diver is working = fine > > with raspberry pi, and I would like to port it to allwinner - = probably orange pi ONE. > >=20 > >=20 > > thanks, > > danny > >=20 From owner-freebsd-arm@freebsd.org Sun Jul 31 11:55:54 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37707BA1A19 for ; Sun, 31 Jul 2016 11:55:54 +0000 (UTC) (envelope-from benny.goemans@belgacom.net) Received: from mailsec112.isp.belgacom.be (mailsec112.isp.belgacom.be [195.238.20.108]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73B1F15E1 for ; Sun, 31 Jul 2016 11:55:52 +0000 (UTC) (envelope-from benny.goemans@belgacom.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ChAACC5Z1X/9HaUlENUIQbKlK5C4F9J?= =?us-ascii?q?IJCgm1KAoFcFAEBAQEBAQGFYwEFAQElJyAbCxguJwEJJg4FAgQBAQEBGQSIHpM?= =?us-ascii?q?rnBKQNgEBCAEBAQEBARwFhiqBeIJVhCECAQEBRoUvBYgdhy2JIkeBYIQ4hTuFF?= =?us-ascii?q?4RagzGFSYwwg3cegkUDHIFObAEBAQSGOQ0egRgBAQE?= Received: from d5152dad1.static.telenet.be (HELO [192.168.0.29]) ([81.82.218.209]) by relay.skynet.be with ESMTP/TLS/DHE-RSA-AES128-SHA; 31 Jul 2016 13:55:50 +0200 Subject: Re: 11.0-BETA2: PWM on Beagle Bone Black kernel panic? To: freebsd-arm@freebsd.org References: <8564a38f541adda22c9aaafa8ed856f0@roundcube.malavon.com> From: Benny Goemans Message-ID: Date: Sun, 31 Jul 2016 13:55:50 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <8564a38f541adda22c9aaafa8ed856f0@roundcube.malavon.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 11:55:54 -0000 On 31-07-2016 13:17, Benny Goemans wrote: > All, > > I've tried enabling PWM on a Beagle Bone Black (tried both PWM 1 & 2) > by modifying the DTS. Once I reboot the boot ends with a kernel panic. > Now, I might simply be doing something wrong which is why I haven't > created a bug for this yet. I haven't used PWM with FreeBSD in quite a > long time. > Kernel output is attached below. No other changes were made to the > default BETA2 image, downloaded from > ftp://ftp.freebsd.org/pub/FreeBSD/releases/arm/armv6/ISO-IMAGES/11.0/FreeBSD-11.0-BETA2-arm-armv6-BEAGLEBONE.img.xz). > > If anyone needs more information, please ask. > > What I added in the default beaglebone-black.dts: > &am33xx_pinmux { > /* other stuff snipped here */ > ehrpwm2_pins: pinmux_ehrpwm2_pins { > pinctrl-single,pins = < > AM33XX_IOPAD(0x820, PIN_OUTPUT | > MUX_MODE4) /* gpmc_ad9.ehrpwm2a */ > AM33XX_IOPAD(0x824, PIN_OUTPUT | > MUX_MODE4) /* gpmc_ad8.ehrpwm2b */ > >; > }; > } > > /* other stuff snipped */ > > &ehrpwm2 { > status = "okay"; > pinctrl-names = "default"; > pinctrl-0 = <&ehrpwm2_pins>; > }; > > Recompiled with 'make builddtb' and then copied to /boot/dtb > > Kind regards, > Benny Goemans > > > > Full output from serial console: > > U-Boot SPL 2014.10 (Jul 22 2016 - 09:57:50) > MMC: block number 0x100 exceeds max(0x0) > MMC: block number 0x200 exceeds max(0x0) > *** Error - No Valid Environment Area found > Using default environment > > reading u-boot.img > reading u-boot.img > > > U-Boot 2014.10 (Jul 22 2016 - 09:57:50) > > Watchdog enabled > I2C: ready > DRAM: 512 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > reading u-boot.env > > ** Unable to read "u-boot.env" from mmc0:1 ** > Using default environment > > Net: not set. Validating first E-fuse MAC > cpsw, usb_ether > reading uEnv.txt > ** Unable to read file uEnv.txt ** > Hit any key to stop autoboot: 0 > Booting from: mmc 0 ubldr > reading ubldr > 271821 bytes read in 31 ms (8.4 MiB/s) > ## Starting application at 0x88000098 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x9e731510 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@releng2.nyi.freebsd.org, Fri Jul 22 10:12:56 UTC 2016) > > DRAM: 512MB > Number of U-Boot devices: 3 > U-Boot env: loaderdev='mmc 0' > Found U-Boot device: disk > Checking unit=0 slice= partition=... good. > Booting from disk0s2a: > /boot/kernel/kernel data=0x6cbfe4+0xc401c syms=[0x4+0x7e0f0+0x4+0x9120e] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > /boot/dtb/beaglebone-black.dtb size=0x8566 > Loaded DTB from file 'beaglebone-black.dtb'. > Kernel entry at 0x0x88200100... > Kernel args: (null) > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-BETA2 #0 r303168: Fri Jul 22 10:19:10 UTC 2016 > > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE > arm > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on > LLVM > 3.8.0 > > ) > VT: init without driver. > CPU: Cortex A8-r3 rev 2 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB enabled LABT branch prediction disabled > LoUU:2 LoC:3 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory = 536870912 (512 MB) > avail memory = 514383872 (490 MB) > Texas Instruments AM335x Processor, Revision ES1.2 > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > simplebus0: on ofwbus0 > simplebus1: on simplebus0 > simplebus2: mem 0x210000-0x211fff > on > simplebu > > s1 > ti_scm0: mem 0-0x7ff on simplebus2 > aintc0: mem 0x48200000-0x48200fff on > simplebus0 > aintc0: Revision 5.0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > pmu0: on ofwbus0 > am335x_prcm0: mem > 0x200000-0x203fff on > simpl > > ebus1 > am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz > ti_pinmux0: mem 0x800-0xa37 on simplebus2 > gpio0: mem > 0x44e07000-0x44e07fff on > simpl > > ebus0 > gpiobus0: on gpio0 > gpioc0: on gpio0 > gpio1: mem > 0x4804c000-0x4804cfff on > simpl > > ebus0 > gpiobus1: on gpio1 > gpioled0: at pin 21 on gpiobus1 > gpioled1: at pin 22 on gpiobus1 > gpioled2: at pin 23 on gpiobus1 > gpioled3: at pin 24 on gpiobus1 > gpioc1: on gpio1 > gpio2: mem > 0x481ac000-0x481acfff on > simpl > > ebus0 > gpiobus2: on gpio2 > gpioc2: on gpio2 > gpio3: mem > 0x481ae000-0x481aefff on > simpl > > ebus0 > gpiobus3: on gpio3 > gpioc3: on gpio3 > uart0: mem 0x44e09000-0x44e0afff on > simplebus0 > uart0: console (115384,n,8,1) > iichb0: mem 0x44e0b000-0x44e0bfff on simplebus0 > iichb0: I2C revision 4.0 FIFO size: 32 bytes > iicbus0: on iichb0 > iic0: on iicbus0 > am335x_pmic0: at addr 0x48 on iicbus0 > iicbus0: at addr 0xa0 > tda0 at addr 0xe0 on iicbus0 > tda1 at addr 0xe0 on iicbus0 > iichb1: mem 0x4802a000-0x4802afff on simplebus0 > iichb1: I2C revision 4.0 FIFO size: 32 bytes > iicbus1: on iichb1 > iic1: on iicbus1 > iichb2: mem 0x4819c000-0x4819cfff on simplebus0 > iichb2: I2C revision 4.0 FIFO size: 32 bytes > iicbus2: on iichb2 > iic2: on iicbus2 > iicbus2: at addr 0xa8 > iicbus2: at addr 0xaa > iicbus2: at addr 0xac > iicbus2: at addr 0xae > sdhci_ti0: mem 0x48060000-0x48060fff on simplebus0 > mmc0: on sdhci_ti0 > sdhci_ti1: mem 0x481d8000-0x481d8fff on simplebus0 > mmc1: on sdhci_ti1 > ti_wdt0: mem 0x44e35000-0x44e35fff on simplebus0 > ti_mbox0: mem 0x480c8000-0x480c81ff on simplebus0 > ti_mbox0: revision 4.0 > am335x_dmtimer0: mem 0x48040000-0x480403ff on > simplebus0 > Event timer "DMTimer2" frequency 24000000 Hz quality 500 > am335x_dmtimer1: mem 0x48042000-0x480423ff on > simplebus0 > Timecounter "DMTimer3" frequency 24000000 Hz quality 500 > am335x_rtc0: mem > 0x44e3e000-0x44e3efff on simplebus0 > am335x_rtc0: AM335X RTC v1.0.6 > spi0: mem 0x481a0000-0x481a03ff on simplebus0 > spi0: scheme: 0x1 func: 0x30 rtl: 1 rev: 2.11 custom rev: 0 > spibus0: on spi0 > usbss0: mem > 0x47400000-0x47400fff on simplebus0 > usbss0: TI AM335X USBSS v0.0.13 > musbotg0: mem > 0x47401400-0x474017ff,0x47401000-0x474011ff on usbss0 > usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM > usbus0 on musbotg0 > musbotg1: mem > 0x47401c00-0x47401fff,0x47401800-0x474019ff on usbss0 > usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM > usbus1 on musbotg1 > am335x_pwmss0: mem 0x48304000-0x4830400f on simplebus0 > am335x_ehrpwm0: mem 0x48304200-0x4830427f on > am335x_pwmss0 > cpswss0: <3-port Switch Ethernet Subsystem> mem > 0x4a100000-0x4a1007ff,0x4a101200-0x4a1012ff on simplebus0 > cpswss0: CPSW SS Version 1.12 (0) > cpswss0: Initial queue size TX=128 RX=384 > cpsw0: on cpswss0 > miibus0: on cpsw0 > smscphy0: PHY 0 on miibus0 > smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > cpsw0: Ethernet address: 1c:ba:8c:a8:8c:1c > fb0: mem 0x4830e000-0x4830efff on simplebus0 > ti_adc0: mem 0x44e0d000-0x44e0dfff disabled on > simplebus0 > ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0 > ti_pruss0: mem > 0x4a300000-0x4a37ffff on simplebus0 > ti_pruss0: AM33xx PRU-ICSS > cryptosoft0: > Timecounters tick every 10.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > am335x_pmic0: TPS65217C ver 1.2 powered by AC > tda0: TDA19988 > ugen0.1: at usbus0 > uhub0: 1> on usbus0 > ugen1.1: at usbus1 > uhub1: 1> on usbus1 > uhub0: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > tda0: failed to read EDID > tda1: TDA19988 > tda1: failed to read EDID > mmcsd0: 8GB at mmc0 > 24.0MHz/4bit/65535-block > mmcsd1: 2GB at > mmc1 48.0MHz/8bit/65535-block > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > WARNING: / was not properly dismounted > warning: no time-of-day clock registered, system time will not be set > accurately > Setting hostuuid: 1662bbe9-4ff6-11e6-8cda-1cba8ca88c1c. > Setting hostid: 0x4d53055b. > Starting file system checks: > /dev/ufs/rootfs: 32999 files, 283298 used, 1594709 free (325 frags, > 199298 blocks, 0.0% fragmentation) > Mounting local filesystems:. > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/perl5/5.20/mach/CORE > random: unblocking device. > Soft Float compatibility ldconfig path: > Setting hostname: beaglebone. > Setting up harvesting: > [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > Feeding entropy: . > cpsw0: link state changed to DOWN > cpsw0: link state changed to UP > Starting Network: lo0 cpsw0. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=21 > cpsw0: flags=8843 metric 0 mtu > 1500 > options=8000b > ether 1c:ba:8c:a8:8c:1c > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > Starting devd. > Fatal kernel mode data abort: 'Translation Fault (L2)' on read > trapframe: 0xde3bdc48 > FSR=00000007, FAR=00000000, spsr=20000013 > r0 =00000001, r1 =00000000, r2 =00000001, r3 =c2c7d6e0 > r4 =de3bddb8, r5 =c29e5cc0, r6 =00000001, r7 =c0960424 > r8 =00000000, r9 =c2c7d6e0, r10=de3bddb8, r11=de3bdcf8 > r12=fefefeff, ssp=de3bdcd8, slr=00008080, pc =c04f8b74 > > panic: Fatal abort > Uptime: 17s > Automatic reboot in 15 seconds - press a key on the console to abort > --> Press a key on the console to reboot, > --> or switch off the system now. > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Small addition, I forgot to mention that I also have the following in the DTS file: &epwmss2 { status = "okay"; }; Another thing I just noticed, this does seem to be working correctly when I disable devd. The clue came from the "Starting devd." right before the crash of course. I suppose this isn't intented, but at least there's a possible workaround. Regards, Benny Goemans From owner-freebsd-arm@freebsd.org Sun Jul 31 14:28:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1676ABA9A61; Sun, 31 Jul 2016 14:28:13 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D50CC15B1; Sun, 31 Jul 2016 14:28:12 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-it0-f45.google.com with SMTP id f6so225997255ith.1; Sun, 31 Jul 2016 07:28:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pj2jQxUWLmt2WZq9vCHqAI5q26TIvxQmEsRZ8HfXsZs=; b=bJdupqX9gVFXsae0OdwLaHcKMqW+ZSGaOVmREyse1wYoiD1Hy35t7kc5DgcLQ+pvIg +pHmcryK5o58MCaw/yf/jgPG49+xoGcmmcnRLHmwhNBpEwfe0UayM6tMfn44LRH3gRmZ 13e2IdCxO3CPR0s/jl6fAn+nnhOAJfVji+OB0+tiT8JYgQPcqv2Xwtdw6XTMAtVJGtai 2qlGJVgA8Nb5ehQBFp3s3fqceutAcjYNPTGjtWDF7unpN1w2UNdOBtUE3w0bB9AmV0KI c8P5ucZigUfJA/JsasIQt16KvvqnPwOwimazHNTIlaX/jxeTV5V0rCwS3iNapvFDSdeu Oo3Q== X-Gm-Message-State: AEkoouvm0PKX7lRp8fI3EVMZcK19DdGcTe7trNjHC6s5qM3973ceg9zp6dqsmV/FDnsLfw== X-Received: by 10.36.110.66 with SMTP id w63mr43498478itc.56.1469974936138; Sun, 31 Jul 2016 07:22:16 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id d71sm11579550ioj.33.2016.07.31.07.22.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jul 2016 07:22:15 -0700 (PDT) Received: by mail-io0-f174.google.com with SMTP id q83so167181531iod.1; Sun, 31 Jul 2016 07:22:15 -0700 (PDT) X-Received: by 10.107.26.16 with SMTP id a16mr52149745ioa.30.1469974935361; Sun, 31 Jul 2016 07:22:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.162.75 with HTTP; Sun, 31 Jul 2016 07:22:13 -0700 (PDT) In-Reply-To: <8efe4828-ab2a-02a6-902b-8614b1f4b24e@freebsd.org> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <8efe4828-ab2a-02a6-902b-8614b1f4b24e@freebsd.org> From: Svatopluk Kraus Date: Sun, 31 Jul 2016 16:22:13 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , "freebsd-arm@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 14:28:13 -0000 Unfortunatelly, I have no time now to read back all this message thread and related ones. Nevertheless, I found time to summarize the main ideas about INTRNG design related to this discussion. Svata ----------------------------------------------------------- INTRNG is designed with three main ideas: (1) An interrupt is identified by one and only unique number. (2) This unique number is assigned only to registered interrupt. (3) The framework does not know any interrupt mapping encoding semantics. A general intr_map_irq() serves to get this unique number for an interrupt mapping. As INTRNG itself does not know any interrupt mapping encoding semantics, it pushes the request to a PIC. Of course, a PIC specification must be provided as arguments to this function. A PIC is specified by either device_t or/and xref (intptr_t). It means that such PIC should be already registered in INTRNG. The idea that INTRNG does not know any interrupt mapping encoding semantics is crucial. It makes INTRNG true general framework. Any interrupt mapping is fully transparent for INTRNG. Any new interrupt mapping semantics can be added without INTRNG concern. That said, centralized interrupt mapping table is no concern for INTRNG as INTRNG works with its interrupt numbers, not with numbers associated with something else. In general, an interrupt mapping table can be established anywhere and clients of this table may use indexes to this table as interrupt specifiers. But if INTRNG bus interface functions are used, a translation to INTRNG interrupt numbers must be done (see paragraph above about intr_map_irq()). In fact, this is a natural case of bridges where interrupts must be remapped. The main reasons why INTRNG does not use a centralized interrupt mapping table instead of an interrupt table are the following: (1) As not only one interrupt mappings can exist for an interrupt in the very same time, it's far more simple, sane, and framework like. One interrupt, one interrupt number, one data associated, no need to know any interrupt mapping semantics. (2) An interrupt mapping is associated with consumer driver and belongs to this driver or some of its parent driver. It's not both sane and newbus like to store an interrupt mapping in some third party - in INTRNG in this case. ----------------------------------------------------------- From owner-freebsd-arm@freebsd.org Sun Jul 31 14:34:26 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 957A9BA9D13 for ; Sun, 31 Jul 2016 14:34:26 +0000 (UTC) (envelope-from movies@flixp-movies-mail.com) Received: from flixp-movies-mail.com (flixp-movies-mail.com [91.239.125.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C1A71A8F for ; Sun, 31 Jul 2016 14:34:25 +0000 (UTC) (envelope-from movies@flixp-movies-mail.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by flixp-movies-mail.com (Postfix) with ESMTPS id EE007A7081 for ; Sun, 31 Jul 2016 08:34:23 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flixp-movies-mail.com; q=dns/txt; s=mail; bh=huIT5gpKcPkkU47uK+rdXXwMxQl9hoDfVxGtZClMEGY=; h=from:subject:to:mime-version:content-type:list-unsubscribe; b=naDNElZlW+zBceWLXkO0ZDojHrtKRWGh9F3AQU6xTuj9mXPgW++nPo+T2ID/wMFakhbfjYlAn 7VBPg4454VYzkeXklo2rl+p+DQ40+y2bqFsy9ToNPqqZniVAa1taBdQdhURMXPI7oYCvL2j8L48 NRKFwAA0n2ttpCk3v1xrZpEuBfK995BthciXOPoI4NDSnMpBorOCIHUfB03ZxLL0g2EROblnbHT hQbamwNWO/Eu5m6EvdaivBV96cuZ4yq7Nxxsc7pbIXcDncL4+a7Zk0HN19iJVlMxSf+olyjk5N0 w/HDKcoaft3rk0W41V4FSCaKbBaaCA9dy5tMOb1wm+UQ== From: Flix Premiere To: freebsd-arm@freebsd.org Subject: Discover new movies on demand in our online cinema Message-Id: <1469975663216-b4a0939c-95929beb-626d76a7@flixp-movies-mail.com> X-Mailer: nodemailer (2.3.0; +http://nodemailer.com/; SMTP (pool)/2.5.1[client:2.3.1]) Date: Sun, 31 Jul 2016 14:34:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 14:34:26 -0000 Discover a world of movies never seen before Welcome to the World's First = Online Cineplex [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 1&url=3Dhttps%3A%2F%2Fflixpremiere.com] , combining the movie theater = experience with on-demand availability. A Cinema in your pocket, where you= can watch great movies you've never seen before, Anytime, Anywhere. Our movies [http://flixp-movies-mail.com/click.php?email_id=3D3745977&email= =3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_= medium=3Demail&utm_campaign=3D4&utm_content=3Dclick2&url=3Dhttps%3A%2F%2Ffl= ixpremiere.com%2Fnow-showing] are exclusive to Flix Premiere. No = commercials. No hidden fees. You pay only for the movies you want to watch,= and can discover new content each and every week in our online Red Carpet = Events [http://flixp-movies-mail.com/click.php?email_id=3D3745977&email=3Df= reebsd-arm@freebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medi= um=3Demail&utm_campaign=3D4&utm_content=3Dclick3&url=3Dhttps%3A%2F%2Fflixpr= emiere.com%2Fred-carpet] . Flix Premiere [http://flixp-movies-mail.com/img= .php?email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4] [http://flixp-movies-mail.com/click.php?email_id=3D3745977&email=3Dfreebsd-= arm@freebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Dem= ail&utm_campaign=3D4&utm_content=3Dclick4&url=3Dhttps%3A%2F%2Fflixpremiere.= com] Now Showing On Demand Interwoven [https://res.cloudinary.= com/flixpremiere/image/upload/c_fill,h_210,w_140/9b271775-2001-4a6e-9a12-09= 40aaccc21e/cover-art/48078dda-f125-4b58-b1b9-df9a52798fb4] [http://flixp-movies-mail.com/click.php?email_id=3D3745977&email=3Dfreebsd-= arm@freebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Dem= ail&utm_campaign=3D4&utm_content=3Dclick5&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Ffilm%2F9b271775-2001-4a6e-9a12-0940aaccc21e] Get Happy [https://res.cloudinary.com/flixpremiere/image/upload/c_fill,h_210,= w_140/22845d49-a7b7-4144-97b4-c81804966d49/cover-art/07b5bfb3-d4c3-4c67-8a6= 0-70a55e03893b] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 6&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2F22845d49-a7b7-4144-97b4-c81= 804966d49] Changeover [https://res.cloudinary.com/flixpremiere/image/upload= /c_fill,h_210,w_140/e321f6ab-83e8-4879-a950-73f3f87d537c/cover-art/9ce373ce= -7dd8-4808-b313-fda1aef18d7f] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 7&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2Fe321f6ab-83e8-4879-a950-73f= 3f87d537c] But Not For Me [https://res.cloudinary.com/flixpremiere/image/up= load/c_fill,h_210,w_140/a725151b-5ab9-4504-8685-a4e29939912d/cover-art/1fda= ed8b-cf9b-4741-a3d9-32f10212955a] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 8&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2Fa725151b-5ab9-4504-8685-a4e= 29939912d] Sonata for Cello [https://res.cloudinary.= com/flixpremiere/image/upload/c_fill,h_210,w_140/091f5303-ee57-4351-b712-39= 333cac39f2/cover-art/001a6678-1c75-42a4-ba7c-2895339ee9a0] [http://flixp-movies-mail.com/click.php?email_id=3D3745977&email=3Dfreebsd-= arm@freebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Dem= ail&utm_campaign=3D4&utm_content=3Dclick9&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Ffilm%2F091f5303-ee57-4351-b712-39333cac39f2] Love Me Do [https://res.cloudinary.com/flixpremiere/image/upload/c_fill,h_210,= w_140/3a607b9e-b4fe-4d40-ab38-b1cdfec4c417/cover-art/118d012c-ec82-45d6-baa= 7-01a7ba1ec46c] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 10&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2F3a607b9e-b4fe-4d40-ab38-b1= cdfec4c417] Noble Fir [https://res.cloudinary.com/flixpremiere/image/upload= /c_fill,h_210,w_140/72e83baa-1af7-4508-a0bd-7544fc7711a6/cover-art/d7918ed4= -7b8f-4192-bae3-e77a32cc8126] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 11&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2F72e83baa-1af7-4508-a0bd-75= 44fc7711a6] Tension(s) [https://res.cloudinary.com/flixpremiere/image/uploa= d/c_fill,h_210,w_140/fd4c15ee-af99-4542-9904-4b94268056c1/cover-art/14c31a0= 1-c2c3-4e2a-bcc0-18ac8e3adaf7] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 12&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2Ffd4c15ee-af99-4542-9904-4b= 94268056c1] Get your ticket for just $4.99 to watch one of these latest movies Now Showing [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 13&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Fnow-showing] . Immerse yourself = in cinema! Watch Now for $4.99 [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 14&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Fnow-showing] Our Upcoming Premiere Exclusive to Flix Premiere Sleepwalkers [https://res.cloudinary.com/flixpremiere/image/upload/c_fill,h_720,= w_480/v1/8d8d3a7f-4259-451c-bc2b-0739ccd1b4cb/cover-art/508c0e1f-23f7-41d3-= a65a-10b971e2e8df] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 15&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Fred-carpet]Premiering this Friday= from 7pm till midnight. Watch the Trailer [http://flixp-movies-mail.= com/click.php?email_id=3D3745977&email=3Dfreebsd-arm@freebsd.= org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_camp= aign=3D4&utm_content=3Dclick16&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Ffilm%2F8d8d3a7f-4259-451c-bc2b-0739ccd1b4cb%3Fmodal%3Dplayer%26filmId= %3D8d8d3a7f-4259-451c-bc2b-0739ccd1b4cb%26video%3Dtrailer]Bring the red = carpet experience home by joining us for the exclusive premieres [http://flixp-movies-mail.com/click.php?email_id=3D3745977&email=3Dfreebsd-= arm@freebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Dem= ail&utm_campaign=3D4&utm_content=3Dclick17&url=3Dhttps%3A%2F%2Fflixpremiere= .com%2Fred-carpet] of films never seen before . Find Out More [http://flixp-movies-mail.com/click.php?email_id=3D3745977&email=3Dfreebsd-= arm@freebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Dem= ail&utm_campaign=3D4&utm_content=3Dclick18&url=3Dhttps%3A%2F%2Fflixpremiere= .com] If you have any questions please don't hesitate to contact us with a= reply or on +44 2085 880618 in the UK and +1 (310) 601 3168 in the USA. To stay informed of the latest theatrical releases and news on Flix = Premiere, sign up to our newsletter [http://flixp-movies-mail.com/click.php= ?email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sou= rce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclic= k19&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Fnewsletter%2Fsign-up] . Or join the conversation Facebook - Flix Premiere [http://res.cloudinary.com/flixpremiere/image/upload/c_scale,h_34,= w_34/social_new-facebook_evulhs.png] [http://flixp-movies-mail.com/click.= php?email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_= source=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dc= lick20&url=3Dhttps%3A%2F%2Fwww.facebook.com%2Fflixpremiere] Twitter - Flix = Premiere [http://res.cloudinary.com/flixpremiere/image/upload/c_scale,h_34,= w_34/social_new_twitter_yaqoks] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 21&url=3Dhttps%3A%2F%2Ftwitter.com%2FFlixPremiere] Instagram - Flix = Premiere [http://res.cloudinary.com/flixpremiere/image/upload/c_scale,h_34,= w_34/social_new-instagram_vvxxtn] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 22&url=3Dhttps%3A%2F%2Finstagram.com%2Fflixpremiere] Twitter - Flix = Premiere [http://res.cloudinary.com/flixpremiere/image/upload/c_scale,h_34,= w_34/social_new-youtube_r1q9wx] [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 23&url=3Dhttps%3A%2F%2Fwww.youtube.com%2Fchannel%2FUCnYihKUuOYOKdK3Ewbq16_w= ] Film Partners [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 24&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm-partners] | News [http://flixp-movies-mail.com/click.php?email_id=3D3745977&email=3Dfreebsd-= arm@freebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Dem= ail&utm_campaign=3D4&utm_content=3Dclick25&url=3Dhttps%3A%2F%2Fflixpremiere= .com%2Fnews] | Privacy [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 26&url=3Dhttps%3A%2F%2Fflixpremiere.com%2Fprivacy] | Terms of Use [http://flixp-movies-mail.com/click.php?email_id=3D3745977&email=3Dfreebsd-= arm@freebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Dem= ail&utm_campaign=3D4&utm_content=3Dclick27&url=3Dhttps%3A%2F%2Fflixpremiere= .com%2Fterms] | Democratize Cinema [http://flixp-movies-mail.com/click.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick= 28&url=3Dhttp%3A%2F%2Fdemocratizecinema.com%2F] More about Flix Premiere Flix Premiere is the world's first online Cineplex, combining the movie = theater experience with on-demand availability. A Cinema in your pocket, = where you can watch great movies you've never seen before, Anytime, = Anywhere. Our movies are exclusive to Flix Premiere. No commercials. No = hidden fees. You pay only for the movies you want to watch, and can = discover new content each and every week. The Flix Premiere Experience Red Carpet =E2=80=93 Each film will premiere on our platform =E2=80=93 = there will be a specific window wherein each film can be viewed for the = first time ever in that territory. Now Showing =E2=80=93 At any given time= we feature films in our online cinema, giving you a choice of quality new films we have carefully selected for you. Coming Soon =E2=80=93 These highly anticipated films will be coming to our = Online Cineplex for on-demand viewing in the near future. All Films =E2=80=93 What makes us unique compared to physical theaters? You= can come back and watch any films previously shown on our Cineplex at any = time! How it works We partner with talented filmmakers from all over the = world, thereby becoming the single point of discovery for the 95% of films = that =E2=80=98never' find their audience. Our rigorous screening program = ensures we bring you high quality content. You create a profile, and stay = up to date with our new releases each week; then stream movies immediately = on the Web, or through our iOS or Android apps. Stay tuned for new = platform announcements soon. If you do not wish to receive these emails,= Unsubscribe [http://flixp-movies-mail.com/unsubscribe.php?= email_id=3D3745977&email=3Dfreebsd-arm@freebsd.org&campaign_id=3D4&utm_sour= ce=3Demail_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dunsub= scribe] here. Copyright =C2=A9 2016 Flix Premiere Ltd All Rights Reserved Disclaimer: This email is intended for the named addressee only. It = contains information, which may be privileged or confidential. Unless you = are the named addressee, you should not read, copy, use the information it = contains nor disclose it to a third party. If you have received this = communication in error please notify us immediately so that we can take = corrective action. Internet e-mails are not necessarily secure. You should = be aware that changes could have been made to this message after it was = sent. Flix Premiere Limited does not accept liability for any action taken= in reliance on the content of this message. Flix Premiere Ltd: Company = Number 09455299 | VAT Number 236 0004 58 Physical location: Churchdown = Chambers, Bordyke, Tunbridge, England TN9 1NR, UK Sent: 2016-07-31 From owner-freebsd-arm@freebsd.org Sun Jul 31 14:34:26 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B82CBBA9D20 for ; Sun, 31 Jul 2016 14:34:26 +0000 (UTC) (envelope-from movies@flixp-movies-mail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9EE1A90 for ; Sun, 31 Jul 2016 14:34:26 +0000 (UTC) (envelope-from movies@flixp-movies-mail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 98EE9BA9D17; Sun, 31 Jul 2016 14:34:26 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96198BA9D14 for ; Sun, 31 Jul 2016 14:34:26 +0000 (UTC) (envelope-from movies@flixp-movies-mail.com) Received: from flixp-movies-mail.com (flixp-movies-mail.com [91.239.125.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C1591A8E for ; Sun, 31 Jul 2016 14:34:25 +0000 (UTC) (envelope-from movies@flixp-movies-mail.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by flixp-movies-mail.com (Postfix) with ESMTPS id EE7C1A7082 for ; Sun, 31 Jul 2016 08:34:23 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flixp-movies-mail.com; q=dns/txt; s=mail; bh=5wKnB54LJCkJpFjfN9hWpTQ+yAn4yIy8o47HC91eDX0=; h=from:subject:to:mime-version:content-type:list-unsubscribe; b=kS5XALGMWwhwlG+P23b2ADeKByx0sv9cWZ+AQtIrmrkM34w02HTx2eY7UYJ5TPEc94EdTuTKD e/cvNZ9yQ7SLUA8sj/Yd34p718MQzeUT9pbr1hl9ayQkOK8s1VLu4eeKAU/EAEBxsA4184poshA rq2MC55dUFN/46gsnbLWmsm0CIT7uxHOB6waCO6FKByOm0bj/AlJ0+VofzHh8ViP3DZJv18EwQs GC61uURjZXqNW3IctXM63yORDNJ4O4KxbRQGjDY0cLhfL7kTnGTRrnFIFQ05KB9tjigTqsr+RmB uoNuvqIW6qIb2uukXL1HqFjQD44DdGlTgbI+Mp5y1UGg== From: Flix Premiere To: arm@freebsd.org Subject: Discover new movies on demand in our online cinema Message-Id: <1469975663229-a0e18984-becd055b-3658afe6@flixp-movies-mail.com> X-Mailer: nodemailer (2.3.0; +http://nodemailer.com/; SMTP (pool)/2.5.1[client:2.3.1]) Date: Sun, 31 Jul 2016 14:34:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 14:34:26 -0000 Discover a world of movies never seen before Welcome to the World's First = Online Cineplex [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick1&url=3D= https%3A%2F%2Fflixpremiere.com] , combining the movie theater experience = with on-demand availability. A Cinema in your pocket, where you can watch = great movies you've never seen before, Anytime, Anywhere. Our movies [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick2&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Fnow-showing] are exclusive to Flix Premiere. No commercials. No = hidden fees. You pay only for the movies you want to watch, and can = discover new content each and every week in our online Red Carpet Events [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick3&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Fred-carpet] . Flix Premiere [http://flixp-movies-mail.com/img.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4] [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick4&url=3Dhttps%3A%2F%2Fflixpremiere.com] Now Showing On Demand Interwoven [https://res.cloudinary.= com/flixpremiere/image/upload/c_fill,h_210,w_140/9b271775-2001-4a6e-9a12-09= 40aaccc21e/cover-art/48078dda-f125-4b58-b1b9-df9a52798fb4] [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick5&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Ffilm%2F9b271775-2001-4a6e-9a12-0940aaccc21e] Get Happy [https://res.cloudinary.com/flixpremiere/image/upload/c_fill,h_210,= w_140/22845d49-a7b7-4144-97b4-c81804966d49/cover-art/07b5bfb3-d4c3-4c67-8a6= 0-70a55e03893b] [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick6&url=3D= https%3A%2F%2Fflixpremiere.com%2Ffilm%2F22845d49-a7b7-4144-97b4-c81804966d4= 9] Changeover [https://res.cloudinary.com/flixpremiere/image/upload/c_fill,= h_210,w_140/e321f6ab-83e8-4879-a950-73f3f87d537c/cover-art/9ce373ce-7dd8-48= 08-b313-fda1aef18d7f] [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick7&url=3D= https%3A%2F%2Fflixpremiere.com%2Ffilm%2Fe321f6ab-83e8-4879-a950-73f3f87d537= c] But Not For Me [https://res.cloudinary.com/flixpremiere/image/upload/c_f= ill,h_210,w_140/a725151b-5ab9-4504-8685-a4e29939912d/cover-art/1fdaed8b-cf9= b-4741-a3d9-32f10212955a] [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick8&url=3D= https%3A%2F%2Fflixpremiere.com%2Ffilm%2Fa725151b-5ab9-4504-8685-a4e29939912= d] Sonata for Cello [https://res.cloudinary.com/flixpremiere/image/upload/= c_fill,h_210,w_140/091f5303-ee57-4351-b712-39333cac39f2/cover-art/001a6678-= 1c75-42a4-ba7c-2895339ee9a0] [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick9&url=3D= https%3A%2F%2Fflixpremiere.com%2Ffilm%2F091f5303-ee57-4351-b712-39333cac39f= 2] Love Me Do [https://res.cloudinary.com/flixpremiere/image/upload/c_fill,= h_210,w_140/3a607b9e-b4fe-4d40-ab38-b1cdfec4c417/cover-art/118d012c-ec82-45= d6-baa7-01a7ba1ec46c] [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick10&url= =3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2F3a607b9e-b4fe-4d40-ab38-b1cdfec4= c417] Noble Fir [https://res.cloudinary.com/flixpremiere/image/upload/c_fil= l,h_210,w_140/72e83baa-1af7-4508-a0bd-7544fc7711a6/cover-art/d7918ed4-7b8f-= 4192-bae3-e77a32cc8126] [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick11&url= =3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2F72e83baa-1af7-4508-a0bd-7544fc77= 11a6] Tension(s) [https://res.cloudinary.com/flixpremiere/image/upload/c_fi= ll,h_210,w_140/fd4c15ee-af99-4542-9904-4b94268056c1/cover-art/14c31a01-c2c3= -4e2a-bcc0-18ac8e3adaf7] [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick12&url= =3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2Ffd4c15ee-af99-4542-9904-4b942680= 56c1] Get your ticket for just $4.99 to watch one of these latest movies Now Showing [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick13&url= =3Dhttps%3A%2F%2Fflixpremiere.com%2Fnow-showing] . Immerse yourself in = cinema! Watch Now for $4.99 [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick14&url= =3Dhttps%3A%2F%2Fflixpremiere.com%2Fnow-showing] Our Upcoming Premiere Exclusive to Flix Premiere Sleepwalkers [https://res.cloudinary.= com/flixpremiere/image/upload/c_fill,h_720,w_480/v1/8d8d3a7f-4259-451c-bc2b= -0739ccd1b4cb/cover-art/508c0e1f-23f7-41d3-a65a-10b971e2e8df] [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick15&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Fred-carpet]Premiering this Friday from 7pm till midnight. Watch the Trailer [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick16&url= =3Dhttps%3A%2F%2Fflixpremiere.com%2Ffilm%2F8d8d3a7f-4259-451c-bc2b-0739ccd1= b4cb%3Fmodal%3Dplayer%26filmId%3D8d8d3a7f-4259-451c-bc2b-0739ccd1b4cb%26vid= eo%3Dtrailer]Bring the red carpet experience home by joining us for the exclusive premieres [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick17&url= =3Dhttps%3A%2F%2Fflixpremiere.com%2Fred-carpet] of films never seen before = . Find Out More [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick18&url= =3Dhttps%3A%2F%2Fflixpremiere.com] If you have any questions please don't = hesitate to contact us with a reply or on +44 2085 880618 in the UK and +1 = (310) 601 3168 in the USA. To stay informed of the latest theatrical = releases and news on Flix Premiere, sign up to our newsletter [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick19&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Fnewsletter%2Fsign-up] . Or join the conversation Facebook - Flix Premiere [http://res.cloudinary.com/flixpremiere/image/uplo= ad/c_scale,h_34,w_34/social_new-facebook_evulhs.png] [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick20&url=3Dhttps%3A%2F%2Fwww.facebook.= com%2Fflixpremiere] Twitter - Flix Premiere [http://res.cloudinary.= com/flixpremiere/image/upload/c_scale,h_34,w_34/social_new_twitter_yaqoks] [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick21&url=3Dhttps%3A%2F%2Ftwitter.= com%2FFlixPremiere] Instagram - Flix Premiere [http://res.cloudinary.= com/flixpremiere/image/upload/c_scale,h_34,w_34/social_new-instagram_vvxxtn= ] [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@fr= eebsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&ut= m_campaign=3D4&utm_content=3Dclick22&url=3Dhttps%3A%2F%2Finstagram.= com%2Fflixpremiere] Twitter - Flix Premiere [http://res.cloudinary.= com/flixpremiere/image/upload/c_scale,h_34,w_34/social_new-youtube_r1q9wx] [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick23&url=3Dhttps%3A%2F%2Fwww.youtube.= com%2Fchannel%2FUCnYihKUuOYOKdK3Ewbq16_w] Film Partners [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick24&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Ffilm-partners] | News [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick25&url= =3Dhttps%3A%2F%2Fflixpremiere.com%2Fnews] | Privacy [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick26&url=3Dhttps%3A%2F%2Fflixpremiere.= com%2Fprivacy] | Terms of Use [http://flixp-movies-mail.com/click.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dclick27&url= =3Dhttps%3A%2F%2Fflixpremiere.com%2Fterms] | Democratize Cinema [http://flixp-movies-mail.com/click.php?email_id=3D3745978&email=3Darm@free= bsd.org&campaign_id=3D4&utm_source=3Demail_campaign&utm_medium=3Demail&utm_= campaign=3D4&utm_content=3Dclick28&url=3Dhttp%3A%2F%2Fdemocratizecinema.= com%2F] More about Flix Premiere Flix Premiere is the world's first = online Cineplex, combining the movie theater experience with on-demand = availability. A Cinema in your pocket, where you can watch great movies you've never seen before, Anytime, Anywhere. Our movies are exclusive to Flix Premiere. No commercials. No hidden fees. = You pay only for the movies you want to watch, and can discover new content= each and every week. The Flix Premiere Experience Red Carpet =E2=80=93 Each film will premiere on our platform =E2=80=93 = there will be a specific window wherein each film can be viewed for the = first time ever in that territory. Now Showing =E2=80=93 At any given time= we feature films in our online cinema, giving you a choice of quality new films we have carefully selected for you. Coming Soon =E2=80=93 These highly anticipated films will be coming to our = Online Cineplex for on-demand viewing in the near future. All Films =E2=80=93 What makes us unique compared to physical theaters? You= can come back and watch any films previously shown on our Cineplex at any = time! How it works We partner with talented filmmakers from all over the = world, thereby becoming the single point of discovery for the 95% of films = that =E2=80=98never' find their audience. Our rigorous screening program = ensures we bring you high quality content. You create a profile, and stay = up to date with our new releases each week; then stream movies immediately = on the Web, or through our iOS or Android apps. Stay tuned for new = platform announcements soon. If you do not wish to receive these emails,= Unsubscribe [http://flixp-movies-mail.com/unsubscribe.php?= email_id=3D3745978&email=3Darm@freebsd.org&campaign_id=3D4&utm_source=3Dema= il_campaign&utm_medium=3Demail&utm_campaign=3D4&utm_content=3Dunsubscribe] = here. Copyright =C2=A9 2016 Flix Premiere Ltd All Rights Reserved Disclaimer: This email is intended for the named addressee only. It = contains information, which may be privileged or confidential. Unless you = are the named addressee, you should not read, copy, use the information it = contains nor disclose it to a third party. If you have received this = communication in error please notify us immediately so that we can take = corrective action. Internet e-mails are not necessarily secure. You should = be aware that changes could have been made to this message after it was = sent. Flix Premiere Limited does not accept liability for any action taken= in reliance on the content of this message. Flix Premiere Ltd: Company = Number 09455299 | VAT Number 236 0004 58 Physical location: Churchdown = Chambers, Bordyke, Tunbridge, England TN9 1NR, UK Sent: 2016-07-31 From owner-freebsd-arm@freebsd.org Sun Jul 31 14:54:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEE19BA9363; Sun, 31 Jul 2016 14:54:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9466A15B2; Sun, 31 Jul 2016 14:54:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6VEsaOF003749 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 31 Jul 2016 07:54:36 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Svatopluk Kraus References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <8efe4828-ab2a-02a6-902b-8614b1f4b24e@freebsd.org> Cc: "freebsd-arm@freebsd.org" , Michal Meloun , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <17f46646-95b7-3bcd-f652-942c802f7cf7@freebsd.org> Date: Sun, 31 Jul 2016 07:54:36 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbhWuT1q6TGz1sR6C7THvdIp5QWRpLpclfbQOJbhHXV1+oYyy/lalE9IO7Ttd+aa5lUutAdpEhZAorif4r1XwcnWUVlZFSepZ0= X-Sonic-ID: C;Ip7Osi5X5hGDHa/hcgQksw== M;MlA0sy5X5hGDHa/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 14:54:39 -0000 On 07/31/16 07:22, Svatopluk Kraus wrote: > Unfortunatelly, I have no time now to read back all this message > thread and related ones. Nevertheless, I found time to summarize the > main ideas about INTRNG design related to this discussion. > > Svata Thank you for the summary. It would be great if you could look at the wiki page at https://wiki.freebsd.org/Complicated_Interrupts at some point and see how it corresponds to this. In particular, there are five cases at the end that I cannot figure out to implement with your API and that are essential to support PowerPC. I have a few comments inline below. -Nathan > > ----------------------------------------------------------- > > INTRNG is designed with three main ideas: > > (1) An interrupt is identified by one and only unique number. > (2) This unique number is assigned only to registered interrupt. > (3) The framework does not know any interrupt mapping encoding semantics. This is also true of the previous system; these are good design principles. > A general intr_map_irq() serves to get this unique number for an > interrupt mapping. As INTRNG itself does not know any interrupt > mapping encoding semantics, it pushes the request to a PIC. Of course, > a PIC specification must be provided as arguments to this function. A > PIC is specified by either device_t or/and xref (intptr_t). It means > that such PIC should be already registered in INTRNG. > > The idea that INTRNG does not know any interrupt mapping encoding > semantics is crucial. It makes INTRNG true general framework. Any > interrupt mapping is fully transparent for INTRNG. Any new interrupt > mapping semantics can be added without INTRNG concern. > > That said, centralized interrupt mapping table is no concern for > INTRNG as INTRNG works with its interrupt numbers, not with numbers > associated with something else. All of this, again, is true of the old code. You provide a PIC specification and data meaningful to that PIC, you get back an abstract IRQ. The core interrupt code neither knows nor cares about what that information means. > > In general, an interrupt mapping table can be established anywhere and > clients of this table may use indexes to this table as interrupt > specifiers. But if INTRNG bus interface functions are used, a > translation to INTRNG interrupt numbers must be done (see paragraph > above about intr_map_irq()). In fact, this is a natural case of > bridges where interrupts must be remapped. Yes, of course. > The main reasons why INTRNG does not use a centralized interrupt > mapping table instead of an interrupt table are the following: > > (1) As not only one interrupt mappings can exist for an interrupt in > the very same time, it's far more simple, sane, and framework like. > One interrupt, one interrupt number, one data associated, no need to > know any interrupt mapping semantics. > > (2) An interrupt mapping is associated with consumer driver and > belongs to this driver or some of its parent driver. It's not both > sane and newbus like to store an interrupt mapping in some third party > - in INTRNG in this case. I agree with this completely. The sticking point is whether you associate PIC-specific interrupt data with the interrupt when the bus parent enumerates the bus or when resources are allocated with bus_alloc_resource(). Doing it at enumeration time means that there is a robust relationship between what the interrupt specifier the bus parent meant to assign and what actually *is* assigned and fixes a large number of issues where interrupts are enumerated by code over which the bus parent does not have full control: its children, the MI PCI code, etc. Doing it when the resources are allocated, as r301453 does, makes it much more fragile (as well as a little confusing, since what interrupts refer to is only set long after they are allocated). For example, I have no idea how to implement PCIB_ROUTE_INTERRUPT(), and so non-MSI PCI interrupts, with this framework and MSI interrupts work only in simple cases. This is a critical thing: It means I can't support PCI. I could hack around the issue with a mapping table and API that records which abstract OFW IRQ meant what specifier and iparent and put that in, say, nexus, using it to do the right thing when bus_alloc_resource() is later called on those specifiers -- but we are immediately back to the pre-310453 API at that point. There are a number of examples (not complete, but illustrative) of other such cases on the referenced wiki page. -Nathan > ----------------------------------------------------------- > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sun Jul 31 15:40:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B465BBA9F22; Sun, 31 Jul 2016 15:40:22 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EB651224; Sun, 31 Jul 2016 15:40:21 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id B6BBC3AC81; Sun, 31 Jul 2016 17:40:18 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <579E1BE2.7020500@FreeBSD.org> Date: Sun, 31 Jul 2016 17:40:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Sun, 31 Jul 2016 17:40:18 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 15:40:22 -0000 Dne 31.07.2016 v 8:11 Nathan Whitehorn napsal(a): [snip] > >> The current API is certainly a bit of a hack and I would be pleased to >>> see it go; but the replacement needs to be more functional and more >>> robust. As far as I can tell, I literally *cannot* move PowerPC over >>> to this architecture. >> Yes, at this time, I agree. If you can accept enhancement of >> (owf_)bus_map_intr() then we can move to next, significantly less >> hackish, state. > > OK, sure. I wrote some code this afternoon (attached) to sketch this. > It does not compile or run or anything useful, but it should > illustrate the important parts of what I think is an API that should > work for everyone. I'm happy to finish it if it looks reasonable -- I > may in any case just to replace PowerPC's increasingly teetering > intr_machdep.c. > > The OF part is essentially unchanged from how it currently works: > there's a method that you pass the interrupt specifier and interrupt > parent to, and it spits back an IRQ that means that combination of > things in perpetuity. OFW_BUS_MAP_INTR() in nexus.c, with its current > API, can be implemented in terms of it in one line. Whenever the > relevant PIC attaches, it is told to use the given IRQ to refer to > that opaque bytestring. > > I've added a set of equivalent functions for ACPI that take the > contents of an ACPI interrupt specifier and do the same things. It > tries to have the IRQ be human-meaningful, if possible, by matching > the ACPI interrupt number. Having separate functions seemed a little > cleaner than exposing the enums and unions as part of the KPI, but I'm > not wedded to it -- this is just an example. > > PICs register (and deregister) themselves with either an OF phandle or > an ACPI resource string or (god help us) both as needed. The PICs have > corresponding methods for interpreting various kinds of interrupt > specifiers. > > Whether it allows bus_alloc_resource(), bus_setup_intr(), etc. to > succeed before the PICs are attached is gated on an #ifdef. That can > probably be off by default on ARM. A PowerPC version of this code > would have to keep it on until various bus drivers are fixed. > > Here's the general flow: > - Parent bus enumerates children, maps IRQs as needed, adds to > resource list. The struct resources involved aren't special (just a > single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are trivial to > implement (and already are implemented, in general, for OF/FDT drivers). > - bus_alloc_resource() does nothing special > - bus_setup_intr() calls into the PIC and does what is needed, as in > r301453 (to within that #ifdef) > > This should keep all the best pieces of everything: > - ACPI and OF are supported together, and easy to extend for other > types of mapping technologies without breaking either KBI or KPI (just > add new functions) > - No APIs change for existing Open Firmware code > - The support code can live entirely in machine-dependent directories, > with no code changes at all required in kern/ or dev/ofw/ > - bus_setup_intr() and friends behave as in r301453 and succeed or > fail for real > - PCI code is not an issue > - No disconnected interrupt state maintained in mapping table (unless > the transitional #ifdef is on) and the mapping table content is only > larger than r301453 by having a copy of the original interrupt specifier. > > If and when we manage to fix the kernel APIs to allow non-scalar > interrupt specifiers, this should also be easy to gradually > transmogrify to support that case since there exists a 1:1 mapping of > scalar IRQs to rich data and the control flow would be identical: > interrupt specifiers are read at enumeration time and a resulting > handle -- struct resource or scalar IRQ -- used afterward to refer to it. > Nice, nice, i think that we are very close at this point. The problem with the above workflow is that maps IRQ function is called at parent bus enumeration time, generally at BUS_PASS_BUS pass. And at this time, PICs are not exist. Also, 'static struct intr_irqsrc *irq_sources[NIRQ];' is not a mapping table, it doesn't provide this functionality. But yes, i understand that mapping table is important and necessary for you. So, if i can extend our concept a little bit, then: We can add new table (map_data_tbl for example) that holds a copy of the original interrupt specifier, index to irq_sources table and probably some flags. And we can modify the above workflow to: - Parent bus enumerates children, allocates entries from map_data_tbl, adds to resource list. The struct resources involved aren't special (just a single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are trivial to implement (and already are implemented, in general, for OF/FDT drivers). Index to map_data_tbl is used as resource ID. - bus_alloc_resource() sets 'ALLOCATED' in map_data_tbl flags field, *maps IRQs* and stores result in 'index' field. - bus_setup_intr() sets 'SETUP_DONE' in map_data_tbl flags field, calls into the PIC and does what is needed, as in r301453. (to within that #ifdef) And, in PPC case, newly attached PIC scans whole map_data_tbl table, finds his entries and makes what needs. Does that make sense? I hope that postponing of map IRQ call is not a problem for PPC, everything else looks easy. Moreover, this additional level of indirection also solves all my 'hypothetical corner cases' with N:1 mappings (between original interrupt specifier and real interrupt number). > Some more comments below. > >>> The ideal API would be one in which the resource enumeration code >>> could assign, instead of numbers, some structured information that >>> contains the full firmware specifier (string parent + interrupt pin >>> for ACPI, interrupt parent phandle + specifier for device tree, bare >>> numbers for simple systems). >> Yes, exactly. I am happy that at least we agree on something. The only >> difference is that we want triplet > specifier> or > > Which makes perfect sense and is a good idea. > >>> That seemed, and seems, too invasive. I think we agree on this and >>> have chosen to approximate that API in two different ways. >> I still think that we found way how we can realize the above idea in >> non-invasive way. >> From my point of view the solution is: >> Put/attach the above triplet to RLE and then copy it (within >> bus_resource_attach() to struct resource. >> But yes, I understand that I am not able to explain clearly enough. > > I think we were just talking past eachother somehow. > > Anyway, my concern about putting this in struct resource * at > bus_alloc_resource() time is basically that there are a whole bunch of > cases in which (a) it's hard to reverse engineer which interrupt from > the device tree (or whatever) was meant to correspond to a particular > arbitrary IRQ in an allocation request unless you keep logs and (b) > there are a bunch of cases, mostly involving PCI, where interrupt > resource allocation doesn't proceed through struct resource * at all, > so you pretty much have to keep logs. Once you start keeping logs of > which IRQ corresponds to which specifier at the device level, you > might as well just do it once in a centralized place. Oki, i agree. > >> >>> When we designed the interrupt mapping code, we evaluated a large >>> number of possible approaches. Something very much like this was one >>> of them. It was rejected as being too fragile (it requires resource >>> allocation and enumeration to be coupled) and to have too many corner >>> cases (the PCI MSI and LSI APIs, for instance). The interrupt mapping >>> stuff seemed at the time, and so far still seems, like the least-bad >>> approximation to the ideal case: it is essentially that ideal API, in >>> that it happens at bus enumeration and involves just assigning the >>> firmware specifiers, but with lookup keys to that information stuffed >>> into the 32-bit numbers that the rest of the system uses. >> The raw PCI (or MSIX) case is relatively simple. The PCI domain uses >> raw numbers and it's host-to-pci bridge job to translate raw numbers >> from PCI domain to (for example) OFW based resource. >> At this point, I'm still not sure about MSI... > > Right, you can keep a big table in the PCI driver that maps whatever > IRQs you are handing out to some richer interrupt specifiers and > consult that when you get a bus_alloc_resource() request. Which is > basically the approach I'm advocating, except that the table is > centralized, which reduces code duplication and fixes a number of > weird corner cases where children assign extra interrupts to > themselves, etc. and the bus parent has no ability to do something > sensible. > > Please take a look at the attached interface and see if it (or > something like it) meets your needs. It meets all of mine, at least, > and I think fixes all the things you were concerned about. Can you, please, give me also example for GPIO (these are identified by pair). Or, in other words, GPIO needs his own sets of functions? And thanks for your effort and patience, Michal From owner-freebsd-arm@freebsd.org Sun Jul 31 17:58:48 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA208BAA0C3 for ; Sun, 31 Jul 2016 17:58:48 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9333C1632 for ; Sun, 31 Jul 2016 17:58:48 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1469987748; bh=6CS13mXpR3AksJfnz1dfJieTHkpoItjhJcJrA1ksQ2Q=; h=From:Subject:Date:To:From:Subject; b=P+6FKZZDWvE7UT9dSq/KAXb58iPUSrYyBu8wc0vEkzdPu2duKkulXVC2jogjWR2rVvVtm7gEkQcHD00hYz/FmtJFH+CB8/eZTuFbyPUYr1juYyBEOhgGVHXa0cuRf5OtMoNXxOsFJcDlIU5v7h6fnxnB5gqP8WZv5kJml8LVHYd9uikSELgPcOTfVKJPEzctQzLGQKBfD3G+H3kwM+CB8KGb0TBh5wCH6DrZNuKZG1Evt9gQmhpKbNvJpVNMKJw75zxgSzV7ks0YHdAhbk10HE3XP/gKe/wO9g+Tip8Sa/5v4Ml7dQLLVDUcXVyE4CzJmQ6R2K5fyuMny0D08lYYGw== Received: from [66.196.81.171] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 17:55:48 -0000 Received: from [98.139.213.9] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 17:55:48 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 31 Jul 2016 17:55:48 -0000 X-Yahoo-Newman-Id: 822394.69264.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: I_tdAjsVM1neYTqXS7mRZw774R5uGxRgPl6os.d_uRkJUc5 NBVya9IpxOiqOx_ucQ2em4qcWVUtE81_y_CmJ8uuOBzSALicPqfVruOKpLuE Z6IQef2P7avll9nsrHGZNpzeevdE1ff1VkTXaQ890e9.vYsUh7wP0qNlymiJ 0FhH1775bYNZTgdXc3wpOrrUei7dTq6hvlmHW0trzF_l8N8i3sd9K6j.jQ9P KicEvDQMqWdjaVO6G4shThfmNkK5Pd_gcx5UkgbSuXS5vLsgeKXetU9wMOX1 vfq3gEjC8hD9Cf.0ZrdJczgENXVLVHiFRA4skwP6ehISv0XhfaaN3Kh9ovPJ 9DV4F3YIV5xEe18NE.9xA0ZTNMTT4GZ8JeyY.E5UVrYwsxJsD2EzRijtVDM8 CEXJX4Oo5413aVxeY120cA9qXXfra7CarSnwwA76Cp8G2FTQbI7D8KNJjinj Q5HpbuHsrAtFbE0Zxxa_qkxxYBGwpbJtzHIanXfq.7hxTh4GwjMhSzgHLhAG 5OwLDvli0X3AswuPC70HxqkQ17Ku1XOZOMrms47FdOI3isiUkq_wNYUUrutd u8XD4TxyIfr_MxQ-- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: multipart/mixed; boundary="Apple-Mail=_34DF7300-D6FF-4EC6-B814-8C6A63818DEE" Subject: Zynq/Zybo USB bug: ubldr "fixes" my device tree Message-Id: <7C4D45AC-3DDB-46FE-85AB-5F692E5C1283@yahoo.com> Date: Sun, 31 Jul 2016 10:55:47 -0700 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 17:58:48 -0000 --Apple-Mail=_34DF7300-D6FF-4EC6-B814-8C6A63818DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello. I finally tracked down a bug that kept me from being able to use a USB = drive as root on a Zybo (or Zedboard). Mounting USB drives has worked = fine before but using one as root would fail. The first megabyte of memory space on Zynq has several caveats including = a hole between 256K-512K that is inaccessible by bus masters. My = solution was to simply ignore the first megabyte by starting memory at = 0x100000 in my DTS file(s). But, I discovered that the first megabyte = was being allocated and the ehci device hung trying to DMA to the hole. = It turns out that ubldr, after loading the board.dtb file, proceeded to = =E2=80=9Cfix up=E2=80=9D the device tree from memory range information = it got in a sysinfo call to u-boot=E2=80=99s API. The memory range = started at 0. The simplest work-around seems to be to add a =E2=80=9Cmemreserve=E2=80=9D= property to the DTS. Also, It turns out that only the first half = megabyte needs to be ignored. Patch attached. =E2=80=94 Thomas Skibo thomasskibo@yahoo.com --Apple-Mail=_34DF7300-D6FF-4EC6-B814-8C6A63818DEE Content-Disposition: attachment; filename=patch.zynq-7000.dtsi.txt Content-Type: text/plain; x-unix-mode=0644; name="patch.zynq-7000.dtsi.txt" Content-Transfer-Encoding: 7bit Index: sys/boot/fdt/dts/arm/zynq-7000.dtsi =================================================================== --- sys/boot/fdt/dts/arm/zynq-7000.dtsi (revision 303418) +++ sys/boot/fdt/dts/arm/zynq-7000.dtsi (working copy) @@ -32,6 +32,10 @@ #size-cells = <1>; interrupt-parent = <&GIC>; + // Reserve first half megabyte because it is not accessible to all + // bus masters. + memreserve = <0x00000000 0x00080000>; + // Zynq PS System registers. // ps7sys@f8000000 { --Apple-Mail=_34DF7300-D6FF-4EC6-B814-8C6A63818DEE-- From owner-freebsd-arm@freebsd.org Sun Jul 31 18:43:26 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF766BAA253; Sun, 31 Jul 2016 18:43:26 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0C6E173F; Sun, 31 Jul 2016 18:43:26 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6VIhN9G004097 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 31 Jul 2016 11:43:23 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> Date: Sun, 31 Jul 2016 11:43:23 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <579E1BE2.7020500@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZvVQZDE005RznR1LrYjBmC0ls8/5+kiod/s4Zcd7U+W9XBY02KiwpryW8xl2M4AQJAJYZCOuOJsr3Nh3yxbD936UULR3sDrWw= X-Sonic-ID: C;fGfMqE5X5hG4haDx2xNB0g== M;uHosqU5X5hG4haDx2xNB0g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 18:43:26 -0000 On 07/31/16 08:40, Michal Meloun wrote: > Dne 31.07.2016 v 8:11 Nathan Whitehorn napsal(a): > [snip] >>> The current API is certainly a bit of a hack and I would be pleased to >>>> see it go; but the replacement needs to be more functional and more >>>> robust. As far as I can tell, I literally *cannot* move PowerPC over >>>> to this architecture. >>> Yes, at this time, I agree. If you can accept enhancement of >>> (owf_)bus_map_intr() then we can move to next, significantly less >>> hackish, state. >> OK, sure. I wrote some code this afternoon (attached) to sketch this. >> It does not compile or run or anything useful, but it should >> illustrate the important parts of what I think is an API that should >> work for everyone. I'm happy to finish it if it looks reasonable -- I >> may in any case just to replace PowerPC's increasingly teetering >> intr_machdep.c. >> >> The OF part is essentially unchanged from how it currently works: >> there's a method that you pass the interrupt specifier and interrupt >> parent to, and it spits back an IRQ that means that combination of >> things in perpetuity. OFW_BUS_MAP_INTR() in nexus.c, with its current >> API, can be implemented in terms of it in one line. Whenever the >> relevant PIC attaches, it is told to use the given IRQ to refer to >> that opaque bytestring. >> >> I've added a set of equivalent functions for ACPI that take the >> contents of an ACPI interrupt specifier and do the same things. It >> tries to have the IRQ be human-meaningful, if possible, by matching >> the ACPI interrupt number. Having separate functions seemed a little >> cleaner than exposing the enums and unions as part of the KPI, but I'm >> not wedded to it -- this is just an example. >> >> PICs register (and deregister) themselves with either an OF phandle or >> an ACPI resource string or (god help us) both as needed. The PICs have >> corresponding methods for interpreting various kinds of interrupt >> specifiers. >> >> Whether it allows bus_alloc_resource(), bus_setup_intr(), etc. to >> succeed before the PICs are attached is gated on an #ifdef. That can >> probably be off by default on ARM. A PowerPC version of this code >> would have to keep it on until various bus drivers are fixed. >> >> Here's the general flow: >> - Parent bus enumerates children, maps IRQs as needed, adds to >> resource list. The struct resources involved aren't special (just a >> single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are trivial to >> implement (and already are implemented, in general, for OF/FDT drivers). >> - bus_alloc_resource() does nothing special >> - bus_setup_intr() calls into the PIC and does what is needed, as in >> r301453 (to within that #ifdef) >> >> This should keep all the best pieces of everything: >> - ACPI and OF are supported together, and easy to extend for other >> types of mapping technologies without breaking either KBI or KPI (just >> add new functions) >> - No APIs change for existing Open Firmware code >> - The support code can live entirely in machine-dependent directories, >> with no code changes at all required in kern/ or dev/ofw/ >> - bus_setup_intr() and friends behave as in r301453 and succeed or >> fail for real >> - PCI code is not an issue >> - No disconnected interrupt state maintained in mapping table (unless >> the transitional #ifdef is on) and the mapping table content is only >> larger than r301453 by having a copy of the original interrupt specifier. >> >> If and when we manage to fix the kernel APIs to allow non-scalar >> interrupt specifiers, this should also be easy to gradually >> transmogrify to support that case since there exists a 1:1 mapping of >> scalar IRQs to rich data and the control flow would be identical: >> interrupt specifiers are read at enumeration time and a resulting >> handle -- struct resource or scalar IRQ -- used afterward to refer to it. >> > Nice, nice, i think that we are very close at this point. > The problem with the above workflow is that maps IRQ function is called > at parent bus enumeration time, generally at BUS_PASS_BUS pass. And at > this time, PICs are not exist. > Also, 'static struct intr_irqsrc *irq_sources[NIRQ];' is not a mapping > table, it doesn't provide this functionality. > But yes, i understand that mapping table is important and necessary for you. > > So, if i can extend our concept a little bit, then: > We can add new table (map_data_tbl for example) that holds a copy of > the original interrupt specifier, index to irq_sources table and > probably some flags. > And we can modify the above workflow to: > - Parent bus enumerates children, allocates entries from map_data_tbl, > adds to resource list. The struct resources involved aren't special > (just a single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are > trivial to implement (and already are implemented, in general, for > OF/FDT drivers). Index to map_data_tbl is used as resource ID. > - bus_alloc_resource() sets 'ALLOCATED' in map_data_tbl flags field, > *maps IRQs* and stores result in 'index' field. > - bus_setup_intr() sets 'SETUP_DONE' in map_data_tbl flags field, calls > into the PIC and does what is needed, as in r301453. (to within that > #ifdef) > > And, in PPC case, newly attached PIC scans whole map_data_tbl table, > finds his entries and makes what needs. > > Does that make sense? > I hope that postponing of map IRQ call is not a problem for PPC, > everything else looks easy. > Moreover, this additional level of indirection also solves all my > 'hypothetical corner cases' with N:1 mappings (between original > interrupt specifier and real interrupt number). Yes, I think we are converging. My qualm about bus_alloc_resource() is twofold: 1. Traditionally, with interrupts, bus_alloc_resource() has no side effects and I'm not sure it propagates cleanly down the tree in all cases. 2. T. , x n nn b n /here are a few bus APIs (bus_config_intr() comes to mind) that use raw IRQ IDs and, so far as I know, can be, and sometimes are called before bus_alloc_resource(). If the PIC doesn't know about the IRQ yet when bus_config_intr() (etc.) is called, things will just break. So you would need to make sure that any bus method handling a resource ID causes it to be mapped on the PIC at that time. It's OK if that happens in bus_alloc_resource() so long as bus_config_intr(), bus_setup_intr(), etc. cause that to happen if it hasn't happened yet -- I don't care when these calls are made to the PIC driver so long as *what* calls will be made is set at enumeration time. I am also totally fine with having, on ARM, bus_config_intr(), bus_setup_intr() etc. fail if the PIC hasn't attached yet (On PowerPC, we can't do that yet, but after this conversation, I regard that as a bug and would fix that later), as well as delaying setup on the PIC to the first time any bus driver actually tries to *use* the interrupt (alloc_resource(), setup_intr(), config_intr(), whatever) rather than when the interrupt is originally allocated. ------------ The following is a large parenthesis ------------------- One other possible route here that would also work well would be to make ofwbus.c MD (it's a trivial piece of code anyway, so we don't gain a lot by sharing it) and implement ofw_bus_map_intr() locally as an ofwbus bus method. Then you could have the mapping table stored in ofwbus's softc -- the API was designed for this initially. You would need MD extensions for doing PIC registration there (which is fine), but that segregates all the OFW-specific information into OFW-specific code and would let the bus methods and the OFW interrupt mapping table interact cleanly in the same place. This still preserves the pre-r301453 API, makes PowerPC work, and maybe address's skra@'s concern about extensibility and letting core interrupt code know about FDT (or ACPI). I'd be happy to mock this up as well if you think it's a good approach. So you would have something in arm/arm/ofwbus.c like (pseudo-code, missing unlocks, etc.): struct ofwbus_softc { (list of PICs) (list of IRQ mapping from # to specifier, iparent, and device_t) } static int ofw_bus_map_if_unmapped(struct ofwbus_softc *sc, int irq) { struct ofw_bus_irq_mapping *i; struct ofw_bus_pic *j; int err = 0; mtx_lock(sc->ofw_bus_irqmap_lock); LIST_FOREACH(i, sc->irq_mappings) { if (i->irq == irq) break; } if (i == NULL) return (ENXIO); /* PANIC? */ if (i->dev != NULL) return (0); /* Mapped already */ LIST_FOREACH(j, sc->ofw_bus_registered_pics) { if (j->phandle == i->phandle) { arm_intr_set_pic(irq, j->dev); err = PIC_SET_OFW_ISPEC(j->dev, i->ispec, i->icells); return (err); } } return (ENXIO); /* No matching PIC. Panic? */ } static int ofw_bus_setup_intr(device_t dev, device_t child, int irq, blah...) { int err; /* This section at the beginning of anything allocating/using/modifying interrupts */ err = ofw_bus_map_if_unmapped(sc, irq); if (err != 0) /* Explode if the PIC isn't online yet return (err); bus_setup_intr(dev, child, irq, blah...); /* onward to nexus */ } This has the following features: - Existing OFW API and semantics unchanged - As such, PowerPC, PCI, etc. work fine with no changes - Details encapsulated in MD code, so individual platforms can implement this however they like - arm/arm/intr.c (or whatever) only needs a method to allocate a fresh interrupt, with no state, and anoter to set the device_t for an interrupt sometime later. - The internal table in the platform interrupt code has no knowledge of any mappings whatsoever except having the appropriate device_t for the PIC stored with the interrupt vector. - Device tree bits handled purely in device tree code - No action need be taken on any mapping until the interrupt is actually allocated/set up, like r301453 - Easy to add more mapping mechanisms (e.g. ACPI) by having similar enumeration-mechanism-specific code in the root bus for that mapping mechanism. -------------- End parenthesis ------------------------------- > `/ > >> Some more comments below. >> >>>> The ideal API would be one in which the resource enumeration code >>>> could assign, instead of numbers, some structured information that >>>> contains the full firmware specifier (string parent + interrupt pin >>>> for ACPI, interrupt parent phandle + specifier for device tree, bare >>>> numbers for simple systems). >>> Yes, exactly. I am happy that at least we agree on something. The only >>> difference is that we want triplet >> specifier> or >> Which makes perfect sense and is a good idea. >> >>>> That seemed, and seems, too invasive. I think we agree on this and >>>> have chosen to approximate that API in two different ways. >>> I still think that we found way how we can realize the above idea in >>> non-invasive way. >>> From my point of view the solution is: >>> Put/attach the above triplet to RLE and then copy it (within >>> bus_resource_attach() to struct resource. >>> But yes, I understand that I am not able to explain clearly enough. >> I think we were just talking past eachother somehow. >> >> Anyway, my concern about putting this in struct resource * at >> bus_alloc_resource() time is basically that there are a whole bunch of >> cases in which (a) it's hard to reverse engineer which interrupt from >> the device tree (or whatever) was meant to correspond to a particular >> arbitrary IRQ in an allocation request unless you keep logs and (b) >> there are a bunch of cases, mostly involving PCI, where interrupt >> resource allocation doesn't proceed through struct resource * at all, >> so you pretty much have to keep logs. Once you start keeping logs of >> which IRQ corresponds to which specifier at the device level, you >> might as well just do it once in a centralized place. > Oki, i agree. o Great, I'm glad we're on the same page. >>> gd ` >>>> When we designed the interrupt mapping code, we evaluated a large >>>> number of possible approaches. Something very much like this was one >>>> of them. It was rejected as being too fragile (it requires resource >>>> allocation and enumeration to be coupled) and to have too many corner >>>> cases (the PCI MSI and LSI APIs, for instance). The interrupt mapping >>>> stuff seemed at the time, and so far still seems, like the least-bad >>>> approximation to the ideal case: it is essentially that ideal API, in >>>> that it happens at bus enumeration and involves just assigning the >>>> firmware specifiers, but with lookup keys to that information stuffed >>>> into the 32-bit numbers that the rest of the system uses. >>> The raw PCI (or MSIX) case is relatively simple. The PCI domain uses >>> raw numbers and it's host-to-pci bridge job to translate raw numbers >>> from PCI domain to (for example) OFW based resource. >>> At this point, I'm still not sure about MSI... >> Right, you can keep a big table in the PCI driver that maps whatever >> IRQs you are handing out to some richer interrupt specifiers and >> consult that when you get a bus_alloc_resource() request. Which is >> basically the approach I'm advocating, except that the table is >> centralized, which reduces code duplication and fixes a number of >> weird corner cases where children assign extra interrupts to >> themselves, etc. and the bus parent has no ability to do something >> sensible. >> >> Please take a look at the attached interface and see if it (or >> something like it) meets your needs. It meets all of mine, at least, >> and I think fixes all the things you were concerned about. > Can you, please, give me also example for GPIO (these are identified by > pair). > Or, in other words, GPIO needs his own sets of functions? You have more experience with GPIOs than I do, but I could imagine a couple different ways of doing this for GPIO interrupts not in standard interrupts properties: 1. You have an extra interrupt class (like r301453) called "GPIO" or something that either takes a OFW/ACPI handle or a device_t and a GPIO specifier. 2. You have some global translator function that makes an OFW/ACPI interrupt specifier out of a GPIO property. I don't like this one. 3. You add a method to the GPIO controller (GPIO_GET_INTERRUPT_FOR_PIN or something) that does something driver specific (e.g. checks if you can have such an interrupt, then fabricates an OF- or ACPI-compatible specifier and maps it) to return a usable IRQ or an error. This also abstracts out how you want to describe the GPIO interrupt domain. Aside from not liking #2, I don't have strong opinions. #1 and #3 aren't mutually exclusive (#3 could be implemented in terms of #1), and #3 seems a little cleaner, so I would have a weak preference for #3 as the canonical mechanism. But anything is OK, really. > And thanks for your effort and patience, Of course -- apologies for being somewhat strident. Thanks for taking the time to discuss this! -Nathan > Michal > > From owner-freebsd-arm@freebsd.org Sun Jul 31 19:21:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D97EBA921A for ; Sun, 31 Jul 2016 19:21:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DA92197B for ; Sun, 31 Jul 2016 19:21:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u6VJLC39056578 for ; Sun, 31 Jul 2016 19:21:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 211484] Zynq/Zybo cannot mount USB drives as root Date: Sun, 31 Jul 2016 19:21:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: thoma555-bsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 19:21:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211484 Bug ID: 211484 Summary: Zynq/Zybo cannot mount USB drives as root Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: thoma555-bsd@yahoo.com Created attachment 173141 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D173141&action= =3Dedit patch to zynq-7000.dtsi A Zynq/Zybo system cannot mount a USB drive/stick as the root filesystem. = The problem is the the ehci driver tries to DMA to a location in the first half megabyte of memory space which has several caveats on Zynq including a hole between 256K-512K that is inaccessible by bus masters. Originally, I tried to avoid something like this happening by starting memo= ry at 0x100000 in the Zynq DTS file. But, ubldr "fixes up" memory ranges using information from u-boot (retrieved by a sysinfo call to the API). That cau= ses the kernel to allocate the first megabyte. The simplest work-around seems to be to add a =E2=80=9Cmemreserve=E2=80=9D = property to the DTS. Also, It turns out that only the first half megabyte needs to be excluded. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Jul 31 19:58:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80621BA987A for ; Sun, 31 Jul 2016 19:58:01 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37FD31746 for ; Sun, 31 Jul 2016 19:58:01 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-yw0-x242.google.com with SMTP id j12so11622565ywb.1 for ; Sun, 31 Jul 2016 12:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RaFTmibxwI0rq8i2xt+oVWeDhmgaULWquoUensb7ezk=; b=VrSmq75or9/lSH//M9bK2zBzC6dO9tV0lnnN2L8gHsrchyQP7TmAf1OoCl7jJ2QJPE Sh7p7wAxcT2THSSlHzWdHS8FTjKybjiBviJfMUa+1hxkGX3/by4rxsp/0gaqJenDibnq CbARhZRa2+OqM8j3a7OkJiDBiHeF6gYOgGY/LFKvKK24UbwR8Wvj2+GcSQY7l5TcdLwI o7TFR/zUXO3RmAph87nxW5qSAIBvGMXNi4Y5/732KnVgCE2Ece+OMhVVxOmW8WNww7aG lNO3h9pHHPuv+NyvFufNdw6C3f7bTYvSiszNmn5UcUplePMTJHq+V4YCBjqOn9M39gQ6 ZBoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RaFTmibxwI0rq8i2xt+oVWeDhmgaULWquoUensb7ezk=; b=mC6Cole7ucwuixitfTGGoJIszeIRsEWqTooyq8HvgYB6CiuJgnh+6sHbzifdOFmzxu wIWkuRSQlsdESSmd4ohxsknqLG19lU4rHP1rHIBXqUBCCid2uRnW7+D9nLrrl5yk/h/q ATAZczpLuYhHitPdGZ5RXwCwpf9aQZAWWQW/2wQhNmV9kfFDkIMdo8AVC5bXdvQyQFKV hdMRBENSms+fqW09T+SR5ZLtlarvKJ/BPQTLZrrxKv4C7oVVUqFcqFhAm/kiMqdtGZvU nHy7DKexRNLYXJhQJ9hYg2nAKmzh0ulA+NPl5OcF9DSYtmItr741xTQjNI9Fq0SVPGsC 3AxA== X-Gm-Message-State: AEkoout303VBRn208apROsz1A+UL4mO34Kg6UISDxerNukxt0NvCCSKqIdfMZsbjGN+Uk7dV/15UTxaN6v8AbA== X-Received: by 10.13.211.195 with SMTP id v186mr39323915ywd.319.1469995080131; Sun, 31 Jul 2016 12:58:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.213.20 with HTTP; Sun, 31 Jul 2016 12:57:59 -0700 (PDT) In-Reply-To: References: <8564a38f541adda22c9aaafa8ed856f0@roundcube.malavon.com> From: Luiz Otavio O Souza Date: Sun, 31 Jul 2016 16:57:59 -0300 Message-ID: Subject: Re: 11.0-BETA2: PWM on Beagle Bone Black kernel panic? To: Benny Goemans Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 19:58:01 -0000 On 31 July 2016 at 08:55, Benny Goemans wrote: > On 31-07-2016 13:17, Benny Goemans wrote: >> All, >> >> I've tried enabling PWM on a Beagle Bone Black (tried both PWM 1 & 2) >> by modifying the DTS. Once I reboot the boot ends with a kernel panic. >> Now, I might simply be doing something wrong which is why I haven't >> created a bug for this yet. I haven't used PWM with FreeBSD in quite a >> long time. >> Kernel output is attached below. No other changes were made to the >> default BETA2 image, downloaded from >> ftp://ftp.freebsd.org/pub/FreeBSD/releases/arm/armv6/ISO-IMAGES/11.0/FreeBSD-11.0-BETA2-arm-armv6-BEAGLEBONE.img.xz). >> [...] > Another thing I just noticed, this does seem to be working correctly > when I disable devd. The clue came from the "Starting devd." right > before the crash of course. I suppose this isn't intented, but at least > there's a possible workaround. This issue was fixed by r302988. I'll ask re@ about the MFC. Luiz From owner-freebsd-arm@freebsd.org Mon Aug 1 01:06:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89E86BA8F1C for ; Mon, 1 Aug 2016 01:06:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79F071633 for ; Mon, 1 Aug 2016 01:06:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7116VKw022309 for ; Mon, 1 Aug 2016 01:06:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 211489] unlabelled interrupts on PI / BBB Date: Mon, 01 Aug 2016 01:06:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-BETA2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: venture37@geeklan.co.uk X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 01:06:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211489 Bug ID: 211489 Summary: unlabelled interrupts on PI / BBB Product: Base System Version: 11.0-BETA2 Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: venture37@geeklan.co.uk When issuing vmstat -i, some interrupt entries have no label, instead there= is just a plus symbol. interrupt number also does not appear in the output of devinfo -u Behaviour observed on 1st gen Raspberry PI model B & BeagleBone Black. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Aug 1 14:51:46 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EFEBBAAB5C for ; Mon, 1 Aug 2016 14:51:46 +0000 (UTC) (envelope-from benny.goemans@belgacom.net) Received: from mailsec110.isp.belgacom.be (mailsec110.isp.belgacom.be [195.238.20.106]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F24191EAC for ; Mon, 1 Aug 2016 14:51:45 +0000 (UTC) (envelope-from benny.goemans@belgacom.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CnBAANYZ9X/9HaUlFdhRe5E4F9hh0Cg?= =?us-ascii?q?WYSAQEBAQEBAV0nhF8BBTgCPxAEBxgcElcGG4gtwEgBAQEBBgIBJIYqhE2KGwE?= =?us-ascii?q?EmTOBYI0Yj0aMMIN3JQwjg3w6MgEBAYgSAQEB?= Received: from d5152dad1.static.telenet.be (HELO roundcube.malavon.com) ([81.82.218.209]) by relay.skynet.be with ESMTP/TLS/DHE-RSA-AES128-SHA; 01 Aug 2016 16:50:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 01 Aug 2016 16:50:33 +0200 From: Benny Goemans To: Luiz Otavio O Souza Cc: freebsd-arm@freebsd.org Subject: Re: 11.0-BETA2: PWM on Beagle Bone Black kernel panic? In-Reply-To: References: <8564a38f541adda22c9aaafa8ed856f0@roundcube.malavon.com> Message-ID: <24212ba41752cf3b8fa4e5da01b4a7d5@roundcube.malavon.com> X-Sender: benny.goemans@belgacom.net User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 14:51:46 -0000 Luiz Otavio O Souza schreef op 2016-07-31 21:57: > On 31 July 2016 at 08:55, Benny Goemans wrote: >> On 31-07-2016 13:17, Benny Goemans wrote: >>> All, >>> >>> I've tried enabling PWM on a Beagle Bone Black (tried both PWM 1 & 2) >>> by modifying the DTS. Once I reboot the boot ends with a kernel >>> panic. >>> Now, I might simply be doing something wrong which is why I haven't >>> created a bug for this yet. I haven't used PWM with FreeBSD in quite >>> a >>> long time. >>> Kernel output is attached below. No other changes were made to the >>> default BETA2 image, downloaded from >>> ftp://ftp.freebsd.org/pub/FreeBSD/releases/arm/armv6/ISO-IMAGES/11.0/FreeBSD-11.0-BETA2-arm-armv6-BEAGLEBONE.img.xz). >>> > [...] >> Another thing I just noticed, this does seem to be working correctly >> when I disable devd. The clue came from the "Starting devd." right >> before the crash of course. I suppose this isn't intented, but at >> least >> there's a possible workaround. > > This issue was fixed by r302988. I'll ask re@ about the MFC. > > Luiz Good to know. If I find the time to do a full rebuild I'll test that patch as well. Aside from that everything seems to be working correctly on the BBB, at least the parts that I tested during the weekend. Benny From owner-freebsd-arm@freebsd.org Mon Aug 1 19:59:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21CF4BABE01; Mon, 1 Aug 2016 19:59:37 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 155751D62; Mon, 1 Aug 2016 19:59:37 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2884F20E; Mon, 1 Aug 2016 19:59:37 +0000 (UTC) Date: Mon, 1 Aug 2016 19:59:34 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: sbruno@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1951219281.89.1470081577172.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1570723866.87.1470070449588.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1570723866.87.1470070449588.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_STABLE_11-arm64 - Build #65 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_STABLE_11-arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 19:59:37 -0000 FreeBSD_STABLE_11-arm64 - Build #65 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_11-arm64/65/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_11-arm64/65/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_11-arm64/65/console Change summaries: 303628 by sbruno: MFC r303322,303326,303327,303345,303413,303416,303418,303557 Update iwm(4) and iwmfw(4) to current in order to stabilize and improve functionality. Approved by: re (gjb) From owner-freebsd-arm@freebsd.org Tue Aug 2 04:00:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1BF7BAC75D; Tue, 2 Aug 2016 04:00:57 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3DB31779; Tue, 2 Aug 2016 04:00:57 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net ([172.58.136.26]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u7240dAU032222 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Aug 2016 21:00:43 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: Date: Mon, 1 Aug 2016 21:00:37 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> Content-Type: multipart/mixed; boundary="------------B09F4E0CEA3FCACA621BF022" X-Sonic-CAuth: UmFuZG9tSVYN5MKl+H41n8ajRjvdGOkQE8VGoD/VmZXpxyHhNF4SVvgYCM7BQ/S1DAiSzD8cnqftsu2pF7kZe70ehtwuBVerc8oh6Yssfdg= X-Sonic-ID: C;EvrDrGVY5hG9zq/hcgQksw== M;ij3trmVY5hG9zq/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 04:00:58 -0000 This is a multi-part message in MIME format. --------------B09F4E0CEA3FCACA621BF022 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 07/31/16 11:43, Nathan Whitehorn wrote: > > > On 07/31/16 08:40, Michal Meloun wrote: >> Dne 31.07.2016 v 8:11 Nathan Whitehorn napsal(a): >> [snip] >>>> The current API is certainly a bit of a hack and I would be pleased to >>>>> see it go; but the replacement needs to be more functional and more >>>>> robust. As far as I can tell, I literally *cannot* move PowerPC over >>>>> to this architecture. >>>> Yes, at this time, I agree. If you can accept enhancement of >>>> (owf_)bus_map_intr() then we can move to next, significantly less >>>> hackish, state. >>> OK, sure. I wrote some code this afternoon (attached) to sketch this. >>> It does not compile or run or anything useful, but it should >>> illustrate the important parts of what I think is an API that should >>> work for everyone. I'm happy to finish it if it looks reasonable -- I >>> may in any case just to replace PowerPC's increasingly teetering >>> intr_machdep.c. >>> >>> The OF part is essentially unchanged from how it currently works: >>> there's a method that you pass the interrupt specifier and interrupt >>> parent to, and it spits back an IRQ that means that combination of >>> things in perpetuity. OFW_BUS_MAP_INTR() in nexus.c, with its current >>> API, can be implemented in terms of it in one line. Whenever the >>> relevant PIC attaches, it is told to use the given IRQ to refer to >>> that opaque bytestring. >>> >>> I've added a set of equivalent functions for ACPI that take the >>> contents of an ACPI interrupt specifier and do the same things. It >>> tries to have the IRQ be human-meaningful, if possible, by matching >>> the ACPI interrupt number. Having separate functions seemed a little >>> cleaner than exposing the enums and unions as part of the KPI, but I'm >>> not wedded to it -- this is just an example. >>> >>> PICs register (and deregister) themselves with either an OF phandle or >>> an ACPI resource string or (god help us) both as needed. The PICs have >>> corresponding methods for interpreting various kinds of interrupt >>> specifiers. >>> >>> Whether it allows bus_alloc_resource(), bus_setup_intr(), etc. to >>> succeed before the PICs are attached is gated on an #ifdef. That can >>> probably be off by default on ARM. A PowerPC version of this code >>> would have to keep it on until various bus drivers are fixed. >>> >>> Here's the general flow: >>> - Parent bus enumerates children, maps IRQs as needed, adds to >>> resource list. The struct resources involved aren't special (just a >>> single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are trivial to >>> implement (and already are implemented, in general, for OF/FDT >>> drivers). >>> - bus_alloc_resource() does nothing special >>> - bus_setup_intr() calls into the PIC and does what is needed, as in >>> r301453 (to within that #ifdef) >>> >>> This should keep all the best pieces of everything: >>> - ACPI and OF are supported together, and easy to extend for other >>> types of mapping technologies without breaking either KBI or KPI (just >>> add new functions) >>> - No APIs change for existing Open Firmware code >>> - The support code can live entirely in machine-dependent directories, >>> with no code changes at all required in kern/ or dev/ofw/ >>> - bus_setup_intr() and friends behave as in r301453 and succeed or >>> fail for real >>> - PCI code is not an issue >>> - No disconnected interrupt state maintained in mapping table (unless >>> the transitional #ifdef is on) and the mapping table content is only >>> larger than r301453 by having a copy of the original interrupt >>> specifier. >>> >>> If and when we manage to fix the kernel APIs to allow non-scalar >>> interrupt specifiers, this should also be easy to gradually >>> transmogrify to support that case since there exists a 1:1 mapping of >>> scalar IRQs to rich data and the control flow would be identical: >>> interrupt specifiers are read at enumeration time and a resulting >>> handle -- struct resource or scalar IRQ -- used afterward to refer >>> to it. >>> >> Nice, nice, i think that we are very close at this point. >> The problem with the above workflow is that maps IRQ function is called >> at parent bus enumeration time, generally at BUS_PASS_BUS pass. And at >> this time, PICs are not exist. >> Also, 'static struct intr_irqsrc *irq_sources[NIRQ];' is not a mapping >> table, it doesn't provide this functionality. >> But yes, i understand that mapping table is important and necessary >> for you. >> >> So, if i can extend our concept a little bit, then: >> We can add new table (map_data_tbl for example) that holds a copy of >> the original interrupt specifier, index to irq_sources table and >> probably some flags. >> And we can modify the above workflow to: >> - Parent bus enumerates children, allocates entries from map_data_tbl, >> adds to resource list. The struct resources involved aren't special >> (just a single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are >> trivial to implement (and already are implemented, in general, for >> OF/FDT drivers). Index to map_data_tbl is used as resource ID. >> - bus_alloc_resource() sets 'ALLOCATED' in map_data_tbl flags field, >> *maps IRQs* and stores result in 'index' field. >> - bus_setup_intr() sets 'SETUP_DONE' in map_data_tbl flags field, calls >> into the PIC and does what is needed, as in r301453. (to within that >> #ifdef) >> >> And, in PPC case, newly attached PIC scans whole map_data_tbl table, >> finds his entries and makes what needs. >> >> Does that make sense? >> I hope that postponing of map IRQ call is not a problem for PPC, >> everything else looks easy. >> Moreover, this additional level of indirection also solves all my >> 'hypothetical corner cases' with N:1 mappings (between original >> interrupt specifier and real interrupt number). > > Yes, I think we are converging. > > My qualm about bus_alloc_resource() is twofold: > 1. Traditionally, with interrupts, bus_alloc_resource() has no side > effects and I'm not sure it propagates cleanly down the tree in all > cases. > 2. T. , x n nn b > n /here are a few bus APIs (bus_config_intr() comes to mind) that > use raw IRQ IDs and, so far as I know, can be, and sometimes are > called before bus_alloc_resource(). If the PIC doesn't know about the > IRQ yet when bus_config_intr() (etc.) is called, things will just break. > > So you would need to make sure that any bus method handling a resource > ID causes it to be mapped on the PIC at that time. It's OK if that > happens in bus_alloc_resource() so long as bus_config_intr(), > bus_setup_intr(), etc. cause that to happen if it hasn't happened yet > -- I don't care when these calls are made to the PIC driver so long as > *what* calls will be made is set at enumeration time. > > I am also totally fine with having, on ARM, bus_config_intr(), > bus_setup_intr() etc. fail if the PIC hasn't attached yet (On PowerPC, > we can't do that yet, but after this conversation, I regard that as a > bug and would fix that later), as well as delaying setup on the PIC to > the first time any bus driver actually tries to *use* the interrupt > (alloc_resource(), setup_intr(), config_intr(), whatever) rather than > when the interrupt is originally allocated. > > ------------ The following is a large parenthesis ------------------- > > One other possible route here that would also work well would be to > make ofwbus.c MD (it's a trivial piece of code anyway, so we don't > gain a lot by sharing it) and implement ofw_bus_map_intr() locally as > an ofwbus bus method. Then you could have the mapping table stored in > ofwbus's softc -- the API was designed for this initially. You would > need MD extensions for doing PIC registration there (which is fine), > but that segregates all the OFW-specific information into OFW-specific > code and would let the bus methods and the OFW interrupt mapping table > interact cleanly in the same place. This still preserves the > pre-r301453 API, makes PowerPC work, and maybe address's skra@'s > concern about extensibility and letting core interrupt code know about > FDT (or ACPI). I'd be happy to mock this up as well if you think it's > a good approach. > [snip] > > This has the following features: > - Existing OFW API and semantics unchanged > - As such, PowerPC, PCI, etc. work fine with no changes > - Details encapsulated in MD code, so individual platforms can > implement this however they like > - arm/arm/intr.c (or whatever) only needs a method to allocate a fresh > interrupt, with no state, and anoter to set the device_t for an > interrupt sometime later. > - The internal table in the platform interrupt code has no knowledge > of any mappings whatsoever except having the appropriate device_t for > the PIC stored with the interrupt vector. > - Device tree bits handled purely in device tree code > - No action need be taken on any mapping until the interrupt is > actually allocated/set up, like r301453 > - Easy to add more mapping mechanisms (e.g. ACPI) by having similar > enumeration-mechanism-specific code in the root bus for that mapping > mechanism. > > -------------- End parenthesis ------------------------------- Here's an implementation of the parenthesis I wrote on an airplane this afternoon. It should be complete, though has not been tested. The code is short and simple (+70 lines in ofwbus.c). This preserves the pre-r301453 API and semantics relative to drivers, which means PowerPC and PCI work out of the box, while keeping the semantics relative to the interrupt layer of r301453 (PIC methods only called on resource allocation, no allocatable IRQs on unattached PICs, encapsulation of OFW-specific code in OFW-specific bits of the tree). It turns out those two things are compatible, somewhat to my surprise, and that makes the result very clean. I like this approach and would be happy to move forward with it. There are five functions of interest: 1. OFW_BUS_MAP_INTR(). This has the semantics and API it has now: you pass an interrupt specifier and parent, you get back an IRQ. No changes. This is the core of the normal OFW interrupt API. 2. OFW_BUS_REGISTER_PIC(device_t pic, phandle_t phandle). This is a new function that PIC drivers are supposed to use to register control of an interrupt domain. This replaces machine-specific code like powerpc_register_pic() to allow the PIC table to be in a bus parent rather than in the interrupt core. 3. PIC_MAP_OFW_INTR(device_t pic, int irq, interrupt specifier). This is a new function that PIC drivers that know how to handle device-tree interrupt descriptors implement (analogous to various existing ones that vary by platform). It tells the PIC that the given abstract IRQ means the given opaque interrupt specifier. 4. arm_allocate_irq(int suggested). This allocates a new IRQ number not (yet) attached to a PIC, as in r301453. I've added a parameter that lets you pass a suggested number to try in case it is possible to make it match an interrupt pin or something for human-readability. 5. arm_set_pic_for_irq(int irq, device_t). This tells the MD interrupt layer to associate a given PIC device_t with an IRQ. That is all the information the MD layer ever has about the IRQ mapping. Functions #1 and #2 are now implemented completely in ofwbus.c: there are no callouts anywhere else and the interrupt mapping table is maintained entirely internally to ofwbus (in its softc). In order to implement ACPI, or some other strategy, you would implement analogs to functions #1 and #2 that live somewhere in the bus hierarchy that is guaranteed to be above all devices that might want that type of interrupt (e.g. in acpi0), and some analog to #3 that PIC drivers implementing the mapping scheme would provide. Since the system interrupt code has no knowledge at all of interrupt mapping, of any type, in this scheme, adding new mapping types is trivial and can be done on a driver-by-driver basis if necessary without changing KPI and without any other part of the system even being aware. For example, GPIOs can use a completely different mechanism if they want and can do setup purely in the GPIO controller driver. You could have a method GPIO_GET_INTERRUPT_FOR_PIN() on a GPIO controller in which the GPIO controller allocates a generic IRQ, assigns through some internal table just in the GPIO driver, and returns to it to a consumer in some other device driver -- without a GPIO mapping type, new bus functions, or modifications to the platform interrupt code. The control flow goes like this: - Bus driver enumerates children, parses interrupts properties, calls OFW_BUS_MAP_INTR() to get IRQs for them (as pre-r301453), adds to interrupt list. - ofwbus receives the OFW_BUS_MAP_INTR() call, allocates a blank disconnected IRQ from the MD interrupt layer, and stores the mapping from the new IRQ to the given interrupt specifier and phandle in an internal table in ofwbus's softc. NB: Nothing else happens here, like post-r301453. Changing this does not change any semantics of the API pre-r301453, which means it remains fully compatible with PCI and PowerPC. Also, like post-r301453, there is no involvement of nexus. - PICs attach and call OFW_BUS_REGISTER_PIC(). ofwbus receives these messages and adds a (device_t, phandle_t) mapping to a second internal table. Note that the interrupt layer does not need to handle PIC registration anymore at all (except for the root PIC). - Bus child eventually calls a function that tries to set the interrupt up (e.g. bus_setup_intr()). That propagates up the bus hierarchy, eventually getting to ofwbus. ofwbus notes the IRQ number, looks it up in the table, looks up the appropriate PIC from the PIC table, then: A) calls arm_set_pic_for_irq(irq, pic_device_t) -- this is the interrupt layer's only interaction with the mapping code. All it deals with is device_ts and abstract IRQ numbers. B) calls PIC_MAP_OFW_INTR(pic, irq_number, interrupt-cells, interrupt-specifier) to tell the PIC that the interrupt layer's IRQ irq_number means the given specifier C) finally, passes the call onto nexus, which will do whatever would normally happen (unmasking the interrupt, setting handlers, etc.) in terms only of the abstract IRQ and the device_t assigned by ofwbus. You would implement ACPI just by doing a s/OFW/ACPI/g search-and-replace above -- since the interrupt layer doesn't know about OFW or ACPI or anything else, there is no need to touch it. This seems clean, simple, compartmentalized, preserves the existing API, and should work on all of our various hardware. PowerPC can't quite work with it yet without some multipass foo, but, since the API is preserved, that transition can happen gradually without KPI changes. For the same reason that it is API-preserving, I think this code is also MFC-able. -Nathan --------------B09F4E0CEA3FCACA621BF022 Content-Type: text/plain; charset=UTF-8; name="ofwbus.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ofwbus.c" /*- * Copyright 2016 Nathan Whitehorn * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * */ #include #include #include #include #include #include #include #include #include #include #include #include /* * The ofwbus forms the root of the OF bus hierarchy and binds the device tree * "/" node to newbus. Since the root node has most of the same bindings and * semantics as the FDT simplebus, this inherits from it. It adds termination * of some resource requests, notably interrupt mapping, that cannot be pushed * further down the bus hierarchy. */ struct ofwbus_intrtabent { int irq; device_t pic; phandle_t iparent; pcell_t *ispec; int icells; SLIST_ENTRY(ofwbus_intrtabent) entry; }; struct ofwbus_pic { phandle_t phandle; device_t dev; SLIST_ENTRY(ofwbus_pic) entry; }; struct ofwbus_softc { struct simplebus_softc simplebus_sc; struct rman intr_rman; struct rman mem_rman; struct mtx intr_tab_lock; SLIST_HEAD(ofwbus_intrtabs, ofwbus_intrtabent) intr_tab; SLIST_HEAD(ofwbus_pics, ofwbus_pic) pic_tab; }; #ifndef __aarch64__ static device_identify_t ofwbus_identify; #endif static device_probe_t ofwbus_probe; static device_attach_t ofwbus_attach; static bus_alloc_resource_t ofwbus_alloc_resource; static bus_adjust_resource_t ofwbus_adjust_resource; static bus_release_resource_t ofwbus_release_resource; static bus_bind_intr_t ofwbus_bind_intr; static bus_config_intr_t ofwbus_config_intr; static bus_setup_intr_t ofwbus_setup_intr; static ofw_bus_map_intr_t ofwbus_ofw_map_intr; static ofw_bus_register_pic_t ofwbus_register_pic; /* Register IRQs with PIC if not done yet */ static int ofwbus_setup_irq_with_pic(device_t dev, int irq); static device_method_t ofwbus_methods[] = { /* Device interface */ #ifndef __aarch64__ DEVMETHOD(device_identify, ofwbus_identify), #endif DEVMETHOD(device_probe, ofwbus_probe), DEVMETHOD(device_attach, ofwbus_attach), /* Bus interface */ DEVMETHOD(bus_alloc_resource, ofwbus_alloc_resource), DEVMETHOD(bus_adjust_resource, ofwbus_adjust_resource), DEVMETHOD(bus_release_resource, ofwbus_release_resource), /* ofw_bus interface */ DEVMETHOD(ofw_bus_map_intr, ofwbus_map_intr) DEVMETHOD(ofw_bus_register_pic, ofwbus_register_pic) DEVMETHOD_END }; DEFINE_CLASS_1(ofwbus, ofwbus_driver, ofwbus_methods, sizeof(struct ofwbus_softc), simplebus_driver); static devclass_t ofwbus_devclass; EARLY_DRIVER_MODULE(ofwbus, nexus, ofwbus_driver, ofwbus_devclass, 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); MODULE_VERSION(ofwbus, 1); #ifndef __aarch64__ static void ofwbus_identify(driver_t *driver, device_t parent) { /* Check if Open Firmware has been instantiated */ if (OF_peer(0) == 0) return; if (device_find_child(parent, "ofwbus", -1) == NULL) BUS_ADD_CHILD(parent, 0, "ofwbus", -1); } #endif static int ofwbus_probe(device_t dev) { #ifdef __aarch64__ if (OF_peer(0) == 0) return (ENXIO); #endif device_set_desc(dev, "Open Firmware Device Tree"); return (BUS_PROBE_NOWILDCARD); } static int ofwbus_attach(device_t dev) { struct ofwbus_softc *sc; phandle_t node; struct ofw_bus_devinfo obd; sc = device_get_softc(dev); node = OF_peer(0); /* * If no Open Firmware, bail early */ if (node == -1) return (ENXIO); /* * Allocate root rmans for ofwbus. */ sc->sc_intr_rman.rm_type = RMAN_ARRAY; sc->sc_intr_rman.rm_descr = "Interrupts"; sc->sc_mem_rman.rm_type = RMAN_ARRAY; sc->sc_mem_rman.rm_descr = "Device Memory"; if (rman_init(&sc->sc_intr_rman) != 0 || rman_init(&sc->sc_mem_rman) != 0 || rman_manage_region(&sc->sc_intr_rman, 0, ~0) != 0 || rman_manage_region(&sc->sc_mem_rman, 0, BUS_SPACE_MAXADDR) != 0) panic("%s: failed to set up rmans.", __func__); /* * Init interrupt mapping table */ SLIST_INIT(&sc->pic_tab); SLIST_INIT(&sc->intr_tab); mtx_init(&sc->intr_tab_lock, "ofwbus intr", NULL, MTX_DEF); /* * This is the root of the tree, so simplebus_attach() will fail * when it asks our parent (nexus) for its OFW node. Pass node to * simplebus_init directly. */ simplebus_init(dev, node); /* * Now walk the OFW tree and attach top-level devices. */ for (node = OF_child(node); node > 0; node = OF_peer(node)) simplebus_add_device(dev, node, 0, NULL, -1, NULL); return (bus_generic_attach(dev)); } static struct resource * ofwbus_alloc_resource(device_t bus, device_t child, int type, int *rid, rman_res_t start, rman_res_t end, rman_res_t count, u_int flags) { struct ofwbus_softc *sc; struct rman *rm; struct resource *rv; struct resource_list_entry *rle; int isdefault, passthrough, err; isdefault = RMAN_IS_DEFAULT_RANGE(start, end); passthrough = (device_get_parent(child) != bus); sc = device_get_softc(bus); rle = NULL; if (!passthrough && isdefault) { rle = resource_list_find(BUS_GET_RESOURCE_LIST(bus, child), type, *rid); if (rle == NULL) { if (bootverbose) device_printf(bus, "no default resources for " "rid = %d, type = %d\n", *rid, type); return (NULL); } start = rle->start; count = ummax(count, rle->count); end = ummax(rle->end, start + count - 1); } switch (type) { case SYS_RES_IRQ: rm = &sc->sc_intr_rman; break; case SYS_RES_MEMORY: rm = &sc->sc_mem_rman; break; default: return (NULL); } rv = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE, child); if (rv == NULL) return (NULL); rman_set_rid(rv, *rid); if ((flags & RF_ACTIVE) != 0 && bus_activate_resource(child, type, *rid, rv) != 0) { rman_release_resource(rv); return (NULL); } if (!passthrough && rle != NULL) { rle->res = rv; rle->start = rman_get_start(rv); rle->end = rman_get_end(rv); rle->count = rle->end - rle->start + 1; } return (rv); } static int ofwbus_adjust_resource(device_t bus, device_t child __unused, int type, struct resource *r, rman_res_t start, rman_res_t end) { struct ofwbus_softc *sc; struct rman *rm; device_t ofwbus; ofwbus = bus; while (strcmp(device_get_name(device_get_parent(ofwbus)), "root") != 0) ofwbus = device_get_parent(ofwbus); sc = device_get_softc(ofwbus); switch (type) { case SYS_RES_IRQ: rm = &sc->sc_intr_rman; break; case SYS_RES_MEMORY: rm = &sc->sc_mem_rman; break; default: return (EINVAL); } if (rm == NULL) return (ENXIO); if (rman_is_region_manager(r, rm) == 0) return (EINVAL); return (rman_adjust_resource(r, start, end)); } static int ofwbus_release_resource(device_t bus, device_t child, int type, int rid, struct resource *r) { struct resource_list_entry *rle; int passthrough; int error; passthrough = (device_get_parent(child) != bus); if (!passthrough) { /* Clean resource list entry */ rle = resource_list_find(BUS_GET_RESOURCE_LIST(bus, child), type, rid); if (rle != NULL) rle->res = NULL; } if ((rman_get_flags(r) & RF_ACTIVE) != 0) { error = bus_deactivate_resource(child, type, rid, r); if (error) return (error); } return (rman_release_resource(r)); } static int ofwbus_map_intr(device_t dev, device_t child, phandle_t iparent, int icells, pcell_t *ispec) { struct ofwbus_intrtabent *intr; struct ofwbus_softc *sc; sc = device_get_softc(dev); mtx_lock(&sc->intr_tab_lock); SLIST_FOREACH(intr, &sc->intr_tab, entry) { if (intr->iparent != iparent) continue; if (intr->icells != icells) continue; if (memcmp(ispec, intr->ispec, sizeof(*ispec)*icells) == 0) break; } if (intr == NULL) { intr = malloc(sizeof(*intr), M_DEVBUF, M_ZERO | M_WAITOK); intr->iparent = iparent; intr->icells = icells; intr->ispec = malloc(sizeof(*ispec)*icells, M_DEVBUF, M_WAITOK); memcpy(intr->ispec, ispec, sizeof(*ispec)*icells); /* * Try to set ispec[0] as the IRQ ID. This is often the * interrupt pin on the PIC, so getting that as the IRQ ID * makes dmesg a little more human-friendly and consistent. No * big deal if that fails and we get something random, though. */ intr->irq = arm_allocate_irq(ispec[0]); SLIST_INSERT_HEAD(&sc->intr_tab, intr, entry); } mtx_unlock(&sc->intr_tab_lock); /* Entries never deleted, so safe */ return (intr->irq); } static int ofwbus_register_pic(device_t dev, device_t pic, phandle_t phandle) { struct ofwbus_pic *picent; struct ofwbus_softc *sc; sc = device_get_softc(dev); mtx_lock(&sc->intr_tab_lock); SLIST_FOREACH(picent, &sc->pic_tab, entry) { if (picent->phandle == phandle) panic("PIC %#x already registered as %s", phandle, device_get_nameunit(picent->dev)); } picent = malloc(sizeof(*picent), M_DEVBUF, M_ZERO | M_WAITOK); picent->phandle = phandle; picent->dev = dev; SLIST_INSERT_HEAD(&sc->pic_tab, picent, entry); mtx_unlock(&sc->intr_tab_lock); return (0); } static int ofwbus_setup_irq_with_pic(device_t dev, int irq) { struct ofwbus_intrtabent *intr; struct ofwbus_pic *picent; struct ofwbus_softc *sc; int err = 0; sc = device_get_softc(dev); mtx_lock(&sc->intr_tab_lock); SLIST_FOREACH(intr, &sc->intr_tab, entry) { if (intr->irq == irq) break; } KASSERT(intr != NULL, ("Setting up unmapped IRQ %d", irq)); if (intr->pic == NULL) { SLIST_FOREACH(picent, &sc->pic_tab, entry) { if (picent->phandle == intr->phandle) break; } if (picent == NULL) panic("Mapping IRQ %d to non-existant PIC %#x", irq, intr->phandle); intr->pic = picent->dev; /* * NB: this ordering is safe so long as the MD interrupt * code never iterates through all interrupts and calls PIC * methods on them: * 1. No bus code (bus_config_intr()), etc. can happen until * this function releases intr_tab_lock. * 2. The PIC can't fire the interrupt until PIC_MAP_OFW_IRQ() * at the very least (hopefully the PIC brings it up masked * anyway and the MD code unmasks later). */ arm_set_pic_for_irq(intr->irq, intr->pic); err = PIC_MAP_OFW_IRQ(intr->pic, intr->irq, intr->icells, intr->ispec); if (err != 0) intr->pic = NULL; } mtx_unlock(&sc->intr_tab_lock); return (err); } static int ofwbus_setup_intr(device_t dev, device_t child, struct resource *r, int flags, driver_filter_t *filt, driver_intr_t *intr, void *arg, void **cookiep) { struct ofwbus_softc *sc = device_get_softc(dev); int err; if (r == NULL) panic("%s: NULL interrupt resource!", __func__); /* Make sure we're good to go */ err = ofwbus_setup_irq_with_pic(rman_get_start(r)); if (err != 0) return (err); return (BUS_SETUP_INTR(device_get_parent(dev), child, r, flags, filt, intr, arg, cookiep)); } static int ofwbus_bind_intr(device_t dev, device_t child, struct resource *r, int cpu) { struct ofwbus_softc *sc = device_get_softc(dev); int err; if (r == NULL) panic("%s: NULL interrupt resource!", __func__); /* Make sure we're good to go */ err = ofwbus_setup_irq_with_pic(rman_get_start(r)); if (err != 0) return (err); return (BUS_BIND_INTR(device_get_parent(dev), child, r, cpu)); } static int ofwbus_config_intr(device_t dev, int irq, enum intr_trigger trig, enum intr_polarity pol) { struct ofwbus_softc *sc = device_get_softc(dev); int err; /* Make sure we're good to go */ err = ofwbus_setup_irq_with_pic(irq) if (err != 0) return (err); return (BUS_CONFIG_INTR(device_get_parent(dev), irq, trig, pol)); } --------------B09F4E0CEA3FCACA621BF022 Content-Type: text/plain; charset=UTF-8; name="ofwdiff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ofwdiff" Index: dev/ofw/ofw_bus.h =================================================================== --- dev/ofw/ofw_bus.h (revision 303312) +++ dev/ofw/ofw_bus.h (working copy) @@ -76,4 +76,10 @@ return (OFW_BUS_MAP_INTR(dev, dev, iparent, icells, intr)); } +static __inline int +ofw_bus_register_pic(device_t dev, phandle_t phandle) +{ + return (OFW_BUS_REGISTER_PIC(dev, dev, phandle)); +} + #endif /* !_DEV_OFW_OFW_BUS_H_ */ Index: dev/ofw/ofw_bus_if.m =================================================================== --- dev/ofw/ofw_bus_if.m (revision 303312) +++ dev/ofw/ofw_bus_if.m (working copy) @@ -113,8 +113,23 @@ /* If that fails, then assume a one-domain system */ return (interrupt[0]); } + + int + ofw_bus_default_register_pic(device_t bus, device_t dev, + phandle_t phandle) + { + /* Propagate up the bus hierarchy until someone handles it. */ + if (device_get_parent(bus) != NULL) + return OFW_BUS_REGISTER_PIC(device_get_parent(bus), dev, + phandle); + + /* If that fails, then it doesn't matter, I guess */ + return (0); + } }; +}; + # Get the ofw_bus_devinfo struct for the device dev on the bus. Used for bus # drivers which use the generic methods in ofw_bus_subr.c to implement the # reset of this interface. The default method will return NULL, which means @@ -159,9 +174,9 @@ device_t dev; } DEFAULT ofw_bus_default_get_type; -# Map an (interrupt parent, IRQ) pair to a unique system-wide interrupt number. -# If the interrupt encoding includes a sense field, the interrupt sense will -# also be configured. +# Map an (interrupt parent, interrupt specifier) pair to a unique system-wide +# interrupt number. If the interrupt encoding includes metadata (sense field, +# for example) that will be passed to the PIC at bring-up. METHOD int map_intr { device_t bus; device_t dev; @@ -169,3 +184,11 @@ int icells; pcell_t *interrupt; } DEFAULT ofw_bus_default_map_intr; + +# Register a device as handling interrupts for a given interrupt-parent value. +METHOD int register_pic { + device_t bus; + device_t dev; + phandle_t phandle; +} DEFAULT ofw_bus_default_register_pic; + Index: powerpc/powerpc/nexus.c =================================================================== --- powerpc/powerpc/nexus.c (revision 303312) +++ powerpc/powerpc/nexus.c (working copy) @@ -72,6 +72,7 @@ #endif static bus_config_intr_t nexus_config_intr; static ofw_bus_map_intr_t nexus_ofw_map_intr; +static ofw_bus_register_pic_t nexus_ofw_register_pic; static device_method_t nexus_methods[] = { /* Device interface */ @@ -92,6 +93,7 @@ /* ofw_bus interface */ DEVMETHOD(ofw_bus_map_intr, nexus_ofw_map_intr), + DEVMETHOD(ofw_bus_register_pic, nexus_ofw_register_pic), DEVMETHOD_END }; @@ -193,6 +195,15 @@ } static int +nexus_ofw_register_pic(device_t dev, device_t pic, phandle_t phandle) +{ + + /* XXX: make up random numbers until intr_machdep.c is updated */ + powerpc_register_pic(pic, phandle, 124, 4, FALSE); + return (0); +} + +static int nexus_activate_resource(device_t bus __unused, device_t child __unused, int type, int rid __unused, struct resource *r) { --------------B09F4E0CEA3FCACA621BF022-- From owner-freebsd-arm@freebsd.org Tue Aug 2 09:24:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46459BAC486 for ; Tue, 2 Aug 2016 09:24:33 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4AA1177C for ; Tue, 2 Aug 2016 09:24:32 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id f65so400850405wmi.0 for ; Tue, 02 Aug 2016 02:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=uYnnwTsR8H2tG7zSjgxSz1Paad9LBak1y0OB1edClBo=; b=NxyL38ibN0RYfxLWIaNI43HgQca+V7zwFRFp1blteyV83mzffQ81d5aUJgthPt7SN2 o25bCi4eiFWWs6c+wCJTgoxDGywN/Vol2Cz1UVLv9khFBDY19MrGth2Op66yfXgjitBq 1VvkH9xRZm/ncRar5uN5GkVt0655Ng6GG3FOSecHZUtOPQDZRWuiiRGzsVkSL8J6pP+t vXN+muzaoZ/I5WRMr1Hd3NcC2UtTsn/k+g0XfH1AXPwMat7tvGjIq8TTCaWXoZ8lLZwy Xi69zJ0GLoHSVe9+TwEQ91Nvb35QBQlNbqvwvQfXQXf80jplfQwd56bXYeGcldrSrfLC Xz5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=uYnnwTsR8H2tG7zSjgxSz1Paad9LBak1y0OB1edClBo=; b=DA0F/VYVjuHgpKLV/TaqvdsKjZ6rQx8wOadH3SEyjZV5zup9RRv/cPW5InF/dRWkxh bpW0GehCpz1ky0Mp144CMjqzCr3/G7N8fSjPdzTcYMAU/2ynuiC+PykfcLEk7wtZPqP0 pUTM2i5t4O2CbUD0esINOT19n/s+0CxHSTyrhCaZOy0YaX++4LPKcS74yvXvBiNgdmAx mgvBT3jQanw7Av9C6clszR7VF87eyOZU6eQuJhoue7zdmGv/Yb/piZVtlJVF7dYs185d 74k0YVPGPJZVZxSCngjvviS0Nf5WsXYqqQa+ore2J9CBKgnBma5B71U8Ga4NG2drx3c/ n/HQ== X-Gm-Message-State: AEkoouvNSdBzPfMAYFzZWpxkG/aayWW1KnKcTQM365F5fISmIJgZXt4XyKjlI015eVmkEA== X-Received: by 10.28.72.139 with SMTP id v133mr62389428wma.32.1470129871021; Tue, 02 Aug 2016 02:24:31 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:415c:5921:236:4373? ([2001:1620:ff0:c51:415c:5921:236:4373]) by smtp.gmail.com with ESMTPSA id s6sm1645488wjm.25.2016.08.02.02.24.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2016 02:24:30 -0700 (PDT) Reply-To: mattia.rossi.mailinglists@gmail.com To: freebsd-arm@freebsd.org From: Mattia Rossi Subject: Allwinner H3 - OrangePi Plus Status Message-ID: <64ad8272-a97f-e51f-19f1-d37e12c4e4bf@gmail.com> Date: Tue, 2 Aug 2016 11:24:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 09:24:33 -0000 Hi all, given that I have one of those things to play with, I wanted to ask what the status is these days? I figured that Ethernet support is working but just missing in U-Boot, video seems not to work yet (but I don't care) and as usual WiFi is not working, as there's no SDIO support. Is that correct? What's the status for SATA? And the most important question: How do I build the image for an OrangePi right now? Do I need a specific Fork off Github or do I build an Image from HEAD (12.0) or do I need some additional Patches so that things work? Can anyone give me a hint? Thanks! Mat From owner-freebsd-arm@freebsd.org Tue Aug 2 10:26:08 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 990C3BAC155 for ; Tue, 2 Aug 2016 10:26:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 161FE12A9 for ; Tue, 2 Aug 2016 10:26:07 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id f2f2dc65; Tue, 2 Aug 2016 12:25:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=NwOvbw4DI3qxGVHaHyyNx1RnflQ=; b=pRQHL4m6em63mchJZFUQl1wHS/QA MVoGvt0kxqWB7QAZTg9Q2NAO6XjKpVArh0fDyZC/XJuewxpR42dS57UTnxxq6XH5 77SbuGSpbsy5qWY3UGSqmQLHT+hgXByEcQ+AyZytAcfBT1OR82kIyo1vIRdIWnUG ETffEstmpOMXbwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=iupd44XbHhiVKSvoMnYxMXYmACEzrxAlLK00k+htB/2BYbjd5JFyrytB 0QSgG84fMFPhGGLqKHjJ8UeYESd/TxkMflsbO/CIgXM1k4g1RwRCTFXLfVmPcyv3 Wj/aSit2VDM8XaTJ/pbsJuhkGS//Uq7tvBUmQlgMXAFkbsfC96s= Received: from atlantis.staff.bocal.org (163.5.250.21 [163.5.250.21]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 81b790a8 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 2 Aug 2016 12:25:58 +0200 (CEST) Date: Tue, 2 Aug 2016 12:25:57 +0200 From: Emmanuel Vadot To: mattia.rossi.mailinglists@gmail.com Cc: freebsd-arm@freebsd.org Subject: Re: Allwinner H3 - OrangePi Plus Status Message-Id: <20160802122557.629e348e4c79b885a4f27b17@bidouilliste.com> In-Reply-To: <64ad8272-a97f-e51f-19f1-d37e12c4e4bf@gmail.com> References: <64ad8272-a97f-e51f-19f1-d37e12c4e4bf@gmail.com> X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 10:26:08 -0000 Hi Mattia, On Tue, 2 Aug 2016 11:24:26 +0200 Mattia Rossi wrote: > Hi all, > > given that I have one of those things to play with, I wanted to ask what > the status is these days? > > I figured that Ethernet support is working but just missing in U-Boot, > video seems not to work yet (but I don't care) and as usual WiFi is not > working, as there's no SDIO support. Is that correct? Excatly. > What's the status for SATA? It's a USB SATA bridge so it should work. > And the most important question: > > How do I build the image for an OrangePi right now? Do I need a specific > Fork off Github or do I build an Image from HEAD (12.0) or do I need > some additional Patches so that things work? > > Can anyone give me a hint? > > Thanks! > > Mat Image from HEAD works but the DTS aren't here. We need to import the DTS from Linux 4.7 (andrew@ imported them into the vendor branch so it's been worked on). In the meantime you could use my tree (https://github.com/evadot/freebsd/tree/linux-4.7-dts) which have a raw import of the DTS files. A uboot port exist for the OrangePi One and one can be easily created for the OrangePi Plus. Cheers, -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Aug 2 10:48:44 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 407E8BAC4C8 for ; Tue, 2 Aug 2016 10:48:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8E8819A5 for ; Tue, 2 Aug 2016 10:48:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.81.13]) by kabab.cs.huji.ac.il with esmtp id 1bUXFO-0000qr-1V; Tue, 02 Aug 2016 13:48:30 +0300 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Allwinner H3 - OrangePi Plus Status From: Daniel Braniss In-Reply-To: <64ad8272-a97f-e51f-19f1-d37e12c4e4bf@gmail.com> Date: Tue, 2 Aug 2016 13:48:29 +0300 Cc: freebsd-arm@freebsd.org Message-Id: References: <64ad8272-a97f-e51f-19f1-d37e12c4e4bf@gmail.com> To: mattia.rossi.mailinglists@gmail.com X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 10:48:44 -0000 > On 2 Aug 2016, at 12:24, Mattia Rossi = wrote: >=20 > Hi all, >=20 > given that I have one of those things to play with, I wanted to ask = what the status is these days? >=20 > I figured that Ethernet support is working but just missing in U-Boot, = video seems not to work yet (but I don't care) and as usual WiFi is not = working, as there's no SDIO support. Is that correct? >=20 > What's the status for SATA? >=20 > And the most important question: >=20 > How do I build the image for an OrangePi right now? Do I need a = specific Fork off Github or do I build an Image from HEAD (12.0) or do I = need some additional Patches so that things work? >=20 > Can anyone give me a hint? >=20 this is what I did (this is very fresh and experimental) but got a = working image: - use the latest current(12). - u-boot from: https://github.com/evadot/u-boot-freebsd-port = mkdir=20 cp u-boot-orangepi-pc/*=20 cd u-boot-orangepi-plus apply patch: - build an ssd image: I=E2=80=99m attaching a wip. don=E2=80=99t just run it! - to cross compile: cd $current-source;=20 make TARGET_ARCH=3Darmv6 build world=20 make TARGET_ARCH=3Darmv6 DESTDIR=3D/mnt-root installworld make TARGET_ARCH=3Darmv6 KERNCONF=3DALLWINNER buildkernel make TARGET_ARCH=3Darmv6 KERNCONF=3DALLWINNER DESTDIR=3D/mnt-root = installkernel if you got here we are almost done :-) you will need an orangepi-plus.dtb > Thanks! >=20 > Mat >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Aug 2 13:25:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67660BAC0FB; Tue, 2 Aug 2016 13:25:18 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DA3B5124B; Tue, 2 Aug 2016 13:25:17 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 8BCE23ACC0; Tue, 2 Aug 2016 15:25:08 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <57A09F34.4050400@FreeBSD.org> Date: Tue, 2 Aug 2016 15:25:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Tue, 02 Aug 2016 15:25:08 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 13:25:18 -0000 I'm sorry for delayed response. We have serious trouble @work so I cannot spend to much time on FreeBSB for next 2 or 3 days. Dne 02.08.2016 v 6:00 Nathan Whitehorn napsal(a): > > > On 07/31/16 11:43, Nathan Whitehorn wrote: >> >> >> On 07/31/16 08:40, Michal Meloun wrote: >>> Dne 31.07.2016 v 8:11 Nathan Whitehorn napsal(a): >>> [snip] >>>>> The current API is certainly a bit of a hack and I would be >>>>> pleased to >>>>>> see it go; but the replacement needs to be more functional and more >>>>>> robust. As far as I can tell, I literally *cannot* move PowerPC over >>>>>> to this architecture. >>>>> Yes, at this time, I agree. If you can accept enhancement of >>>>> (owf_)bus_map_intr() then we can move to next, significantly less >>>>> hackish, state. >>>> OK, sure. I wrote some code this afternoon (attached) to sketch this. >>>> It does not compile or run or anything useful, but it should >>>> illustrate the important parts of what I think is an API that should >>>> work for everyone. I'm happy to finish it if it looks reasonable -- I >>>> may in any case just to replace PowerPC's increasingly teetering >>>> intr_machdep.c. >>>> >>>> The OF part is essentially unchanged from how it currently works: >>>> there's a method that you pass the interrupt specifier and interrupt >>>> parent to, and it spits back an IRQ that means that combination of >>>> things in perpetuity. OFW_BUS_MAP_INTR() in nexus.c, with its current >>>> API, can be implemented in terms of it in one line. Whenever the >>>> relevant PIC attaches, it is told to use the given IRQ to refer to >>>> that opaque bytestring. >>>> >>>> I've added a set of equivalent functions for ACPI that take the >>>> contents of an ACPI interrupt specifier and do the same things. It >>>> tries to have the IRQ be human-meaningful, if possible, by matching >>>> the ACPI interrupt number. Having separate functions seemed a little >>>> cleaner than exposing the enums and unions as part of the KPI, but I'm >>>> not wedded to it -- this is just an example. >>>> >>>> PICs register (and deregister) themselves with either an OF phandle or >>>> an ACPI resource string or (god help us) both as needed. The PICs have >>>> corresponding methods for interpreting various kinds of interrupt >>>> specifiers. >>>> >>>> Whether it allows bus_alloc_resource(), bus_setup_intr(), etc. to >>>> succeed before the PICs are attached is gated on an #ifdef. That can >>>> probably be off by default on ARM. A PowerPC version of this code >>>> would have to keep it on until various bus drivers are fixed. >>>> >>>> Here's the general flow: >>>> - Parent bus enumerates children, maps IRQs as needed, adds to >>>> resource list. The struct resources involved aren't special (just a >>>> single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are trivial to >>>> implement (and already are implemented, in general, for OF/FDT >>>> drivers). >>>> - bus_alloc_resource() does nothing special >>>> - bus_setup_intr() calls into the PIC and does what is needed, as in >>>> r301453 (to within that #ifdef) >>>> >>>> This should keep all the best pieces of everything: >>>> - ACPI and OF are supported together, and easy to extend for other >>>> types of mapping technologies without breaking either KBI or KPI (just >>>> add new functions) >>>> - No APIs change for existing Open Firmware code >>>> - The support code can live entirely in machine-dependent directories, >>>> with no code changes at all required in kern/ or dev/ofw/ >>>> - bus_setup_intr() and friends behave as in r301453 and succeed or >>>> fail for real >>>> - PCI code is not an issue >>>> - No disconnected interrupt state maintained in mapping table (unless >>>> the transitional #ifdef is on) and the mapping table content is only >>>> larger than r301453 by having a copy of the original interrupt >>>> specifier. >>>> >>>> If and when we manage to fix the kernel APIs to allow non-scalar >>>> interrupt specifiers, this should also be easy to gradually >>>> transmogrify to support that case since there exists a 1:1 mapping of >>>> scalar IRQs to rich data and the control flow would be identical: >>>> interrupt specifiers are read at enumeration time and a resulting >>>> handle -- struct resource or scalar IRQ -- used afterward to refer >>>> to it. >>>> >>> Nice, nice, i think that we are very close at this point. >>> The problem with the above workflow is that maps IRQ function is called >>> at parent bus enumeration time, generally at BUS_PASS_BUS pass. And at >>> this time, PICs are not exist. >>> Also, 'static struct intr_irqsrc *irq_sources[NIRQ];' is not a mapping >>> table, it doesn't provide this functionality. >>> But yes, i understand that mapping table is important and necessary >>> for you. >>> >>> So, if i can extend our concept a little bit, then: >>> We can add new table (map_data_tbl for example) that holds a copy of >>> the original interrupt specifier, index to irq_sources table and >>> probably some flags. >>> And we can modify the above workflow to: >>> - Parent bus enumerates children, allocates entries from map_data_tbl, >>> adds to resource list. The struct resources involved aren't special >>> (just a single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are >>> trivial to implement (and already are implemented, in general, for >>> OF/FDT drivers). Index to map_data_tbl is used as resource ID. >>> - bus_alloc_resource() sets 'ALLOCATED' in map_data_tbl flags field, >>> *maps IRQs* and stores result in 'index' field. >>> - bus_setup_intr() sets 'SETUP_DONE' in map_data_tbl flags field, calls >>> into the PIC and does what is needed, as in r301453. (to within that >>> #ifdef) >>> >>> And, in PPC case, newly attached PIC scans whole map_data_tbl table, >>> finds his entries and makes what needs. >>> >>> Does that make sense? >>> I hope that postponing of map IRQ call is not a problem for PPC, >>> everything else looks easy. >>> Moreover, this additional level of indirection also solves all my >>> 'hypothetical corner cases' with N:1 mappings (between original >>> interrupt specifier and real interrupt number). >> >> Yes, I think we are converging. >> >> My qualm about bus_alloc_resource() is twofold: >> 1. Traditionally, with interrupts, bus_alloc_resource() has no side >> effects and I'm not sure it propagates cleanly down the tree in all >> cases. >> 2. There are a few bus APIs (bus_config_intr() comes to mind) that >> use raw IRQ IDs and, so far as I know, can be, and sometimes are >> called before bus_alloc_resource(). If the PIC doesn't know about the >> IRQ yet when bus_config_intr() (etc.) is called, things will just break. >> >> So you would need to make sure that any bus method handling a >> resource ID causes it to be mapped on the PIC at that time. It's OK >> if that happens in bus_alloc_resource() so long as bus_config_intr(), >> bus_setup_intr(), etc. cause that to happen if it hasn't happened yet >> -- I don't care when these calls are made to the PIC driver so long >> as *what* calls will be made is set at enumeration time. >> >> I am also totally fine with having, on ARM, bus_config_intr(), >> bus_setup_intr() etc. fail if the PIC hasn't attached yet (On >> PowerPC, we can't do that yet, but after this conversation, I regard >> that as a bug and would fix that later), as well as delaying setup on >> the PIC to the first time any bus driver actually tries to *use* the >> interrupt (alloc_resource(), setup_intr(), config_intr(), whatever) >> rather than when the interrupt is originally allocated. >> I understand. And yes, bus_alloc_resource() isn't propagated cleanly down the tree in all cases. That's why we have 'INTRNG' hook in subr_bus.c, which is suboptimal. About bus_config_intr(). The only consumer of bus_config_intr() is ACPI code, in little hackish manner, as workaround for problem which is fully solved by INTRNG. Also, the semantic of bus_config_intr() is not clear, from INTRNG point of view. So i have tendency to ignore it :) >> ------------ The following is a large parenthesis ------------------- >> >> One other possible route here that would also work well would be to >> make ofwbus.c MD (it's a trivial piece of code anyway, so we don't >> gain a lot by sharing it) and implement ofw_bus_map_intr() locally as >> an ofwbus bus method. Then you could have the mapping table stored in >> ofwbus's softc -- the API was designed for this initially. You would >> need MD extensions for doing PIC registration there (which is fine), >> but that segregates all the OFW-specific information into >> OFW-specific code and would let the bus methods and the OFW interrupt >> mapping table interact cleanly in the same place. This still >> preserves the pre-r301453 API, makes PowerPC work, and maybe >> address's skra@'s concern about extensibility and letting core >> interrupt code know about FDT (or ACPI). I'd be happy to mock this up >> as well if you think it's a good approach. >> > [snip] >> >> This has the following features: >> - Existing OFW API and semantics unchanged >> - As such, PowerPC, PCI, etc. work fine with no changes >> - Details encapsulated in MD code, so individual platforms can >> implement this however they like >> - arm/arm/intr.c (or whatever) only needs a method to allocate a >> fresh interrupt, with no state, and anoter to set the device_t for an >> interrupt sometime later. >> - The internal table in the platform interrupt code has no knowledge >> of any mappings whatsoever except having the appropriate device_t for >> the PIC stored with the interrupt vector. >> - Device tree bits handled purely in device tree code >> - No action need be taken on any mapping until the interrupt is >> actually allocated/set up, like r301453 >> - Easy to add more mapping mechanisms (e.g. ACPI) by having similar >> enumeration-mechanism-specific code in the root bus for that mapping >> mechanism. >> >> -------------- End parenthesis ------------------------------- > > Here's an implementation of the parenthesis I wrote on an airplane > this afternoon. It should be complete, though has not been tested. The > code is short and simple (+70 lines in ofwbus.c). This preserves the > pre-r301453 API and semantics relative to drivers, which means PowerPC > and PCI work out of the box, while keeping the semantics relative to > the interrupt layer of r301453 (PIC methods only called on resource > allocation, no allocatable IRQs on unattached PICs, encapsulation of > OFW-specific code in OFW-specific bits of the tree). It turns out > those two things are compatible, somewhat to my surprise, and that > makes the result very clean. I like this approach and would be happy > to move forward with it. There are five functions of interest: > > 1. OFW_BUS_MAP_INTR(). This has the semantics and API it has now: you > pass an interrupt specifier and parent, you get back an IRQ. No > changes. This is the core of the normal OFW interrupt API. > > 2. OFW_BUS_REGISTER_PIC(device_t pic, phandle_t phandle). This is a > new function that PIC drivers are supposed to use to register control > of an interrupt domain. This replaces machine-specific code like > powerpc_register_pic() to allow the PIC table to be in a bus parent > rather than in the interrupt core. > > 3. PIC_MAP_OFW_INTR(device_t pic, int irq, interrupt specifier). This > is a new function that PIC drivers that know how to handle device-tree > interrupt descriptors implement (analogous to various existing ones > that vary by platform). It tells the PIC that the given abstract IRQ > means the given opaque interrupt specifier. > > 4. arm_allocate_irq(int suggested). This allocates a new IRQ number > not (yet) attached to a PIC, as in r301453. I've added a parameter > that lets you pass a suggested number to try in case it is possible to > make it match an interrupt pin or something for human-readability. > > 5. arm_set_pic_for_irq(int irq, device_t). This tells the MD interrupt > layer to associate a given PIC device_t with an IRQ. That is all the > information the MD layer ever has about the IRQ mapping. > > Functions #1 and #2 are now implemented completely in ofwbus.c: there > are no callouts anywhere else and the interrupt mapping table is > maintained entirely internally to ofwbus (in its softc). In order to > implement ACPI, or some other strategy, you would implement analogs to > functions #1 and #2 that live somewhere in the bus hierarchy that is > guaranteed to be above all devices that might want that type of > interrupt (e.g. in acpi0), and some analog to #3 that PIC drivers > implementing the mapping scheme would provide. > > Since the system interrupt code has no knowledge at all of interrupt > mapping, of any type, in this scheme, adding new mapping types is > trivial and can be done on a driver-by-driver basis if necessary > without changing KPI and without any other part of the system even > being aware. For example, GPIOs can use a completely different > mechanism if they want and can do setup purely in the GPIO controller > driver. You could have a method GPIO_GET_INTERRUPT_FOR_PIN() on a GPIO > controller in which the GPIO controller allocates a generic IRQ, > assigns through some internal table just in the GPIO driver, and > returns to it to a consumer in some other device driver -- without a > GPIO mapping type, new bus functions, or modifications to the platform > interrupt code. > > The control flow goes like this: > - Bus driver enumerates children, parses interrupts properties, calls > OFW_BUS_MAP_INTR() to get IRQs for them (as pre-r301453), adds to > interrupt list. > - ofwbus receives the OFW_BUS_MAP_INTR() call, allocates a blank > disconnected IRQ from the MD interrupt layer, and stores the mapping > from the new IRQ to the given interrupt specifier and phandle in an > internal table in ofwbus's softc. > NB: Nothing else happens here, like post-r301453. Changing this does > not change any semantics of the API pre-r301453, which means it > remains fully compatible with PCI and PowerPC. Also, like > post-r301453, there is no involvement of nexus. > - PICs attach and call OFW_BUS_REGISTER_PIC(). ofwbus receives these > messages and adds a (device_t, phandle_t) mapping to a second internal > table. Note that the interrupt layer does not need to handle PIC > registration anymore at all (except for the root PIC). > - Bus child eventually calls a function that tries to set the > interrupt up (e.g. bus_setup_intr()). That propagates up the bus > hierarchy, eventually getting to ofwbus. ofwbus notes the IRQ number, > looks it up in the table, looks up the appropriate PIC from the PIC > table, then: > A) calls arm_set_pic_for_irq(irq, pic_device_t) -- this is the > interrupt layer's only interaction with the mapping code. All it deals > with is device_ts and abstract IRQ numbers. > B) calls PIC_MAP_OFW_INTR(pic, irq_number, interrupt-cells, > interrupt-specifier) to tell the PIC that the interrupt layer's IRQ > irq_number means the given specifier > C) finally, passes the call onto nexus, which will do whatever would > normally happen (unmasking the interrupt, setting handlers, etc.) in > terms only of the abstract IRQ and the device_t assigned by ofwbus. > > You would implement ACPI just by doing a s/OFW/ACPI/g > search-and-replace above -- since the interrupt layer doesn't know > about OFW or ACPI or anything else, there is no need to touch it. This > seems clean, simple, compartmentalized, preserves the existing API, > and should work on all of our various hardware. PowerPC can't quite > work with it yet without some multipass foo, but, since the API is > preserved, that transition can happen gradually without KPI changes. > For the same reason that it is API-preserving, I think this code is > also MFC-able. > -Nathan I think that we are slightly diverges in this place: - please note that PIC API (in kern/pic_if.m) is different from the one that PPC uses. - we must be able to store configuration data (original interrupt specifier) in all cases, not only for OFW. That's reason why I have proposed to create 'mapping table'. Anyway, i think that we both talking about +/- same solution, only i want to move it from OFW specific level implemented at OFW bus level to bus/interrupt specifier format independent level implemented in subr_intr.c. Most of your control flow can be implemented at general level as is, or already exist [intr_map_irq(), intr_pic_register()] . Also, impact for current PPC code is, by me, minimal. I can sketch my idea in more details, if you found it acceptable. Again, I'm sorry for delayed and very brief response. Michal From owner-freebsd-arm@freebsd.org Tue Aug 2 14:30:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09919BAC653 for ; Tue, 2 Aug 2016 14:30:38 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F7841A62 for ; Tue, 2 Aug 2016 14:30:37 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id q128so31232513wma.1 for ; Tue, 02 Aug 2016 07:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Wz6DOUN+yhhZzl+y6LL5Z1enKPJ5IcHCphTzdFEA8Ds=; b=fZdTEI8ywYi75cwCO+vwnHjU+RkQuxqcMqmdgEtS80Jod6U9BeEDUQ6QIngboIx5U6 f9ivYG3jgVRR165qlBVWE1wwS4s/0SHH2HW66TtNhVFTf/azesCDM8Jr33Q3UKce6RdQ GUe0UXxJ7wCIhBaBxyQqc3AYNmuRJ/bcDC+skIfTGD4IR+/be9IvADwVMRI78G+zjKNO f936wP0qOfsn8qKnlwZK4JoTzZJ2jYBqIxvKfRfsksUWPBPqi5Mga6r1tLQ0jWM7KouD rche7KnBxvverQEMXeM4tMw/I+ePabPPxg8qnxBQhcQgPJbcbhgplIDGofz/kKDVA7MW UfbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Wz6DOUN+yhhZzl+y6LL5Z1enKPJ5IcHCphTzdFEA8Ds=; b=ekQXVbOtQPKhtdLNDjv8Tou94jKZAERQ4j/17ysyDvzUeqL+bMu5z+nkZa/z2KT2MC kpYUtg/OaoK34ve/OYbSzOaBYrtW8Ic7Ildp4juEq6l/ljwClo/6kc2Sn7djprLkX8v8 PQELbWNJuXPcViwLhVfpe9wdHCSh+8NY7cUvOd3kN1n08C/hETDprhEzPjzOvRIYeepf yreeDFv1GB7cqd0N75xg3SwKz0Vqsdlydb6RAC4deA77SNbfuohct63t8bnFRhAliIWV asU2i9CoEHkgaCuhkgA7FJjUBI9cQG39cj9uHNlhZUdQT4Q05OUMoavi/QmFMIzCpTap XEIQ== X-Gm-Message-State: AEkooutSokaTatGyENRB3ZD0gdSocU2PnsIykb3sc5rqcwId1KIBAian7z6ZdfHfl6KRdQ== X-Received: by 10.28.238.154 with SMTP id j26mr20836145wmi.94.1470148235821; Tue, 02 Aug 2016 07:30:35 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:415c:5921:236:4373? ([2001:1620:ff0:c51:415c:5921:236:4373]) by smtp.gmail.com with ESMTPSA id hy3sm2933999wjb.8.2016.08.02.07.30.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2016 07:30:35 -0700 (PDT) Reply-To: mattia.rossi.mailinglists@gmail.com Subject: Re: Allwinner H3 - OrangePi Plus Status References: <64ad8272-a97f-e51f-19f1-d37e12c4e4bf@gmail.com> <20160802122557.629e348e4c79b885a4f27b17@bidouilliste.com> To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org From: Mattia Rossi Message-ID: Date: Tue, 2 Aug 2016 16:30:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160802122557.629e348e4c79b885a4f27b17@bidouilliste.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 14:30:38 -0000 Hi Emmanuel, thanks for the info. I'm going to try your dts files and follow Danny's build advice. Just realised again, that my board is an OrangePi Plus 2 though... so I hope the dts still works. Cheers, Mat Am 02.08.2016 um 12:25 schrieb Emmanuel Vadot: > Hi Mattia, > > On Tue, 2 Aug 2016 11:24:26 +0200 > Mattia Rossi wrote: > >> Hi all, >> >> given that I have one of those things to play with, I wanted to ask what >> the status is these days? >> >> I figured that Ethernet support is working but just missing in U-Boot, >> video seems not to work yet (but I don't care) and as usual WiFi is not >> working, as there's no SDIO support. Is that correct? > Excatly. > >> What's the status for SATA? > It's a USB SATA bridge so it should work. > >> And the most important question: >> >> How do I build the image for an OrangePi right now? Do I need a specific >> Fork off Github or do I build an Image from HEAD (12.0) or do I need >> some additional Patches so that things work? >> >> Can anyone give me a hint? >> >> Thanks! >> >> Mat > Image from HEAD works but the DTS aren't here. We need to import the DTS from Linux 4.7 (andrew@ imported them into the vendor branch so it's been worked on). > In the meantime you could use my tree (https://github.com/evadot/freebsd/tree/linux-4.7-dts) which have a raw import of the DTS files. > A uboot port exist for the OrangePi One and one can be easily created for the OrangePi Plus. > > Cheers, > From owner-freebsd-arm@freebsd.org Tue Aug 2 14:32:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15295BAC7C0 for ; Tue, 2 Aug 2016 14:32:38 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 953711D67 for ; Tue, 2 Aug 2016 14:32:37 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id q128so412021923wma.1 for ; Tue, 02 Aug 2016 07:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=ipQcVrrk7iJBhbRzlSbKzBtMcyDIcL7MuuTj0ulleYk=; b=pfU90UC4OLskIcoCmDmB20vuHh0vmNBVYNMzuuw4/ygASoJMTurWgQKqWl0H9SRKOD e3PK0kN4kj+dFr0yxQhb/QIr3ierfPMBc+4BDGLBFHemwKUz7fqaZlb12umpS6Uz+zSD 89f/izQgbK6XL5vqbA3RcwbtHMJf0mbb4bvm9j8ocjHAtz0dwHZVvjBPZ9T0EpSx0eA4 cisMxcYiq0QL0u092LTlxgzrAxgIa842xuYswIPEs9sYZLS9cWzoJL/u8gD5uVGCDFgV SEz9T4xqiavIraX/3/3qi+dVpi419dgYQSZtPI1Bj5PVS1tiXpUr8wmRkSOD1fVs8x60 gCPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to; bh=ipQcVrrk7iJBhbRzlSbKzBtMcyDIcL7MuuTj0ulleYk=; b=fuM+iakJWgOPubaRGupBpNK0474tiJytde5gfm1dYgEnUMIiPVc5pEEbo0DCnZxLlx zR3JC56mWJfLnoybYrtvQvyyDonxarDCQMDFUsUSPjDYCdzTx9fHi0+yOwA9jWNcUwNf igRPY/JbgJH9geXGa6CIclsRTmYpH+n3kshdfdZhsBxd0so2AxDFT1glLFRSwuQ5t4Bf NQPOO+VYsByQjthzHmyciNKou86a01lfg4OSHt/0b50aek9+c95sALkNmhoarVEt6Ckg fDTWJXt0ODtbZQf4CKkW0zuGB1PyvOTzKZwSdoUNvWsNrz2B0j6eOreuxO9D2VoGVfjS ORMw== X-Gm-Message-State: AEkoous23ub7FeJiTtMGaWUFzkYWkX3gFn22dpvR30OZlUfGcSzWPu9kQc1ZXTSIK4PmQA== X-Received: by 10.194.249.170 with SMTP id yv10mr4048798wjc.73.1470148356070; Tue, 02 Aug 2016 07:32:36 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:415c:5921:236:4373? ([2001:1620:ff0:c51:415c:5921:236:4373]) by smtp.gmail.com with ESMTPSA id a2sm22424288wma.2.2016.08.02.07.32.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2016 07:32:35 -0700 (PDT) Reply-To: mattia.rossi.mailinglists@gmail.com Subject: Re: Allwinner H3 - OrangePi Plus Status References: <64ad8272-a97f-e51f-19f1-d37e12c4e4bf@gmail.com> To: Daniel Braniss Cc: freebsd-arm@freebsd.org From: Mattia Rossi Message-ID: <868ae805-bf93-50f9-e22c-1d2ea13f8555@gmail.com> Date: Tue, 2 Aug 2016 16:32:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 14:32:38 -0000 Thanks Danny, I'll give it a go with Emmanuel's dts from Linux 4.7. I'll let you know how it went. Cheers! Mat Am 02.08.2016 um 12:48 schrieb Daniel Braniss: > >> On 2 Aug 2016, at 12:24, Mattia Rossi >> > > wrote: >> >> Hi all, >> >> given that I have one of those things to play with, I wanted to ask >> what the status is these days? >> >> I figured that Ethernet support is working but just missing in >> U-Boot, video seems not to work yet (but I don't care) and as usual >> WiFi is not working, as there's no SDIO support. Is that correct? >> >> What's the status for SATA? >> >> And the most important question: >> >> How do I build the image for an OrangePi right now? Do I need a >> specific Fork off Github or do I build an Image from HEAD (12.0) or >> do I need some additional Patches so that things work? >> >> Can anyone give me a hint? >> > this is what I did (this is very fresh and experimental) but got a > working image: > - use the latest current(12). > - u-boot from: https://github.com/evadot/u-boot-freebsd-port > mkdir > cp u-boot-orangepi-pc/* > cd u-boot-orangepi-plus > apply patch: > > > - build an ssd image: > I’m attaching a wip. don’t just run it! > > > - to cross compile: > cd $current-source; > make TARGET_ARCH=armv6 build world > make TARGET_ARCH=armv6 DESTDIR=/mnt-root installworld > make TARGET_ARCH=armv6 KERNCONF=ALLWINNER buildkernel > make TARGET_ARCH=armv6 KERNCONF=ALLWINNER DESTDIR=/mnt-root installkernel > > if you got here we are almost done :-) > you will need an orangepi-plus.dtb > >> Thanks! >> >> Mat >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Tue Aug 2 14:56:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB6A3BAC06A for ; Tue, 2 Aug 2016 14:56:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 610391DA4 for ; Tue, 2 Aug 2016 14:56:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1bUb78-0003f6-SG; Tue, 02 Aug 2016 17:56:15 +0300 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Allwinner H3 - OrangePi Plus Status From: Daniel Braniss In-Reply-To: <868ae805-bf93-50f9-e22c-1d2ea13f8555@gmail.com> Date: Tue, 2 Aug 2016 17:56:14 +0300 Cc: freebsd-arm@freebsd.org Message-Id: <8FDE95E3-C66E-40D5-8133-67FD987BE729@cs.huji.ac.il> References: <64ad8272-a97f-e51f-19f1-d37e12c4e4bf@gmail.com> <868ae805-bf93-50f9-e22c-1d2ea13f8555@gmail.com> To: mattia.rossi.mailinglists@gmail.com X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 14:56:18 -0000 > On 2 Aug 2016, at 5:32 PM, Mattia Rossi = wrote: >=20 > Thanks Danny, >=20 > I'll give it a go with Emmanuel's dts from Linux 4.7. >=20 > I'll let you know how it went. >=20 >=20 the .dtb file goes in /boot/dtb Also realised that my attachments did not go through, in case their air = needed let me know. cheers, danny > Cheers! >=20 > Mat > Am 02.08.2016 um 12:48 schrieb Daniel Braniss: >>=20 >>> On 2 Aug 2016, at 12:24, Mattia Rossi = > wrote: >>>=20 >>> Hi all, >>>=20 >>> given that I have one of those things to play with, I wanted to ask = what the status is these days? >>>=20 >>> I figured that Ethernet support is working but just missing in = U-Boot, video seems not to work yet (but I don't care) and as usual WiFi = is not working, as there's no SDIO support. Is that correct? >>>=20 >>> What's the status for SATA? >>>=20 >>> And the most important question: >>>=20 >>> How do I build the image for an OrangePi right now? Do I need a = specific Fork off Github or do I build an Image from HEAD (12.0) or do I = need some additional Patches so that things work? >>>=20 >>> Can anyone give me a hint? >>>=20 >> this is what I did (this is very fresh and experimental) but got a = working image: >> - use the latest current(12). >> - u-boot from: https://github.com/evadot/u-boot-freebsd-port = >> mkdir=20 >> cp u-boot-orangepi-pc/*=20 >> cd u-boot-orangepi-plus >> apply patch: >>=20 >>=20 >> - build an ssd image: >> I=92m attaching a wip. don=92t just run it! >>=20 >>=20 >> - to cross compile: >> cd $current-source;=20 >> make TARGET_ARCH=3Darmv6 build world=20 >> make TARGET_ARCH=3Darmv6 DESTDIR=3D/mnt-root installworld >> make TARGET_ARCH=3Darmv6 KERNCONF=3DALLWINNER buildkernel >> make TARGET_ARCH=3Darmv6 KERNCONF=3DALLWINNER DESTDIR=3D/mnt-root = installkernel >>=20 >> if you got here we are almost done :-) >> you will need an orangepi-plus.dtb >>=20 >>> Thanks! >>>=20 >>> Mat >>>=20 >>>=20 >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing = list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = >>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" = >>=20 >=20 From owner-freebsd-arm@freebsd.org Tue Aug 2 15:07:46 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24CAEBAC2D2 for ; Tue, 2 Aug 2016 15:07:46 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8CCF131F for ; Tue, 2 Aug 2016 15:07:45 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id o80so295052757wme.1 for ; Tue, 02 Aug 2016 08:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=F1H98bVu1UDdnTjaWiXzvxbW7JaB6RmhXqHOfaDeNfQ=; b=b9odcshdjLqATWxFmzVMfsKdJAMHwJCSD3CF4svLzxIEaOBDs0/iz4n8DaAU4cjxSF d/oSuid19RQtekveRjg41Whj24z1sd3Sqpfmkjbhjr1q+Gj6ft0FWrUjNgDicDs9J30m o5a+4kTOlIZaNasfwQBIXoFeWOqRojss0pnK9Ho9eeGc+VynF2q9+jyshpNPUsFlAJrG vNhg/MIChoThkaeDCvVwe+/+A8SwlQrP1lalepcMT9VASEuDDp2tnaOh7ovRtp2jExWr cASTsbjAch8qkVTrb4v9U3RfvU0BkG7kCrpGKIe2HALRYPo1gYzONcf4bBu/AqbTIqhN HEwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to; bh=F1H98bVu1UDdnTjaWiXzvxbW7JaB6RmhXqHOfaDeNfQ=; b=kiX2EezSiors10tfaGzIQEcAbi6dLSEOX+sJtwGRPblVGrSfAtUTpE4ekBEoB+dvsu iMq9dJRtZwTn5O6UDUdj5JOYLkqVNc24mmtC66y7PYv01pMDATjqwZoyGfgOcth/rH6v ajww4lw0EaEM1nfJj8m4jsf0mUqeRBFhtiHbWG6CIQWuv6PzMB1/MH1Th3tIX4H/Rj5I ETbEKeN+hMTHxLkmZuZhc65Z9o/scb+sx3kNGGMgbwk6am+sjuPCItYDQ2pu2Y59OLhB M1GnJL84w5bOoQsfz3GpKWLDpL5KduDTtWZDh3YlGlP+vd3/pALuDbx2p+cVhigbkIRD I57Q== X-Gm-Message-State: AEkoouurji7n6ymkHkifa6Ezky+zuYAsnNAbfmwyVhKJkMidD3jB2+Ae7vv8itgAMuhN8g== X-Received: by 10.28.74.221 with SMTP id n90mr18963969wmi.16.1470150463671; Tue, 02 Aug 2016 08:07:43 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:415c:5921:236:4373? ([2001:1620:ff0:c51:415c:5921:236:4373]) by smtp.gmail.com with ESMTPSA id a9sm3081539wjf.16.2016.08.02.08.07.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2016 08:07:42 -0700 (PDT) Reply-To: mattia.rossi.mailinglists@gmail.com Subject: Re: Allwinner H3 - OrangePi Plus Status References: <64ad8272-a97f-e51f-19f1-d37e12c4e4bf@gmail.com> <868ae805-bf93-50f9-e22c-1d2ea13f8555@gmail.com> <8FDE95E3-C66E-40D5-8133-67FD987BE729@cs.huji.ac.il> To: Daniel Braniss Cc: freebsd-arm@freebsd.org From: Mattia Rossi Message-ID: <6e7433f4-02be-8bdc-7cb9-9ce53079efc5@gmail.com> Date: Tue, 2 Aug 2016 17:07:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8FDE95E3-C66E-40D5-8133-67FD987BE729@cs.huji.ac.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 15:07:46 -0000 Am 02.08.2016 um 16:56 schrieb Daniel Braniss: > >> On 2 Aug 2016, at 5:32 PM, Mattia Rossi >> > > wrote: >> >> Thanks Danny, >> >> I'll give it a go with Emmanuel's dts from Linux 4.7. >> >> I'll let you know how it went. >> >> > > the .dtb file goes in /boot/dtb > Also realised that my attachments did not go through, in case their > air needed > let me know. > Thanks, I was actually wondering, but I immagined that they would need to go there. The attachments came through fine, thanks. It'll be a day or two until I can test everything properly and provide feedback. Cheers, Mat From owner-freebsd-arm@freebsd.org Tue Aug 2 15:31:44 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F877BACA99; Tue, 2 Aug 2016 15:31:44 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40CEB15B2; Tue, 2 Aug 2016 15:31:43 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net ([192.5.85.48]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u72FVdew018035 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Aug 2016 08:31:40 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> <57A09F34.4050400@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: Date: Tue, 2 Aug 2016 08:31:39 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57A09F34.4050400@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYLbx0DfpdB0lge4gSoDIGN4Mxfrle5ZyKi1R1qp3sg5EfEUSgS/w9/jusrHNWE7pwA11gjPWyFR/izgeMcFy+K X-Sonic-ID: C;CKLiNMZY5hGhja/hcgQksw== M;ACN4NcZY5hGhja/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 15:31:44 -0000 On 08/02/16 06:25, Michal Meloun wrote: > I'm sorry for delayed response. We have serious trouble @work so I > cannot spend to much time on FreeBSB for next 2 or 3 days. Understood. > > Dne 02.08.2016 v 6:00 Nathan Whitehorn napsal(a): >> >> On 07/31/16 11:43, Nathan Whitehorn wrote: >>> >>> On 07/31/16 08:40, Michal Meloun wrote: >>>> Dne 31.07.2016 v 8:11 Nathan Whitehorn napsal(a): >>>> [snip] >>>>>> The current API is certainly a bit of a hack and I would be >>>>>> pleased to >>>>>>> see it go; but the replacement needs to be more functional and more >>>>>>> robust. As far as I can tell, I literally *cannot* move PowerPC over >>>>>>> to this architecture. >>>>>> Yes, at this time, I agree. If you can accept enhancement of >>>>>> (owf_)bus_map_intr() then we can move to next, significantly less >>>>>> hackish, state. >>>>> OK, sure. I wrote some code this afternoon (attached) to sketch this. >>>>> It does not compile or run or anything useful, but it should >>>>> illustrate the important parts of what I think is an API that should >>>>> work for everyone. I'm happy to finish it if it looks reasonable -- I >>>>> may in any case just to replace PowerPC's increasingly teetering >>>>> intr_machdep.c. >>>>> >>>>> The OF part is essentially unchanged from how it currently works: >>>>> there's a method that you pass the interrupt specifier and interrupt >>>>> parent to, and it spits back an IRQ that means that combination of >>>>> things in perpetuity. OFW_BUS_MAP_INTR() in nexus.c, with its current >>>>> API, can be implemented in terms of it in one line. Whenever the >>>>> relevant PIC attaches, it is told to use the given IRQ to refer to >>>>> that opaque bytestring. >>>>> >>>>> I've added a set of equivalent functions for ACPI that take the >>>>> contents of an ACPI interrupt specifier and do the same things. It >>>>> tries to have the IRQ be human-meaningful, if possible, by matching >>>>> the ACPI interrupt number. Having separate functions seemed a little >>>>> cleaner than exposing the enums and unions as part of the KPI, but I'm >>>>> not wedded to it -- this is just an example. >>>>> >>>>> PICs register (and deregister) themselves with either an OF phandle or >>>>> an ACPI resource string or (god help us) both as needed. The PICs have >>>>> corresponding methods for interpreting various kinds of interrupt >>>>> specifiers. >>>>> >>>>> Whether it allows bus_alloc_resource(), bus_setup_intr(), etc. to >>>>> succeed before the PICs are attached is gated on an #ifdef. That can >>>>> probably be off by default on ARM. A PowerPC version of this code >>>>> would have to keep it on until various bus drivers are fixed. >>>>> >>>>> Here's the general flow: >>>>> - Parent bus enumerates children, maps IRQs as needed, adds to >>>>> resource list. The struct resources involved aren't special (just a >>>>> single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are trivial to >>>>> implement (and already are implemented, in general, for OF/FDT >>>>> drivers). >>>>> - bus_alloc_resource() does nothing special >>>>> - bus_setup_intr() calls into the PIC and does what is needed, as in >>>>> r301453 (to within that #ifdef) >>>>> >>>>> This should keep all the best pieces of everything: >>>>> - ACPI and OF are supported together, and easy to extend for other >>>>> types of mapping technologies without breaking either KBI or KPI (just >>>>> add new functions) >>>>> - No APIs change for existing Open Firmware code >>>>> - The support code can live entirely in machine-dependent directories, >>>>> with no code changes at all required in kern/ or dev/ofw/ >>>>> - bus_setup_intr() and friends behave as in r301453 and succeed or >>>>> fail for real >>>>> - PCI code is not an issue >>>>> - No disconnected interrupt state maintained in mapping table (unless >>>>> the transitional #ifdef is on) and the mapping table content is only >>>>> larger than r301453 by having a copy of the original interrupt >>>>> specifier. >>>>> >>>>> If and when we manage to fix the kernel APIs to allow non-scalar >>>>> interrupt specifiers, this should also be easy to gradually >>>>> transmogrify to support that case since there exists a 1:1 mapping of >>>>> scalar IRQs to rich data and the control flow would be identical: >>>>> interrupt specifiers are read at enumeration time and a resulting >>>>> handle -- struct resource or scalar IRQ -- used afterward to refer >>>>> to it. >>>>> >>>> Nice, nice, i think that we are very close at this point. >>>> The problem with the above workflow is that maps IRQ function is called >>>> at parent bus enumeration time, generally at BUS_PASS_BUS pass. And at >>>> this time, PICs are not exist. >>>> Also, 'static struct intr_irqsrc *irq_sources[NIRQ];' is not a mapping >>>> table, it doesn't provide this functionality. >>>> But yes, i understand that mapping table is important and necessary >>>> for you. >>>> >>>> So, if i can extend our concept a little bit, then: >>>> We can add new table (map_data_tbl for example) that holds a copy of >>>> the original interrupt specifier, index to irq_sources table and >>>> probably some flags. >>>> And we can modify the above workflow to: >>>> - Parent bus enumerates children, allocates entries from map_data_tbl, >>>> adds to resource list. The struct resources involved aren't special >>>> (just a single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are >>>> trivial to implement (and already are implemented, in general, for >>>> OF/FDT drivers). Index to map_data_tbl is used as resource ID. >>>> - bus_alloc_resource() sets 'ALLOCATED' in map_data_tbl flags field, >>>> *maps IRQs* and stores result in 'index' field. >>>> - bus_setup_intr() sets 'SETUP_DONE' in map_data_tbl flags field, calls >>>> into the PIC and does what is needed, as in r301453. (to within that >>>> #ifdef) >>>> >>>> And, in PPC case, newly attached PIC scans whole map_data_tbl table, >>>> finds his entries and makes what needs. >>>> >>>> Does that make sense? >>>> I hope that postponing of map IRQ call is not a problem for PPC, >>>> everything else looks easy. >>>> Moreover, this additional level of indirection also solves all my >>>> 'hypothetical corner cases' with N:1 mappings (between original >>>> interrupt specifier and real interrupt number). >>> Yes, I think we are converging. >>> >>> My qualm about bus_alloc_resource() is twofold: >>> 1. Traditionally, with interrupts, bus_alloc_resource() has no side >>> effects and I'm not sure it propagates cleanly down the tree in all >>> cases. >>> 2. There are a few bus APIs (bus_config_intr() comes to mind) that >>> use raw IRQ IDs and, so far as I know, can be, and sometimes are >>> called before bus_alloc_resource(). If the PIC doesn't know about the >>> IRQ yet when bus_config_intr() (etc.) is called, things will just break. >>> >>> So you would need to make sure that any bus method handling a >>> resource ID causes it to be mapped on the PIC at that time. It's OK >>> if that happens in bus_alloc_resource() so long as bus_config_intr(), >>> bus_setup_intr(), etc. cause that to happen if it hasn't happened yet >>> -- I don't care when these calls are made to the PIC driver so long >>> as *what* calls will be made is set at enumeration time. >>> >>> I am also totally fine with having, on ARM, bus_config_intr(), >>> bus_setup_intr() etc. fail if the PIC hasn't attached yet (On >>> PowerPC, we can't do that yet, but after this conversation, I regard >>> that as a bug and would fix that later), as well as delaying setup on >>> the PIC to the first time any bus driver actually tries to *use* the >>> interrupt (alloc_resource(), setup_intr(), config_intr(), whatever) >>> rather than when the interrupt is originally allocated. >>> > I understand. And yes, bus_alloc_resource() isn't propagated cleanly > down the tree in all cases. That's why we have 'INTRNG' hook in > subr_bus.c, which is suboptimal. > > About bus_config_intr(). The only consumer of bus_config_intr() is ACPI > code, in little hackish manner, as workaround for problem which is > fully solved by INTRNG. > Also, the semantic of bus_config_intr() is not clear, from INTRNG point > of view. > So i have tendency to ignore it :) Heh. Fair enough. I hadn't noticed that -- though I can see legitimate uses for it in the context of GPIOs. In any case, I'm a little wary of bus_alloc_resource() having side effects. Usually bus_activate_resource() would do that kind of thing. > >>> ------------ The following is a large parenthesis ------------------- >>> >>> One other possible route here that would also work well would be to >>> make ofwbus.c MD (it's a trivial piece of code anyway, so we don't >>> gain a lot by sharing it) and implement ofw_bus_map_intr() locally as >>> an ofwbus bus method. Then you could have the mapping table stored in >>> ofwbus's softc -- the API was designed for this initially. You would >>> need MD extensions for doing PIC registration there (which is fine), >>> but that segregates all the OFW-specific information into >>> OFW-specific code and would let the bus methods and the OFW interrupt >>> mapping table interact cleanly in the same place. This still >>> preserves the pre-r301453 API, makes PowerPC work, and maybe >>> address's skra@'s concern about extensibility and letting core >>> interrupt code know about FDT (or ACPI). I'd be happy to mock this up >>> as well if you think it's a good approach. >>> >> [snip] >>> This has the following features: >>> - Existing OFW API and semantics unchanged >>> - As such, PowerPC, PCI, etc. work fine with no changes >>> - Details encapsulated in MD code, so individual platforms can >>> implement this however they like >>> - arm/arm/intr.c (or whatever) only needs a method to allocate a >>> fresh interrupt, with no state, and anoter to set the device_t for an >>> interrupt sometime later. >>> - The internal table in the platform interrupt code has no knowledge >>> of any mappings whatsoever except having the appropriate device_t for >>> the PIC stored with the interrupt vector. >>> - Device tree bits handled purely in device tree code >>> - No action need be taken on any mapping until the interrupt is >>> actually allocated/set up, like r301453 >>> - Easy to add more mapping mechanisms (e.g. ACPI) by having similar >>> enumeration-mechanism-specific code in the root bus for that mapping >>> mechanism. >>> >>> -------------- End parenthesis ------------------------------- >> Here's an implementation of the parenthesis I wrote on an airplane >> this afternoon. It should be complete, though has not been tested. The >> code is short and simple (+70 lines in ofwbus.c). This preserves the >> pre-r301453 API and semantics relative to drivers, which means PowerPC >> and PCI work out of the box, while keeping the semantics relative to >> the interrupt layer of r301453 (PIC methods only called on resource >> allocation, no allocatable IRQs on unattached PICs, encapsulation of >> OFW-specific code in OFW-specific bits of the tree). It turns out >> those two things are compatible, somewhat to my surprise, and that >> makes the result very clean. I like this approach and would be happy >> to move forward with it. There are five functions of interest: >> >> 1. OFW_BUS_MAP_INTR(). This has the semantics and API it has now: you >> pass an interrupt specifier and parent, you get back an IRQ. No >> changes. This is the core of the normal OFW interrupt API. >> >> 2. OFW_BUS_REGISTER_PIC(device_t pic, phandle_t phandle). This is a >> new function that PIC drivers are supposed to use to register control >> of an interrupt domain. This replaces machine-specific code like >> powerpc_register_pic() to allow the PIC table to be in a bus parent >> rather than in the interrupt core. >> >> 3. PIC_MAP_OFW_INTR(device_t pic, int irq, interrupt specifier). This >> is a new function that PIC drivers that know how to handle device-tree >> interrupt descriptors implement (analogous to various existing ones >> that vary by platform). It tells the PIC that the given abstract IRQ >> means the given opaque interrupt specifier. >> >> 4. arm_allocate_irq(int suggested). This allocates a new IRQ number >> not (yet) attached to a PIC, as in r301453. I've added a parameter >> that lets you pass a suggested number to try in case it is possible to >> make it match an interrupt pin or something for human-readability. >> >> 5. arm_set_pic_for_irq(int irq, device_t). This tells the MD interrupt >> layer to associate a given PIC device_t with an IRQ. That is all the >> information the MD layer ever has about the IRQ mapping. >> >> Functions #1 and #2 are now implemented completely in ofwbus.c: there >> are no callouts anywhere else and the interrupt mapping table is >> maintained entirely internally to ofwbus (in its softc). In order to >> implement ACPI, or some other strategy, you would implement analogs to >> functions #1 and #2 that live somewhere in the bus hierarchy that is >> guaranteed to be above all devices that might want that type of >> interrupt (e.g. in acpi0), and some analog to #3 that PIC drivers >> implementing the mapping scheme would provide. >> >> Since the system interrupt code has no knowledge at all of interrupt >> mapping, of any type, in this scheme, adding new mapping types is >> trivial and can be done on a driver-by-driver basis if necessary >> without changing KPI and without any other part of the system even >> being aware. For example, GPIOs can use a completely different >> mechanism if they want and can do setup purely in the GPIO controller >> driver. You could have a method GPIO_GET_INTERRUPT_FOR_PIN() on a GPIO >> controller in which the GPIO controller allocates a generic IRQ, >> assigns through some internal table just in the GPIO driver, and >> returns to it to a consumer in some other device driver -- without a >> GPIO mapping type, new bus functions, or modifications to the platform >> interrupt code. >> >> The control flow goes like this: >> - Bus driver enumerates children, parses interrupts properties, calls >> OFW_BUS_MAP_INTR() to get IRQs for them (as pre-r301453), adds to >> interrupt list. >> - ofwbus receives the OFW_BUS_MAP_INTR() call, allocates a blank >> disconnected IRQ from the MD interrupt layer, and stores the mapping >> from the new IRQ to the given interrupt specifier and phandle in an >> internal table in ofwbus's softc. >> NB: Nothing else happens here, like post-r301453. Changing this does >> not change any semantics of the API pre-r301453, which means it >> remains fully compatible with PCI and PowerPC. Also, like >> post-r301453, there is no involvement of nexus. >> - PICs attach and call OFW_BUS_REGISTER_PIC(). ofwbus receives these >> messages and adds a (device_t, phandle_t) mapping to a second internal >> table. Note that the interrupt layer does not need to handle PIC >> registration anymore at all (except for the root PIC). >> - Bus child eventually calls a function that tries to set the >> interrupt up (e.g. bus_setup_intr()). That propagates up the bus >> hierarchy, eventually getting to ofwbus. ofwbus notes the IRQ number, >> looks it up in the table, looks up the appropriate PIC from the PIC >> table, then: >> A) calls arm_set_pic_for_irq(irq, pic_device_t) -- this is the >> interrupt layer's only interaction with the mapping code. All it deals >> with is device_ts and abstract IRQ numbers. >> B) calls PIC_MAP_OFW_INTR(pic, irq_number, interrupt-cells, >> interrupt-specifier) to tell the PIC that the interrupt layer's IRQ >> irq_number means the given specifier >> C) finally, passes the call onto nexus, which will do whatever would >> normally happen (unmasking the interrupt, setting handlers, etc.) in >> terms only of the abstract IRQ and the device_t assigned by ofwbus. >> >> You would implement ACPI just by doing a s/OFW/ACPI/g >> search-and-replace above -- since the interrupt layer doesn't know >> about OFW or ACPI or anything else, there is no need to touch it. This >> seems clean, simple, compartmentalized, preserves the existing API, >> and should work on all of our various hardware. PowerPC can't quite >> work with it yet without some multipass foo, but, since the API is >> preserved, that transition can happen gradually without KPI changes. >> For the same reason that it is API-preserving, I think this code is >> also MFC-able. >> -Nathan > I think that we are slightly diverges in this place: > - please note that PIC API (in kern/pic_if.m) is different from the one > that PPC uses. Yes, which is fine (this is machine-dependent code anyway). On consideration, the PIC_MAP_OFW_INTR() function should probably be called OFW_BUS_PIC_MAP_INTR() and live in ofw_bus_if.m anyway, then be implemented by PICs. > - we must be able to store configuration data (original interrupt > specifier) in all cases, not only for OFW. That's reason why I have > proposed > to create 'mapping table'. It is stored in all cases, just not in the core interrupt code. I've only mocked this up for OFW here. For ACPI, you would have the equivalent table in acpi.c, along with ACPI_MAP_INTR(), ACPI_REGISTER_PIC(), etc. in acpi_if.m and implemented in dev/acpica/acpi.c. For GPIOs, you would have a mechanism that just traces however you are representing GPIOs anyway. > Anyway, i think that we both talking about +/- same solution, only i > want to move it from OFW specific level implemented at OFW bus level to > bus/interrupt specifier format independent level implemented in > subr_intr.c. This implements the same API in any case (identical to that pre-r301453), so the implementation doesn't really matter at all in terms of my needs. That said, having it in the root bus for the mapping domain (ofwbus0, acpi0) etc. seems cleaner to me, with no loss of functionality. The core interrupt code (subr_intr.c or whatever) doesn't have any obvious need to know anything at all about the mapping information so long as it knows the PIC device_t that corresponds to every abstract IRQ so that it can mask it or do other operations. Since, presumably, nothing in an ACPI device tree references an interrupt in the OFW device tree (if you even had both -- and how would you specify that, anyway?), implementing the relevant bits one step up the bus hierarchy doesn't change any behavior. And nothing can possibly be more flexible in terms of the mapping table in subr_intr.c than not having a mapping table: you don't need enums for mapping types, or unions that need to be expanded, breaking KBI, or anything. You can delete all the PIC registration (and MSI) code, all the switches, and all the unions from subr_intr.c and have a totally mapping-mechanism-agnostic KPI. > Most of your control flow can be implemented at general level as is, or > already exist [intr_map_irq(), intr_pic_register()] . > Also, impact for current PPC code is, by me, minimal. > I can sketch my idea in more details, if you found it acceptable. All ideas are fine -- and the solution does not need to apply to all platforms anyway, so long as the OFW_BUS_MAP_INTR() semantics (and, ideally, API) are preserved. > Again, I'm sorry for delayed and very brief response. No worries; good luck with the work emergencies. -Nathan > Michal > From owner-freebsd-arm@freebsd.org Tue Aug 2 16:31:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C26CBADA04 for ; Tue, 2 Aug 2016 16:31:14 +0000 (UTC) (envelope-from milne.james@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED1C012FE for ; Tue, 2 Aug 2016 16:31:13 +0000 (UTC) (envelope-from milne.james@gmail.com) Received: by mail-it0-x233.google.com with SMTP id f6so42690672ith.0 for ; Tue, 02 Aug 2016 09:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=e76hbc0+zPY9ViPyV/SPEpNin4Y0g8zduhh2uePHdQQ=; b=wGv0RYRV4xS1iDN3DzYk3VCINJlX/nFTIkNOxX68CI+z4RPRNNM+GgLfrdj+JdIHQ/ ingMabJr49ln2dxUltZr4msYfLIq7onx6wZBlktMzNERVqZZJV0XNEeTtCekXEjT5i39 0M4Vq6fSIUWcy/NvrB/+66KjMWge3OZe85+a1zsVxzuSU2Vf2e+QFGYQz6OXaaYVW1YV WbZXz/szz7K590Fjhcj1WrrP8llVHUCyr+k1zdl32bI509vy++uQmp9MbIv6r33twGc7 qpqAm0OyzBPAbeJel1SciKz81vXrdt1GXoKwIAYh9QBoqVm/ZimhzU7Qnw2LLkAP2lRD Zmpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e76hbc0+zPY9ViPyV/SPEpNin4Y0g8zduhh2uePHdQQ=; b=VFhZKWtQGtoGbXusnDz0UXkWcmarggQ3I28dv72Fjsm3E2Y6nJsHQhtU9iGjsuKaLX agyjHGWq9WA1TCJmk8OpVsMeIQGAeKXYCgLPtrIg33yAN8PdPAo/SCHLaFAPAnwe0LCm gmx4EHXxZ0dY8VAZkv9QRY+m5eCV5pJ1o6sU8ZqMVqF0RVPFlGs06+ekFiFX+zUFjrEw J+0MUt3XeHgRVrRK2m5owbIfy81E3TAHP9036yoxFAmeckZvQg3GQpyW98CE0L/uNtZA QRZMuQFXN9D4cotyZzj3A4aQkysBMADmY+JUlW5lYYe9idCbc0flZzrgCINvlSGDlhpV izbw== X-Gm-Message-State: AEkoousLOIB7SElZuLpiDDW8qAe/2KYcdM7v+qRv28zc3C1fNiTqN2RZWHvl3+Xs+zVWf5rz4l5Iku8mZ36Pdg== X-Received: by 10.36.1.12 with SMTP id 12mr20066463itk.30.1470155473185; Tue, 02 Aug 2016 09:31:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.17 with HTTP; Tue, 2 Aug 2016 09:30:32 -0700 (PDT) From: James Milne Date: Tue, 2 Aug 2016 11:30:32 -0500 Message-ID: Subject: Utilite CM-FX6 FreeBSD with ubldr To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 16:31:14 -0000 I'm having a challenge getting ubldr to see my mmc card (even after I u-boot from it). Specifically: Use the u-boot-utilite u-boot image on the SD card, copy of ubldr after cross build. (Not using crochet) fatload mmc 2 0x10800000 ubldr (not using .bin atm, although both fail) bootelf 0x10800000 I've tried to setenv loaderdev= to about everything I can think of: mmc 0 mmc 2 disk0 etc No luck. Any suggestions? U-Boot SPL 2015.07-cm-fx6-3 (Jul 29 2016 - 01:09:00) Trying to boot from MMC U-Boot 2015.07-cm-fx6-3 (Jul 29 2016 - 01:09:00 +0000) CPU: Freescale i.MX6Q rev1.2 1200 MHz (running at 792 MHz) Reset cause: WDOG Board: CM-FX6 I2C: ready DRAM: 2 GiB NAND: 0 MiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 SF: Detected M25PX16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB In: serial Out: serial Err: serial PCB: 1.0 Net: FEC Hit any key to stop autoboot: 0 CM-FX6 # CM-FX6 # fatload mmc 2 0x10800000 ubldr reading ubldr 267307 bytes read in 29 ms (8.8 MiB/s) CM-FX6 # bootelf 0x10800000 ## Starting application at 0x10800098 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x8f5584d8 FreeBSD/armv6 U-Boot loader, Revision 1.2 (e42@freebsd.test.local, Sun Jul 31 13:35:49 CDT 2016) DRAM: 2048MB Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Number of U-Boot devices: 2 U-Boot env: loaderdev='mmc 0' Found U-Boot device: disk Requested disk type/unit/slice/partition not found Found U-Boot device: net No boot device found! data abort pc : [<8ff55c0c>] lr : [<8ff55c83>] reloc pc : [<17800c0c>] lr : [<17800c83>] sp : 8f554d38 ip : 10830178 fp : 00000002 r10: 8ffa3004 r9 : 8f554eb0 r8 : 00000000 r7 : 00000001 r6 : 8f55c23c r5 : badef1ce r4 : 00000000 r3 : 32470000 r2 : 00a02104 r1 : 0000000d r0 : badef1ce Flags: nZcv IRQs off FIQs off Mode SVC_32 Resetting CPU ... From owner-freebsd-arm@freebsd.org Tue Aug 2 19:55:03 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95E02BAD19C for ; Tue, 2 Aug 2016 19:55:03 +0000 (UTC) (envelope-from michel@universal-devices.com) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0114.outbound.protection.outlook.com [104.47.40.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 415291C35 for ; Tue, 2 Aug 2016 19:55:02 +0000 (UTC) (envelope-from michel@universal-devices.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=universaldevices.onmicrosoft.com; s=selector1-universaldevices-com02c; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k/yR0UdKm0Osg8ir4GtbvmphPZ+aiTjMaZICC4NdmMY=; b=nsp77s9bfc1usFGuyoSAXYBjCqsAur0/OO/nlc4WHevo7VHAEQAx3uwbcpgMHdUyiS73GaKD1ADobIyE+p54UsY3VWlvApCZxkjgeYs/y/Zdk5UtLkr8+S1BBbJz9cWKNaoNWj3e56T15jQNDMlRXHkXcWNoYXwqJOUB+BCmhIg= Received: from SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) by SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 16:20:42 +0000 Received: from SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) by SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) with mapi id 15.01.0549.022; Tue, 2 Aug 2016 16:20:42 +0000 From: Michel Kohanim To: "freebsd-arm@freebsd.org" Subject: Paid Support for iMX6 Port Thread-Topic: Paid Support for iMX6 Port Thread-Index: AdHs1b5KsSu8z2xcTpKjv7T6+miKcw== Date: Tue, 2 Aug 2016 16:20:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michel@universal-devices.com; x-originating-ip: [75.83.36.12] x-ms-office365-filtering-correlation-id: a927c956-11e9-44e4-429a-08d3baf0f2fc x-microsoft-exchange-diagnostics: 1; SN1PR0201MB1534; 6:ayuzdwNgJ24ggaySZyqAfKJejoBu9tCEz81FSolgAt8B/y8GPsMQ042GoDSTw8f+W+fOgIqjkJUyrEdx8QicWRMqsFGtTEDDhVkYu65arBbfwwX3YjLSsjYR44DzAefABmpQCGJUEOslqUIstBskhG20lNpQ9yE02NnOLUalticx5WhfGElpZydK5+s071KX1dJdNzhanY6E7PZl6r/ojtUuhlPVk/yMZLOar3vqCnDT0bylCxZm5wS/XWpIYmBczEriXNe1d5ugHmuA0w3ncqAm1tHI+TfKTaj265iekFuyX7qaiXEbLu1xXGTqb0jt; 5:nhX4tfVSxJGVsL+5RZNUF61O2NdElqzC8S0IvKSK6nNjQGNye0RR7X7Odv5VOKwziJEO49UWpiwhIOEVsmsrXrHdXOyXVuUT5Ho48MTFLbmbzMw5qv+qpZmvEHLlDQgG4ODwqb6TtKMq2DPlCvjJPw==; 24:+GQJOlKEOIA7jmrRRdc/h2u8MgSPleL+p/uAb3eZAUGXakXaC8M43RJFm5tG0N0wO27KNtu/Du1nxVQ3zooH2SRQAcMurfHXgpqI7o7omB0=; 7:T2ZTIeWHtlWbyHh6+yLbH7A2w79QzXtsfgLSHdHs82ZLx9IVmBfnbKfR3CnEFhuUA/5E5omoxRqCnuPATy7/YkNuSPozud1kdO4qRMUVCKeRsEHN26AtY+Na871xjup612q/LMJnlGGsztX5Al4zkcQHvSUK7bupjLpOy9GNIjlu6cbLIEUJJlXw1/RMc8R6EsIKUUT+0XDxMNqbMtD3mSvClYkkTLE0V6WhR3m5a2OlsmYRnd1+x5kl6UPFI1N+ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0201MB1534; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:SN1PR0201MB1534; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0201MB1534; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(71364002)(199003)(2900100001)(11100500001)(66066001)(2501003)(87936001)(7846002)(77096005)(15975445007)(122556002)(586003)(92566002)(5640700001)(8676002)(7906003)(19300405004)(81156014)(5630700001)(81166006)(7696003)(7736002)(19580395003)(189998001)(74316002)(8936002)(10400500002)(99286002)(105586002)(19617315012)(2906002)(68736007)(229853001)(790700001)(102836003)(6116002)(106356001)(450100001)(16601075003)(86362001)(76576001)(3660700001)(110136002)(9686002)(3280700002)(19625215002)(101416001)(97736004)(5002640100001)(16236675004)(33656002)(107886002)(54356999)(50986999)(2351001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0201MB1534; H:SN1PR0201MB1534.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: universal-devices.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: universal-devices.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 16:20:41.7874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d628f750-5cc1-4a42-9d4c-463ac737d54f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1534 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:55:03 -0000 Hello Dear FreeBSD ARM team, We are in the process of migrating our embedded hardware/OS platform and ha= ve decided to go with iMX6 and FreeBSD (we currently have our own real time= operating system). Due to the shortage of time on our side and ever comple= xity and instability of getting crochet to do what we need, I would like to= know whether or not you accept contributions or other types of remuneratio= ns to help us with this endeavor. What we need: 1. Minimalistic kernel and build tools/cross compiler 2. Use Libressl instead of OpenSSL 3. Support for the onboard I2C RTC 4. Support for SDIO and especially onboard WiFi and Bluetooth on the = Quad 5. Support for booting from NAND flash or eMMC 6. Enabling support for hardware cryptography The end result can be shared with the community. Looking forward to hearing back from you. With kind regards, ****************************** Michel Kohanim CEO (p) 818.631.0333 (f) 818.436.0702 http://www.universal-devices.com ****************************** From owner-freebsd-arm@freebsd.org Tue Aug 2 21:04:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34814BADA13 for ; Tue, 2 Aug 2016 21:04:58 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF2F51954 for ; Tue, 2 Aug 2016 21:04:57 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-ua0-x22a.google.com with SMTP id k90so138535009uak.0 for ; Tue, 02 Aug 2016 14:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=z42lwOytiUejqLeg1SAUX36No9H4QS8EFPMA8PDQcDI=; b=Rw6iqutDpWdA8f3bd5OvwUpgu0A6nG9lAxFDwZsk5BlkMwm3dOxqIQRdXG5UbKtrRH 0UIxAEKmfo8iBZJeTDb7Cot/AMmqHx7Qy1YrEvb7dUavXqAySInMrJxhANrHDx24d3+t FsAN/XHyYZYQuyf9nqQzSuAkIcLnugv4oHDmz1s7D5jv6xXPrbmBpgHTmxOZxxqCN02D XA9TwxNDb6c/THbVQtPOSNlM5KmAAp0g0hqFh83lsw8xToJeQ5Ht1ZSXxTFltaDMEywg G4dx8f4ad0dikYmY+n49IJ2d0DFETUS8YY7go8y5DYlyKbpQ3eRJhcl1cXAsHLWvRt0Q uhBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=z42lwOytiUejqLeg1SAUX36No9H4QS8EFPMA8PDQcDI=; b=gU+Kb/VDGYlTZw5PB9T68iqNkdlvLW4xGPmRPHq3l0Y+g++uAFB3x5OsRqSIfYp47J viDNmgoQp9wRRcmHWRsxNMPLMU7bZ7yFzg8w04fp1nHrR2/ApMn4ZD8FGbeOBl8zFM5V nSE0YKrTA13LpoY+6ZZZPeIlpSLA4W0ipuHv4Im1oBA4oPPEb76SdU4Ri7OfX42xrkOM aWKdNmYsvVRvBlCeJgl1UzddgtNCmkn+UK9W5+C1L5mbwQZE37XxiL8cdKZ6Ov1Rs3kJ frejtKa53scn2QfWM8mwdahJi1UonECfNjWCnXomUKv6g9lghK3B5RDSkaHlPgqlUL2l Z1Fg== X-Gm-Message-State: AEkoousQ0HN0/W+a6x/U4TO61KSroNihLySp6jVAuSVN7gjcB/1O8xsEgqOB9tHo+drvvmqFeEPO71QWEsbIsg== X-Received: by 10.159.33.5 with SMTP id 5mr30420458uab.36.1470171896957; Tue, 02 Aug 2016 14:04:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.54.75 with HTTP; Tue, 2 Aug 2016 14:04:56 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Tue, 2 Aug 2016 14:04:56 -0700 Message-ID: Subject: Re: Paid Support for iMX6 Port To: Michel Kohanim , freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 21:04:58 -0000 Hi Michel, I have an on-going interest in the iMX6 family as well. There is a developer who is very experienced and knowledgeable on the platform and may choose to chime in, but here are my notes (in-line). On Tue, Aug 2, 2016 at 9:20 AM, Michel Kohanim wrote: > Hello Dear FreeBSD ARM team, > > We are in the process of migrating our embedded hardware/OS platform and = have decided to go with iMX6 and FreeBSD (we currently have our own real ti= me operating system). Due to the shortage of time on our side and ever comp= lexity and instability of getting crochet to do what we need, I would like = to know whether or not you accept contributions or other types of remunerat= ions to help us with this endeavor. What we need: > > > 1. Minimalistic kernel and build tools/cross compiler I can send you my build notes in the next couple of days. I am building and running a Solid-Run based iMX6 hummingboard (mostly from wiki.freebsd.org/arm though). Do you have a specific SOM you are looking at supporting? The standard src package and tool-chain supports iMX6 and specifically Wandboard and Solid-Run SOMs. > 2. Use Libressl instead of OpenSSL Never done it myself but very keen to see it implemented: https://wiki.freebsd.org/LibreSSL. Stubborn support for openssl still boggles my mind. > 3. Support for the onboard I2C RTC I do not know the state of this > 4. Support for SDIO and especially onboard WiFi and Bluetooth on th= e Quad SDIO is not currently supported by FreeBSD (so none of the bluetooth or NFC or SDIO wifi work), but there is a patch currently in the code review system for basic SDIO access via the CAM bus system. https://reviews.freebsd.org/D4761. This is experimental at best. A shame, lots of new low cost connectivity is starting to use this standard. > 5. Support for booting from NAND flash or eMMC No, there is no support at this time. There is basic NAND support on one of the chips, but it has proven to be too deficient to be of much use (single bit parity, no use of hardware ECC and other major deficiencies). > 6. Enabling support for hardware cryptography I do not know the state of this Another one you have missed is support for SATA. It is not currently supported on iMX6 (although an all-winner bannana-pi has experimental support). Also, my Broadcom PCIe wireless card is not being recognized by FreeBSD on Arm, but was recognized when running PC-BSD on an Intel machine. I would love to see any of these items pushed forward, especially SATA as I have had to start using Debian for my prototype platform due to missing FreeBSD SATA support. Cheers, Russ From owner-freebsd-arm@freebsd.org Tue Aug 2 21:11:03 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FD15BADF93 for ; Tue, 2 Aug 2016 21:11:03 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-ua0-x243.google.com (mail-ua0-x243.google.com [IPv6:2607:f8b0:400c:c08::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A95D13B2 for ; Tue, 2 Aug 2016 21:11:03 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-ua0-x243.google.com with SMTP id m60so8143285uam.3 for ; Tue, 02 Aug 2016 14:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Wl+czionzpJI6DeVCwWS6H+sdyuKh6kFX9l7PYCvbiA=; b=xoYIFj0pcHFh4oWRiKXoB2k8oHbAEFSf3nXBm7KCYWWR6H7EFRC1bYr28v1PCZ4xkc PE0HzCdB4xQbhF735uhXC1yiOeEOhmHeH20ezOrna8ZS1b2kdLiQeSnZE2b3WO+CRT1M ZoqHUmp/Zl3ijLGWPxhThX70/AGywYplAkTr4osqhzeqA7w16REoD5aS9pTXEecvGbts 4j5xsysEYk26outxPwjqbCFrPteggeVoZ81b18kxZ16rrrNiSCHWyBh8rjckU7TzL+Wo OSc28pBHwLuihjDIBPznIl70XdqXMTwisaxnJ7f/KJov75e03K+ixvngYK+kpTPBLmoQ 4o+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Wl+czionzpJI6DeVCwWS6H+sdyuKh6kFX9l7PYCvbiA=; b=gHPUb7BM3UjTYAs2NCgbcDbP8FKm1271pPmTPdEotE7TxQdThad6q5EZH9ylJiOX0A Nn/sAMhGSFbEeUWoZ2cezuojghrdC4Taw9VDSpQmSfRXFHLk1q98xQFN7KJQ/2LXFjDt 8xWzfF3wvgJyme0FQ7KgLmjlFpLLy4FV0iIuqXTZ2ArR+86WIR4dHz4ln7QOMtYjbQX3 mxHMy1IIA+sZiVD4z/8wLEeLcQnMqfweC6fLvIBNOvbpg2GfkC9fK6jOsDjILGtYzx3K N8dJSVGchuCO13giRCF/zj8I7Sckxk8GKEzGRsQEdTvtLNz2Qdr1razgS3AihrF1bBS0 FKRg== X-Gm-Message-State: AEkoouvoLAsWCnRJsJ5gEhPnsX3jr/mYwu+nRQ/8AMvEK+EJSCm/Mm3jqTXNLtkYvFOCIdtOWGNE+gr7i4ggLQ== X-Received: by 10.159.39.39 with SMTP id a36mr30802286uaa.86.1470172262412; Tue, 02 Aug 2016 14:11:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.54.75 with HTTP; Tue, 2 Aug 2016 14:11:01 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Tue, 2 Aug 2016 14:11:01 -0700 Message-ID: Subject: Re: Paid Support for iMX6 Port To: Michel Kohanim , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 21:11:03 -0000 >> 5. Support for booting from NAND flash or eMMC > No, there is no support at this time. There is basic NAND support on > one of the chips, but it has proven to be too deficient to be of much > use (single bit parity, no use of hardware ECC and other major > deficiencies). Sorry, even if there was a driver for it, there is no Filesystem designed to use eMMC or NAND directly. My understanding is typically the flash controller provides a standardized SATA path for accessing the NAND as if it's a disk (yet another developer make speak more to this). GNU/Linux equivalent is yaffs or jfs2 (I think). Cheers, Russ From owner-freebsd-arm@freebsd.org Tue Aug 2 22:12:42 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85D3BBAB5C2 for ; Tue, 2 Aug 2016 22:12:42 +0000 (UTC) (envelope-from michel@universal-devices.com) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0123.outbound.protection.outlook.com [104.47.36.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F4571AF6 for ; Tue, 2 Aug 2016 22:12:41 +0000 (UTC) (envelope-from michel@universal-devices.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=universaldevices.onmicrosoft.com; s=selector1-universaldevices-com02c; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FIjurEO4sKa7zKgryzBGZLEX6t8H0wtey1SDie1GSVM=; b=VM2y7lPqGa+K4/OqwzQ+1GPmDWuPzsjyYkBBBk9X/L6bWZ6ip2BvZOuKBlBDgbKtejEl5jJ0z1IsHoqblEx5Y8Er7wazf52BD1dVfQNt0yByvaFK75dmri8mDUXn3qxhc+lDI2dRXsJ8Zm3/Xa+TFKLMDOQ3yyjw8T0rAGiD9Ko= Received: from SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) by SN1PR0201MB1535.namprd02.prod.outlook.com (10.163.129.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 21:39:19 +0000 Received: from SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) by SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) with mapi id 15.01.0549.022; Tue, 2 Aug 2016 21:39:20 +0000 From: Michel Kohanim To: Russell Haley , freebsd-arm Subject: RE: Paid Support for iMX6 Port Thread-Topic: Paid Support for iMX6 Port Thread-Index: AdHs1b5KsSu8z2xcTpKjv7T6+miKcwAK8ckAAACUROA= Date: Tue, 2 Aug 2016 21:39:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michel@universal-devices.com; x-originating-ip: [75.83.36.12] x-ms-office365-filtering-correlation-id: b0d4dfb6-d596-42ac-e52c-08d3bb1d7684 x-microsoft-exchange-diagnostics: 1; SN1PR0201MB1535; 6:m7xL9Uibkr3gL5t1y/0KJHzlJFgrH70csr0EqD3C0Yol/1DZ3Q3aZAWfaciTjuUUjxhC836E/OaRALhChQ/9t2vU/f9wb+SOQUf+/7R1AUgm1gC/ZkBsnpeTTZkWwwqSSZx+2GoH8sxNKys5xcKgP1Ungbyq+xvmOjNEdIpb6mx94mSqg/CZV8zjiGcZlri4Ep+lWzGp7ydTWWBELfdMSwSkyThlQPVPLQqOEXj0QSMQOSY7kDqOegvj7tgugePl3pBpynvh3Gk1r5xDiBQac/jvm3kNN4dO/yt1D7p0v5IYePZITssH07FCS/aRIVU/; 5:4QbM03MrXxkVOdql/+86qEH+E1dB3CnobNf1ukYZ4Rt1UFqLlVyDjgD4Ypz+6XyWZWyMdJX/uVNjOeuhkPoQ9q/nkdjwMIigf6v5rrYVfIg4rMl6P+LRVRTey7sA8b1YnFJdnMMdhCNUMxetunCR2w==; 24:u1ZZ+AeUtLsXWQPv2ORuo/ouk92ba8KiHyk1jJLABZ/kJ9Ltpr9dH4q4LvEEk5Qi6bS3ZsgvDt17KOE8FjFzbO489jC3trFk2ocNs/5u6mY=; 7:Fe/Pyh3whh7uu3PZO90YlppdDlTV6pepfVaeF27LHtoaMGhITWXsE7KegjROQGg/6CrkbjGO/Pd8cBclBpRWOm0xqPaiS6V29UPRFaBGwp8yHf70qff5VOcFvYvkQzHaFf0tTFfBvAsIB88R2++uM+pLqoReQA3QiL/McOYh3JcRIIo2fICmP0PRIq1uj8nBPDluki1gjH6NQFPXpoEsumXF4wQutgyq62nzed0haH5eokOGnbpJnnODp9le5nA5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0201MB1535; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:SN1PR0201MB1535; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0201MB1535; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(43784003)(71364002)(24454002)(13464003)(199003)(189002)(33656002)(122556002)(106356001)(87936001)(19580405001)(19580395003)(81166006)(54356999)(50986999)(92566002)(3660700001)(81156014)(10400500002)(102836003)(3280700002)(3846002)(86362001)(76176999)(68736007)(586003)(6116002)(8936002)(2950100001)(2900100001)(99286002)(8676002)(16601075003)(5002640100001)(77096005)(15975445007)(107886002)(7846002)(97736004)(189998001)(66066001)(76576001)(2906002)(5001770100001)(101416001)(74316002)(7696003)(7736002)(5890100001)(9686002)(105586002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0201MB1535; H:SN1PR0201MB1534.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: universal-devices.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: universal-devices.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 21:39:20.3766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d628f750-5cc1-4a42-9d4c-463ac737d54f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1535 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:12:42 -0000 SGkgUnVzc2VsbCwNCg0KVGhhbmtzIHNvIHZlcnkgbXVjaCBmb3IgZ2V0dGluZyBpbiB0b3VjaC4g SG9wZWZ1bGx5IHRoZSBleHBlcmllbmNlZCBpTVg2IGRldmVsb3BlciB3aWxsIGNoaW1lIGluLiBB Z2FpbiwgSSBhbSB3aWxsaW5nIHRvIHBheSBmb3Igc2VydmljZXMgYW5kIHRoZW4gc2hhcmUgdGhl IHJlc3VsdHMgd2l0aCB0aGUgY29tbXVuaXR5Lg0KDQoxLiBXb3VsZCBsb3ZlIHRvIHJlYWQgeW91 ciBub3RlcyBvbiBIdW1taW5nYm9hcmQuIEkgYW0gdXNpbmcgV2FuZGJvYXJkIGFuZCBXYW5kYm9h cmQgRHVhbCBmb3IgdGVzdGluZyBwdXJwb3NlcyBhbmQgaGF2ZSBiZWVuIGFibGUgdG8gZ2V0IEZy ZWVCU0QgYmluYXJ5IGltYWdlIChmcm9tIHRoZSB3ZWJzaXRlKSBsb2FkZWQgYW5kIGZ1bmN0aW9u aW5nIGFsYmVpdCBpdCdzIHdheSB0b28gc2xvdyBldmVuIGZvciBydWRpbWVudGFyeSB0YXNrcyBz dWNoIGFzIHZpIChvbiB0aGUgU29sbykuIEkgc3VzcGVjdCA1MTJNQiBpcyBub3Qgc3VmZmljaWVu dC4gVWx0aW1hdGVseSwgSSB3b3VsZCBsaWtlIHRvIGJlIGFibGUgdG8gbWFrZSBhIHNtYWxsZXIg aW1hZ2Ugb3Vyc2VsdmVzIGJ1dCBoYXZlIGJlZW4gaGF2aW5nIGEgaGVsbCBvZiBhIHRpbWUgd2l0 aCBDcm9jaGV0DQoNCjIuIFRoZSB1bHRpbWF0ZSBwbGFuIGlzIHRvIHVzZSBpTVggU0NNIHdoaWNo IGlzIGEgY2hpcCB3aXRoIFJBTSBhbHJlYWR5IHB1c2hlZCBvbiB0aGUgdG9wLiBUaGlzIHdpbGwg cmVkdWNlIGJvYXJkIHNpemUNCg0KMy4gSSBkZXRlc3QgT3BlblNTTCAuLi4gaXQncyBqdXN0IHdh eSB0b28gYmxvYXRlZCBhbmQgSSBjb3VsZG4ndCBkaXNsb2RnZSBpdCBmcm9tIG15IHJ1bm5pbmcg RnJlZUJTRCBkZXNrdG9wIChoYWQgdG8gcmVpbnN0YWxsIGV2ZXJ5dGhpbmcpDQoNCjQuIFNESU8g aXMgbm90IGFzIHVyZ2VudCBzaW5jZSB3ZSBjYW4gdXNlIHRob3NlIGxpdHRsZSBVU0Igc3RpY2tz IGZvciBXaUZpIGFuZCBCbHVldG9vdGggKEkgaGF2ZSBvbmUgYXR0YWNoZWQgdG8gV2FuZGJvYXJk IGFuZCBpdCB3b3JrcyBmaW5lKS4gVGhpcyBzYWlkIC0gYW5kIGlmIHdlIGNhbm5vdCB1c2Ugc29t ZSB0eXBlIG9mIGZsYXNoIGZvciB0aGUgb3BlcmF0aW5nIHN5c3RlbSAtIHRoZW4gd2UgY2Fubm90 IHVzZSBhbiBleHRyYSBTRCBDYXJkIHNpbmNlIHRoZSBtYWluIG9uZSBpcyBiZWluZyB1c2VkIGJ5 IHRoZSBPUw0KDQo1LiBSVEMgb24gSTJDIC4uLiBpTVggYWxyZWFkeSBoYXMgYW4gUlRDIG9uIGJv YXJkLiBTbywgaXQgd291bGQgYmUgcXVpdGUgc2hhbWVmdWwgaWYgd2Ugd2lsbCBoYXZlIHRvIHB1 dCBhbm90aGVyIFJUQyBvbiBib2FyZCBqdXN0IGJlY2F1c2Ugd2UgY2Fubm90IGdldCBGcmVlQlNE IHRvIGNvbW11bmljYXRlIHdpdGggdGhlIGludGVybmFsIFJUQw0KDQo2LiBOQU5EIGZsYXNoL2VN TUMgLi4uIG91ciBtYWluIGdvYWwgaXMgdGhhdCAtIGF0IHRoZSBtaW5pbXVtIC0gdGhlIGtlcm5l bCBzaG91bGQgYmUgb24gYSBmbGFzaCBjaGlwIG9mIHNvbWUgc29ydCBzbyB0aGF0IGJvb3QgdXAg ZG9lcyBOT1QgcmVxdWlyZSBhbiBTRCBDYXJkLiBBcmUgeW91IGF3YXJlIG9mIGFueSBmbGFzaCBj aGlwIHRoYXQgY2FuIGJlIHVzZWQgYnkgdWJvb3QgdG8gYm9vdCBGcmVlQlNEPw0KDQo3LiBpTVg2 IGFscmVhZHkgaGFzIGNyeXB0b2dyYXBoaWMgYWNjZWxlcmF0b3JzIC4uLiBpdCB3b3VsZCBiZSBx dWl0ZSBhIHNoYW1lIGlmIHdlIGNhbm5vdCB1c2UgdGhlbQ0KDQo4LiBTQVRBIC4uLiBtYXkgYmUg YW4gaW50ZXJlc3Rpbmcgb3B0aW9uIGluc3RlYWQgb2YgdXNpbmcgZmxhc2guIFRoZSBtYWluIGlz c3VlIGlzIHRoYXQgb3VyIHByb2R1Y3RzIGFyZSBwcmljZSBzZW5zaXRpdmUgYW5kIHVzaW5nIFNB VEEgYWRkcyBhdCBsZWFzdCAkMTAuMDAgdG8gdGhlIEJPTS4gQXMgc3VjaCAtIG9yIHVubGVzcyBJ IGFtIG1pc3Rha2VuIG9uIHRoZSBwcmljZSAtIFNBVEEgaXMgbm90IGEgcmVxdWlyZW1lbnQgZm9y IG1lDQoNClRoYW5rcyBhZ2Fpbi4NCg0KDQpXaXRoIGtpbmQgcmVnYXJkcywNCg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQrCoCBNaWNoZWwgS29oYW5pbQ0KwqAgQ0VPDQrCoA0KwqAg KHApIDgxOC42MzEuMDMzMw0KwqAgKGYpwqAgODE4LjQzNi4wNzAyDQrCoCBodHRwOi8vd3d3LnVu aXZlcnNhbC1kZXZpY2VzLmNvbSANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnVzc2VsbCBIYWxleSBbbWFpbHRvOnJ1 c3MuaGFsZXlAZ21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyLCAyMDE2IDI6MDUg UE0NClRvOiBNaWNoZWwgS29oYW5pbSA8bWljaGVsQHVuaXZlcnNhbC1kZXZpY2VzLmNvbT47IGZy ZWVic2QtYXJtIDxmcmVlYnNkLWFybUBmcmVlYnNkLm9yZz4NClN1YmplY3Q6IFJlOiBQYWlkIFN1 cHBvcnQgZm9yIGlNWDYgUG9ydA0KDQpIaSBNaWNoZWwsDQoNCkkgaGF2ZSBhbiBvbi1nb2luZyBp bnRlcmVzdCBpbiB0aGUgaU1YNiBmYW1pbHkgYXMgd2VsbC4gVGhlcmUgaXMgYSBkZXZlbG9wZXIg d2hvIGlzIHZlcnkgZXhwZXJpZW5jZWQgYW5kIGtub3dsZWRnZWFibGUgb24gdGhlIHBsYXRmb3Jt IGFuZCBtYXkgY2hvb3NlIHRvIGNoaW1lIGluLCBidXQgaGVyZSBhcmUgbXkgbm90ZXMgKGluLWxp bmUpLg0KDQoNCk9uIFR1ZSwgQXVnIDIsIDIwMTYgYXQgOToyMCBBTSwgTWljaGVsIEtvaGFuaW0g PG1pY2hlbEB1bml2ZXJzYWwtZGV2aWNlcy5jb20+IHdyb3RlOg0KPiBIZWxsbyBEZWFyIEZyZWVC U0QgQVJNIHRlYW0sDQo+DQo+IFdlIGFyZSBpbiB0aGUgcHJvY2VzcyBvZiBtaWdyYXRpbmcgb3Vy IGVtYmVkZGVkIGhhcmR3YXJlL09TIHBsYXRmb3JtIGFuZCBoYXZlIGRlY2lkZWQgdG8gZ28gd2l0 aCBpTVg2IGFuZCBGcmVlQlNEICh3ZSBjdXJyZW50bHkgaGF2ZSBvdXIgb3duIHJlYWwgdGltZSBv cGVyYXRpbmcgc3lzdGVtKS4gRHVlIHRvIHRoZSBzaG9ydGFnZSBvZiB0aW1lIG9uIG91ciBzaWRl IGFuZCBldmVyIGNvbXBsZXhpdHkgYW5kIGluc3RhYmlsaXR5IG9mIGdldHRpbmcgY3JvY2hldCB0 byBkbyB3aGF0IHdlIG5lZWQsIEkgd291bGQgbGlrZSB0byBrbm93IHdoZXRoZXIgb3Igbm90IHlv dSBhY2NlcHQgY29udHJpYnV0aW9ucyBvciBvdGhlciB0eXBlcyBvZiByZW11bmVyYXRpb25zIHRv IGhlbHAgdXMgd2l0aCB0aGlzIGVuZGVhdm9yLiBXaGF0IHdlIG5lZWQ6DQo+DQo+DQo+IDEuICAg ICAgIE1pbmltYWxpc3RpYyBrZXJuZWwgYW5kIGJ1aWxkIHRvb2xzL2Nyb3NzIGNvbXBpbGVyDQpJ IGNhbiBzZW5kIHlvdSBteSBidWlsZCBub3RlcyBpbiB0aGUgbmV4dCBjb3VwbGUgb2YgZGF5cy4g SSBhbSBidWlsZGluZyBhbmQgcnVubmluZyBhIFNvbGlkLVJ1biBiYXNlZCBpTVg2IGh1bW1pbmdi b2FyZCAobW9zdGx5IGZyb20gd2lraS5mcmVlYnNkLm9yZy9hcm0gdGhvdWdoKS4gRG8geW91IGhh dmUgYSBzcGVjaWZpYyBTT00geW91IGFyZSBsb29raW5nIGF0IHN1cHBvcnRpbmc/IFRoZSBzdGFu ZGFyZCBzcmMgcGFja2FnZSBhbmQgdG9vbC1jaGFpbiBzdXBwb3J0cyBpTVg2IGFuZCBzcGVjaWZp Y2FsbHkgV2FuZGJvYXJkIGFuZCBTb2xpZC1SdW4gU09Ncy4NCg0KPiAyLiAgICAgICBVc2UgTGli cmVzc2wgaW5zdGVhZCBvZiBPcGVuU1NMDQpOZXZlciBkb25lIGl0IG15c2VsZiBidXQgdmVyeSBr ZWVuIHRvIHNlZSBpdCBpbXBsZW1lbnRlZDoNCmh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9MaWJy ZVNTTC4gU3R1YmJvcm4gc3VwcG9ydCBmb3Igb3BlbnNzbCBzdGlsbCBib2dnbGVzIG15IG1pbmQu DQoNCj4gMy4gICAgICAgU3VwcG9ydCBmb3IgdGhlIG9uYm9hcmQgSTJDIFJUQw0KSSBkbyBub3Qg a25vdyB0aGUgc3RhdGUgb2YgdGhpcw0KDQo+IDQuICAgICAgIFN1cHBvcnQgZm9yIFNESU8gYW5k IGVzcGVjaWFsbHkgb25ib2FyZCBXaUZpIGFuZCBCbHVldG9vdGggb24gdGhlIFF1YWQNClNESU8g aXMgbm90IGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgRnJlZUJTRCAoc28gbm9uZSBvZiB0aGUgYmx1 ZXRvb3RoIG9yIE5GQyBvciBTRElPIHdpZmkgd29yayksIGJ1dCB0aGVyZSBpcyBhIHBhdGNoIGN1 cnJlbnRseSBpbiB0aGUgY29kZSByZXZpZXcgc3lzdGVtIGZvciBiYXNpYyBTRElPIGFjY2VzcyB2 aWEgdGhlIENBTSBidXMgc3lzdGVtLg0KaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Q0NzYx LiBUaGlzIGlzIGV4cGVyaW1lbnRhbCBhdCBiZXN0LiAgQSBzaGFtZSwgbG90cyBvZiBuZXcgbG93 IGNvc3QgY29ubmVjdGl2aXR5IGlzIHN0YXJ0aW5nIHRvIHVzZSB0aGlzIHN0YW5kYXJkLg0KDQo+ IDUuICAgICAgIFN1cHBvcnQgZm9yIGJvb3RpbmcgZnJvbSBOQU5EIGZsYXNoIG9yIGVNTUMNCk5v LCB0aGVyZSBpcyBubyBzdXBwb3J0IGF0IHRoaXMgdGltZS4gVGhlcmUgaXMgYmFzaWMgTkFORCBz dXBwb3J0IG9uIG9uZSBvZiB0aGUgY2hpcHMsIGJ1dCBpdCBoYXMgcHJvdmVuIHRvIGJlIHRvbyBk ZWZpY2llbnQgdG8gYmUgb2YgbXVjaCB1c2UgKHNpbmdsZSBiaXQgcGFyaXR5LCBubyB1c2Ugb2Yg aGFyZHdhcmUgRUNDIGFuZCBvdGhlciBtYWpvciBkZWZpY2llbmNpZXMpLg0KDQo+IDYuICAgICAg IEVuYWJsaW5nIHN1cHBvcnQgZm9yIGhhcmR3YXJlIGNyeXB0b2dyYXBoeQ0KSSBkbyBub3Qga25v dyB0aGUgc3RhdGUgb2YgdGhpcw0KDQpBbm90aGVyIG9uZSB5b3UgaGF2ZSBtaXNzZWQgaXMgc3Vw cG9ydCBmb3IgU0FUQS4gSXQgaXMgbm90IGN1cnJlbnRseSBzdXBwb3J0ZWQgb24gaU1YNiAoYWx0 aG91Z2ggYW4gYWxsLXdpbm5lciBiYW5uYW5hLXBpIGhhcyBleHBlcmltZW50YWwgc3VwcG9ydCku IEFsc28sIG15IEJyb2FkY29tIFBDSWUgd2lyZWxlc3MgY2FyZCBpcyBub3QgYmVpbmcgcmVjb2du aXplZCBieSBGcmVlQlNEIG9uIEFybSwgYnV0IHdhcyByZWNvZ25pemVkIHdoZW4gcnVubmluZyBQ Qy1CU0Qgb24gYW4gSW50ZWwgbWFjaGluZS4NCg0KSSB3b3VsZCBsb3ZlIHRvIHNlZSBhbnkgb2Yg dGhlc2UgaXRlbXMgcHVzaGVkIGZvcndhcmQsIGVzcGVjaWFsbHkgU0FUQSBhcyBJIGhhdmUgaGFk IHRvIHN0YXJ0IHVzaW5nIERlYmlhbiBmb3IgbXkgcHJvdG90eXBlIHBsYXRmb3JtIGR1ZSB0byBt aXNzaW5nIEZyZWVCU0QgU0FUQSBzdXBwb3J0Lg0KDQoNCkNoZWVycywNCg0KUnVzcw0K From owner-freebsd-arm@freebsd.org Tue Aug 2 22:15:36 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3740BAB60D for ; Tue, 2 Aug 2016 22:15:36 +0000 (UTC) (envelope-from michel@universal-devices.com) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0122.outbound.protection.outlook.com [104.47.38.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68FB11BA2 for ; Tue, 2 Aug 2016 22:15:35 +0000 (UTC) (envelope-from michel@universal-devices.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=universaldevices.onmicrosoft.com; s=selector1-universaldevices-com02c; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=whF1kCh+pGdwL0pc4T57eiMJ+1gDgzeeDBxmrkc/+Dg=; b=JdXSNsE5RcD6tOKU1TRKEyatREPtSj6O0gm1AW5+/kX9GNMZqkluBEzVPcT1YIq1x1jJ9Fma+cf4/HmroNzoPxY40h/GMVtYRzyjwYoLpymPz6KFif7hWbM1jKj8+pmwHdduyGTw2Om1MTK/8o138fBE7aVqsKJB5S8nB79OIYU= Received: from SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) by SN1PR0201MB1536.namprd02.prod.outlook.com (10.163.129.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 21:41:41 +0000 Received: from SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) by SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) with mapi id 15.01.0549.022; Tue, 2 Aug 2016 21:41:43 +0000 From: Michel Kohanim To: Russell Haley , freebsd-arm Subject: RE: Paid Support for iMX6 Port Thread-Topic: Paid Support for iMX6 Port Thread-Index: AdHs1b5KsSu8z2xcTpKjv7T6+miKcwAK8ckAAAA2ZIAAAQPQAA== Date: Tue, 2 Aug 2016 21:41:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michel@universal-devices.com; x-originating-ip: [75.83.36.12] x-ms-office365-filtering-correlation-id: 0ac963b6-311a-4070-9608-08d3bb1dcb63 x-microsoft-exchange-diagnostics: 1; SN1PR0201MB1536; 6:26scrDO7z5f9aa+S1qUUFRyuBkXxq1tyBhzppNRV+kDgSERnlnqyYba7AU0Wm2nAfczT0MIB0izZDCzpgYKIh0MkrljZmydWTZZml+HEKQMIypoR63LFkqI+aG/5nUXgJ1sZSr3G9h+ySteOBetBmtqcMHudP5WHxmCPiIk1zbWXE6omy46QYFYbu8jvi2JbPckJb4ZnWWtsn/7nLWipuGzPFfcDhIh5GEl3oFYGusWh8+wogC50Zh9AI55UxSNk9Vh/zdb2XiDT+VXpLEkSXnYsaq/NOZtBEjuRhIAJykau6MSz81jZkxVmCu64eaHS; 5:bTk34c3SRQUyHYdpj4hbBzr/FVziUTAAIBayuJ44o9PBgVf9QetUYQqiOhWcJgDxgxZyDuXrzfxScgXQwmaRZDGOEPzg70CNklz2HUMzlLQ4fFEE95YY0Whd2j99OR+gnivVigbEl5X00JGA67WkXA==; 24:rdqij+2T56qQU7zOMk4zJ7NxP+1Cr4U+pMZqw4mlODLayyGWTl8v9mvrLclv5VIbyAVy0MWh03K9rNr9mp4hnSNAJQne8AfBqSBH2ACphy8=; 7:ekBLbQBEayZl0WxRuuCoY4DQoMUdgja0DtfaCi2XgI0XAxYZIsVqY1Y7xhhoiv/1JR7hJdvohVeMmjA5uWzJJQxVLx534Ryzi53cg88gMUELLrm6UGNQ9IivyP5EkoG0Pj6atNMCxHJ9lWF3S/lOJq/5CagMNtLicDNJDG6uv4AkVnKHVPkGOVRCKURcn4S+M4DO9MqVCQhejhhEs9EcLmCw3BGbUxcwaCQjENrwaNGxPZZgYGjWGlOpt9qXvhrZ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0201MB1536; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:SN1PR0201MB1536; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0201MB1536; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(199003)(71364002)(189002)(86362001)(76176999)(87936001)(9686002)(101416001)(50986999)(54356999)(106356001)(74316002)(77096005)(15975445007)(99286002)(105586002)(68736007)(5002640100001)(10400500002)(122556002)(76576001)(6116002)(305945005)(586003)(5001770100001)(3280700002)(16601075003)(92566002)(3660700001)(2950100001)(7846002)(8676002)(189998001)(102836003)(2900100001)(33656002)(107886002)(81156014)(97736004)(2906002)(3846002)(66066001)(8936002)(19580395003)(19580405001)(7696003)(7736002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0201MB1536; H:SN1PR0201MB1534.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: universal-devices.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: universal-devices.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 21:41:42.8367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d628f750-5cc1-4a42-9d4c-463ac737d54f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1536 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:15:36 -0000 SGkgUnVzc2VsbCwgdGhhbmsgeW91Lg0KDQpJZiB3ZSBjYW5ub3QgYm9vdCBmcm9tIGFuIG9uYm9h cmQgZmxhc2gsIHRoaXMgd2lsbCBiZSBhIGRlYWwgYnJlYWtlciBmb3IgdXMuIEluIG91ciBjdXJy ZW50IGhhcmR3YXJlLCB5b3UgY2FuIHRha2UgdGhlIFNEIENhcmQgb3V0IGFuZCB0aGUgc3lzdGVt IHN0aWxsIGJvb3RzIHVwLiBGdXJ0aGVybW9yZSwgeW91IGNhbiBwdXQgYSBjb21wbGV0ZWx5IGJs YW5rIFNEIENhcmQgYW5kIHRoZW4gcmVpbnN0YWxsIGV2ZXJ5dGhpbmcgc2luY2UgdGhlIHN5c3Rl bSBpcyBydW5uaW5nLg0KDQpXaXRoIGtpbmQgcmVnYXJkcywNCg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQrCoCBNaWNoZWwgS29oYW5pbQ0KwqAgQ0VPDQrCoA0KwqAgKHApIDgxOC42 MzEuMDMzMw0KwqAgKGYpwqAgODE4LjQzNi4wNzAyDQrCoCBodHRwOi8vd3d3LnVuaXZlcnNhbC1k ZXZpY2VzLmNvbSANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnVzc2VsbCBIYWxleSBbbWFpbHRvOnJ1c3MuaGFsZXlA Z21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyLCAyMDE2IDI6MTEgUE0NClRvOiBN aWNoZWwgS29oYW5pbSA8bWljaGVsQHVuaXZlcnNhbC1kZXZpY2VzLmNvbT47IGZyZWVic2QtYXJt IDxmcmVlYnNkLWFybUBmcmVlYnNkLm9yZz4NClN1YmplY3Q6IFJlOiBQYWlkIFN1cHBvcnQgZm9y IGlNWDYgUG9ydA0KDQo+PiA1LiAgICAgICBTdXBwb3J0IGZvciBib290aW5nIGZyb20gTkFORCBm bGFzaCBvciBlTU1DDQo+IE5vLCB0aGVyZSBpcyBubyBzdXBwb3J0IGF0IHRoaXMgdGltZS4gVGhl cmUgaXMgYmFzaWMgTkFORCBzdXBwb3J0IG9uIA0KPiBvbmUgb2YgdGhlIGNoaXBzLCBidXQgaXQg aGFzIHByb3ZlbiB0byBiZSB0b28gZGVmaWNpZW50IHRvIGJlIG9mIG11Y2ggDQo+IHVzZSAoc2lu Z2xlIGJpdCBwYXJpdHksIG5vIHVzZSBvZiBoYXJkd2FyZSBFQ0MgYW5kIG90aGVyIG1ham9yIA0K PiBkZWZpY2llbmNpZXMpLg0KU29ycnksIGV2ZW4gaWYgdGhlcmUgd2FzIGEgZHJpdmVyIGZvciBp dCwgdGhlcmUgaXMgbm8gRmlsZXN5c3RlbSBkZXNpZ25lZCB0byB1c2UgZU1NQyBvciBOQU5EIGRp cmVjdGx5LiBNeSB1bmRlcnN0YW5kaW5nIGlzIHR5cGljYWxseSB0aGUgZmxhc2ggY29udHJvbGxl ciBwcm92aWRlcyBhIHN0YW5kYXJkaXplZCBTQVRBIHBhdGggZm9yIGFjY2Vzc2luZyB0aGUgTkFO RCBhcyBpZiBpdCdzIGEgZGlzayAoeWV0IGFub3RoZXIgZGV2ZWxvcGVyIG1ha2Ugc3BlYWsgbW9y ZSB0byB0aGlzKS4gR05VL0xpbnV4IGVxdWl2YWxlbnQgaXMgeWFmZnMgb3IgamZzMiAoSSB0aGlu aykuDQoNCkNoZWVycywNCg0KUnVzcw0K From owner-freebsd-arm@freebsd.org Tue Aug 2 22:16:57 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA998BAB670 for ; Tue, 2 Aug 2016 22:16:57 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 632CE1C0A for ; Tue, 2 Aug 2016 22:16:57 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x232.google.com with SMTP id s189so133118614vkh.1 for ; Tue, 02 Aug 2016 15:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=F1NS7yemO7spkUdmWGaYqiERYCI96MotUCAnjPFjPpM=; b=LBRZRKJyKIWiHVqouIoquaWszj7oM/usXIDEKdMNHUg5T6rwy+GZzae33BLvfXjJFy DhHMykmaiblcdh0GBtQA3ZMBafvSG01iXHXsWIocu10YCV7U/pfm8SN57l9pH2IjO3EV BpRAx5lxEBvL6l6b6B6AmPm1LRZBrLr519Lgj3pHel+LXNG51v2uMQ67oLrQrZZhJC96 YvrE47KgAXZrM/XIYkTiMMxL0fqAkPCrq6LZszYdy/BlsA4mKp47AsHZBopIMQPy4Dc+ l7RcCuhxDOSYJXbmLfegzfbn9w2kbyj+D4JrRl9qpNrjwNICAN4RbvgDnSsJ+duDWQYh T4Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=F1NS7yemO7spkUdmWGaYqiERYCI96MotUCAnjPFjPpM=; b=Q3mkF300We680PhQSdJHHWD/xdAQ7Kyf5KwIF8q37z04ds+F74WtaR4TNMuHddvNQ4 cpNtrba3dj2wnY2fAWwJaSqSyRxtRh/onXBVm2mc1p5+b0GhJmrZvMPliOMGwCmKkk7D 4gBp3gnLw9MtBqgjkJgo7Px3JmGlTrBo6BmpxKf9s+ELBW3hFMANFDkCijIvT9q3oMB4 S+Sr8YEqoTF0gXhTuzIkFTRTp+PTt5DbkyNOtWeDFgpfAx6SCRFgoCwMWw9EKJSoQ7WT KTvfEoH55i7IFIXK+mas6HKx9op6GuGV08P+/5JkpFZB4gezf1rGPRSUbZudni8+hbo5 4PvA== X-Gm-Message-State: AEkoouuVmrjxpmnQYRpaXC0vgYJ+WaYcZInJBs4WDoiBYBI0oxyYiSGUShXTlMIar7X3OtID2VgxjEfUdt1WgQ== X-Received: by 10.31.230.194 with SMTP id d185mr30479804vkh.143.1470176216382; Tue, 02 Aug 2016 15:16:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.208.4 with HTTP; Tue, 2 Aug 2016 15:16:55 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Tue, 2 Aug 2016 15:16:55 -0700 Message-ID: Subject: Fwd: Paid Support for iMX6 Port To: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:16:57 -0000 Sorry, reply instead of reply all... ---------- Forwarded message ---------- From: Russell Haley Date: Tue, Aug 2, 2016 at 3:16 PM Subject: Re: Paid Support for iMX6 Port To: Michel Kohanim On Tue, Aug 2, 2016 at 2:39 PM, Michel Kohanim wrote: > Hi Russell, > > Thanks so very much for getting in touch. Hopefully the experienced iMX6 = developer will chime in. Again, I am willing to pay for services and then s= hare the results with the community. > > 1. Would love to read your notes on Hummingboard. I am using Wandboard an= d Wandboard Dual for testing purposes and have been able to get FreeBSD bin= ary image (from the website) loaded and functioning albeit it's way too slo= w even for rudimentary tasks such as vi (on the Solo). I suspect 512MB is n= ot sufficient. Ultimately, I would like to be able to make a smaller image = ourselves but have been having a hell of a time with Crochet Give me a few days, I just got back from vacation and kids don't sleep well during summer hours so I have very limited time right now, but I will get you what I have so far. > 6. NAND flash/eMMC ... our main goal is that - at the minimum - the kerne= l should be on a flash chip of some sort so that boot up does NOT require a= n SD Card. Are you aware of any flash chip that can be used by uboot to boo= t FreeBSD? It's possible to run u-boot from NAND and then run ubldr/kernel from a different source. It may even be possible to manually load ubldr from NAND (or even manually load the kernel from NAND in u-boot) but you would need to find an alternative for the kernel and rootfs, especially if you want to update your kernel ever. Not what I would call desirable, but I have *heard* of production systems running like this. > 8. SATA ... may be an interesting option instead of using flash. The main= issue is that our products are price sensitive and using SATA adds at leas= t $10.00 to the BOM. As such - or unless I am mistaken on the price - SATA = is not a requirement for me Hmmm... at work we use an apacer solder on 2 GB chip that comes in considerably under $10 I believe. Not sure if a little 2GB chip is still available. http://us.apacer.com/products/SDC4-18-pin. Regardless, there is no support at this time. Russ From owner-freebsd-arm@freebsd.org Tue Aug 2 22:20:34 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0566FBAB6F4 for ; Tue, 2 Aug 2016 22:20:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6EA51CB0 for ; Tue, 2 Aug 2016 22:20:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-pf0-x230.google.com with SMTP id h186so70145866pfg.3 for ; Tue, 02 Aug 2016 15:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4MVIxfiXtiO4OLQB4UxA7yq42CiM7ZPj564i77X3pCo=; b=0Dk6wvlSKun9xQNY4i89hfE8aYd2oFlNdBGiq2I+fSgFUagPmRs3MER4wHADAYEjv2 ZVswEJhLdNsHlvDcs3w8ppq2A/H2P6FvHSuuYxOUers75DFHp0Y/bsfn01jtBK3An5wg 1JfDvnl7CasYwSkRWaQfkVwJmLJ0kaanRduJ1uMN0T8GcXInY5RIpVaYCA71ca2CvkNq KWgjauADO+6i8Q3n6jSi51efQ+hwpEKYe2o6BaXTuSlQprlIHhbSjADmb5HYWbgM2zLQ i8cQMysfZKp9sD7FrdvSyxumbVQYJfONBsDpcuemKTOmeGVsMav3Q73A2c9MuMwNMjMP AvJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4MVIxfiXtiO4OLQB4UxA7yq42CiM7ZPj564i77X3pCo=; b=Kj4RDMdaNg3sBACEy6caqCg1503KPZg9XDoAu8+COmbQXa4XG/TU1LCCxGLluCoeFn jYlFMyDgpEq12QB+etnLKB7YOqhXbRAxHZE3WOS245Z75W6JrjdCl0KAnQhAxCEW24a5 FiuMjFpoWn01UDwHgXnXeuuY0Fb1uy/wUwj9bg04BRzNxALYIubJ0M1wQEHb+VtBlEwR 5IlcWm4uH9XMuFx+IZixJdXpb10dTUXFhID0X7vc9SLIPyHe2mOAD59/M8PZQTZ4xvpF ZeY4GE7cxk3yYCvqUiuAPhJMRmBzPK0QYFbOkP2UHEYsUAj1n0D5qeH4KcImJdg9DTyj Ludw== X-Gm-Message-State: AEkoous+HugigrIszAIIJL99epxzj0OsrHCTlCzbUSAwxcFMc5zHXzN4mLo+nTlr5fq/0w== X-Received: by 10.98.24.194 with SMTP id 185mr109891605pfy.52.1470176433296; Tue, 02 Aug 2016 15:20:33 -0700 (PDT) Received: from [100.127.66.204] ([69.53.245.200]) by smtp.gmail.com with ESMTPSA id q26sm7137636pfj.53.2016.08.02.15.20.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Aug 2016 15:20:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Paid Support for iMX6 Port From: Warner Losh In-Reply-To: Date: Tue, 2 Aug 2016 16:20:31 -0600 Cc: Michel Kohanim , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <241D6B3A-A780-4206-A4E8-18F3C91E3D99@bsdimp.com> References: To: Russell Haley X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:20:34 -0000 > On Aug 2, 2016, at 3:11 PM, Russell Haley = wrote: >=20 >>> 5. Support for booting from NAND flash or eMMC >> No, there is no support at this time. There is basic NAND support on >> one of the chips, but it has proven to be too deficient to be of much >> use (single bit parity, no use of hardware ECC and other major >> deficiencies). > Sorry, even if there was a driver for it, there is no Filesystem > designed to use eMMC or NAND directly. My understanding is typically > the flash controller provides a standardized SATA path for accessing > the NAND as if it's a disk (yet another developer make speak more to > this). GNU/Linux equivalent is yaffs or jfs2 (I think). nandfs will work on NAND directly, but needs lots of work. ufs works fine on eMMC since the eMMC parts do wear leveling in the part. It isn=E2=80=99t designed specifically for that, but = thousands of systems are running ufs on SD cards just fine and eMMC is the same thing (but with different low-level commands). Warner From owner-freebsd-arm@freebsd.org Tue Aug 2 22:21:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B1DDBAB83A for ; Tue, 2 Aug 2016 22:21:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 233201D79 for ; Tue, 2 Aug 2016 22:21:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id x130so133311970vkc.0 for ; Tue, 02 Aug 2016 15:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=g+SfSFvVUYdbosIEnqIFTWIM76yteAzTicJXPt5giG0=; b=vI8X8oN752bFamyHQZ/A9EctoYvQToi2dk2HRRPtjdtgDq/V6Pvf1ixLfifS98VuQV Wk43LZsJEMrATNwJw5q1bIO8ZYOyHVeL4hijbeFJjTHSh63s56qqzDJvx7QsyBaJLNDs qgI8FJTAKTZDQ72W0xQYZHh+jHFdrOoXJqPonn0xKtbje+p+ompkhaIEE75ROE8OOAFi R3kLJDSEwLkUBXghHBD76CFJrB71+EZSiiygeEtXwCEEKtCSvd7ufV9bRwZDeNInci/M zWey6Ffue+GBYM4F5sqot/jGnpBu8M5ICER7TcnGUrWJ6Nhlf5iw3IuFWIrl/YD5GJI1 j8OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=g+SfSFvVUYdbosIEnqIFTWIM76yteAzTicJXPt5giG0=; b=UtR3Oy6o7di6+P0yEdwkWvE2Xn5+Amdmhkgxi7kjJixZfDoMcjUS8k429u+7vCMTZ1 UuN6kx6sueUGH4WpVaPMggt0N3hZbDna+XhHZsejASttcQztOcj5e1NVka8EF1qOQ59K 9RXMSdhY6OAhFLbagGaBgRjvR6F1IRT3h3TGt3c3PthDbxBQNS7sEPghlomwu/kSEEES 9xjF2cSNgyE1bAhlN88sGAfrG35TaPWW6pSfxYRqPJpP4ZjuuMCsiyp91sucuha06nCU gZOi2BoA5m5blSP9ud2oBz9pN6YoecSyU/RIlJSS6G/3TulgCf+tRcPeqcg3+8nlhBNF 2ztg== X-Gm-Message-State: AEkoouuslAUxog99DKmAuTYQJD5oMFHAD8H/DZSe/IpSo2RA7037TBW9Q754SfI+unhb9cpNZWbLD0imYxZzeA== X-Received: by 10.31.201.71 with SMTP id z68mr2938903vkf.14.1470176468386; Tue, 02 Aug 2016 15:21:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.208.4 with HTTP; Tue, 2 Aug 2016 15:21:07 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Tue, 2 Aug 2016 15:21:07 -0700 Message-ID: Subject: Re: Paid Support for iMX6 Port To: Michel Kohanim Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:21:09 -0000 On Tue, Aug 2, 2016 at 2:41 PM, Michel Kohanim wrote: > Hi Russell, thank you. > > If we cannot boot from an onboard flash, this will be a deal breaker for = us. In our current hardware, you can take the SD Card out and the system st= ill boots up. Furthermore, you can put a completely blank SD Card and then = reinstall everything since the system is running. As I mentioned earlier, there are things that can be done, but none of which I think are very desirable. What initially excited me on FreeBSD/Arm was the possibility of running ZFS on an SSD and have multiple boot environments and data snapshots using a multi-core Arm system with 1+ GB of RAM. Super robust and super fast. I've had to abandon all of that in my prototype. Russ From owner-freebsd-arm@freebsd.org Tue Aug 2 22:25:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AECCBAB8CA for ; Tue, 2 Aug 2016 22:25:16 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7CE5114C for ; Tue, 2 Aug 2016 22:25:15 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-ua0-x22a.google.com with SMTP id 35so139860711uap.1 for ; Tue, 02 Aug 2016 15:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nfAlEP1+xB3ggyAFrkgr1jlCOX7umtjlFVhyHbrrsXw=; b=LQkE+l/qOWtKnNHeI8n3sLdgQ1Hy6/v+cxzloJF+hpMQk0FZr9KYyq1IV7YNhR4xAM Wq8wfipbiVdvBdPjGL2efwRCDsJ+XYSM3v7mV01o4CjspTjm2nYy6pv0dPny9nqx89U4 ZhcvjqCwqkU8pGx0rKFR/xCBi3c3Us2xJH82aoNT0yTB2NFS5VIg3f8XHD1G//ZuLJQc Y4XZ5lYrPi4QdQ0XHIJ4sA4zhLw+xuBymXEdW4koawIg06CEBRnKUtGYlNuVWVIBlSJm jb+2s8ULDTvdE+Qz1dTqDLLNTZMAcsw3qOJ4qgfzIaG8WsMIl9Tp6pML+OIZ90ksinib d6OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nfAlEP1+xB3ggyAFrkgr1jlCOX7umtjlFVhyHbrrsXw=; b=DliScWxgTC24SWiVhWAaUedy1awHa65g3jguJOmLi1b19Vv2ttPoA3qi7ZlAR2wowo rnpkJuKItxzngniswv/N7cOlVpuo2CEANkSPju+8dwu8cp2dMbqS+DFgvG7Hhq0Y8EtX HKH1SHggEAeMvNScsqUUO/jz7QkwVZDuM0G4rdEDTz6nfQP7n/dbYcy7vJLwzSRb5WWL MaNbsuZXrwus84hEe3h9/+SFwtGWrX6xAshRmi5X8h0QLfw1bKZtNYA9/IOnaMSb4Zer UyVkvu7uc4w1KD7kRTFAnjwUTGbh2YzDFCtzIIqd8VF5MCQgKRdf5CVfu5bIpujcnrfn WLJg== X-Gm-Message-State: AEkoouvnMzWzg1vFWKZNfNrKsatgGVKMCB8COYsajzib64m03lDccedY7dTKqKuX4pY+O6JoIoHSRlEALQRtPg== X-Received: by 10.176.65.102 with SMTP id j93mr31310894uad.30.1470176715024; Tue, 02 Aug 2016 15:25:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.208.4 with HTTP; Tue, 2 Aug 2016 15:25:14 -0700 (PDT) In-Reply-To: <241D6B3A-A780-4206-A4E8-18F3C91E3D99@bsdimp.com> References: <241D6B3A-A780-4206-A4E8-18F3C91E3D99@bsdimp.com> From: Russell Haley Date: Tue, 2 Aug 2016 15:25:14 -0700 Message-ID: Subject: Re: Paid Support for iMX6 Port To: Warner Losh Cc: Michel Kohanim , freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:25:16 -0000 On Tue, Aug 2, 2016 at 3:20 PM, Warner Losh wrote: > >> On Aug 2, 2016, at 3:11 PM, Russell Haley wrote: >> >>>> 5. Support for booting from NAND flash or eMMC >>> No, there is no support at this time. There is basic NAND support on >>> one of the chips, but it has proven to be too deficient to be of much >>> use (single bit parity, no use of hardware ECC and other major >>> deficiencies). >> Sorry, even if there was a driver for it, there is no Filesystem >> designed to use eMMC or NAND directly. My understanding is typically >> the flash controller provides a standardized SATA path for accessing >> the NAND as if it's a disk (yet another developer make speak more to >> this). GNU/Linux equivalent is yaffs or jfs2 (I think). > > nandfs will work on NAND directly, but needs lots of work. > > ufs works fine on eMMC since the eMMC parts do wear leveling > in the part. It isn=E2=80=99t designed specifically for that, but thousan= ds > of systems are running ufs on SD cards just fine and eMMC is > the same thing (but with different low-level commands). Sorry, absolutely correct. My mistake. My comment was in terms of boards that don't have eMMC and only raw NAND support. I think the beaglebone black (TI, not Freescale) has an eMMC chip that is available to users, but my (anecdotal) experience has been eMMC was not widely available on iMX6 boards without customization. Russ From owner-freebsd-arm@freebsd.org Tue Aug 2 22:30:12 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1C40BAB953 for ; Tue, 2 Aug 2016 22:30:12 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D507122E for ; Tue, 2 Aug 2016 22:30:12 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-ua0-x22a.google.com with SMTP id 35so139930454uap.1 for ; Tue, 02 Aug 2016 15:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=aLi8A3XuzPxhpGyDUUDKCXyrMQDvk77GE0DEDTbEmRE=; b=HeJyCELINRW3MJ806U2jdUmj5/EuVIIFdJ8Ao8rbIDuBc3QRCxmW6yJbeCiTWDg4Mf 0b8ESe1QUtnHtUQ8zr/8xQqmNMNj5NVLpe0o7qRlBuCJky/HGGxFU/xf8knnV6PHS1fD jI2pWvJj2PdnG+LhOYDlM8Wrqeb+kbiO1SkNzoilpjOqytaKfNKpz71CrBKNbm0f9sTH lpN95u2stPWb9y7n9X6J6S1qZLRsBwo21CJNW4chPf5gGUJnvADXa+Guie984JPEtld8 qQZohaMWFZqzxZRY6wcyVA772FpTtJsha2nqRLlsl5IQbVDFJpUh4x3KaUgW5K9ELuZ0 aXcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=aLi8A3XuzPxhpGyDUUDKCXyrMQDvk77GE0DEDTbEmRE=; b=FKHee42fJa9ohOnhMe4WHXRRIIlZGD4vuTsL0LqltQSPZzxRTDHMfb3xJ5o5f8Gshw ropcWU7kBQk0Xyuhv7v8yOJngJzsVfhC5WiW984MDwVLC/mUyFUOJ+hUAvgBEpv7F1cw o45M5Yk+PUTBOpLsS2RBtvrstAdKlA4rTsFApiaDSVztxy/dm4ynK6dCmgwsMmwI9EYC Ff3rUkZ/Dvqdp9rMA7XL/TzC1muN5YBsqLvA35VF87+SawgsO4sR0ThrnA1lGFaJOmm6 CC1Go2g+xpKUnAprfJml4UYX5c5MBg2Z4G3J0letyzAE/P97aRJ576UfXnZ43kUdq12Q iiUA== X-Gm-Message-State: AEkooutD7dPb2s+NErNBRQDK5Y5OeYiavltQvoPERtIeROW56yXbTBw86HaAxiSQFaUcl2fD4yiQdBW4htw7rg== X-Received: by 10.176.65.102 with SMTP id j93mr31321914uad.30.1470177011644; Tue, 02 Aug 2016 15:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.54.75 with HTTP; Tue, 2 Aug 2016 15:30:10 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Tue, 2 Aug 2016 15:30:10 -0700 Message-ID: Subject: Re: Paid Support for iMX6 Port To: freebsd-arm , Michel Kohanim Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:30:12 -0000 On Tue, Aug 2, 2016 at 3:16 PM, Russell Haley wrote: > Sorry, reply instead of reply all... > > > ---------- Forwarded message ---------- > From: Russell Haley > Date: Tue, Aug 2, 2016 at 3:16 PM > Subject: Re: Paid Support for iMX6 Port > To: Michel Kohanim > > > On Tue, Aug 2, 2016 at 2:39 PM, Michel Kohanim > wrote: >> Hi Russell, > Give me a few days, I just got back from vacation and kids don't sleep > well during summer hours so I have very limited time right now, but I > will get you what I have so far. Most of what you need is here: https://wiki.freebsd.org/FreeBSD/arm/crossbuild and even specifies the right kernel conf! Russ From owner-freebsd-arm@freebsd.org Tue Aug 2 23:18:05 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1C2FBAC962 for ; Tue, 2 Aug 2016 23:18:05 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 982B31E7D for ; Tue, 2 Aug 2016 23:18:05 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from [208.184.220.60] (helo=limiting-factor.dolby.net) by id.bluezbox.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1bUiUL-000DQ1-1T; Tue, 02 Aug 2016 15:48:41 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Utilite CM-FX6 FreeBSD with ubldr From: Oleksandr Tymoshenko In-Reply-To: Date: Tue, 2 Aug 2016 15:48:10 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A76F16A-9EA5-412E-B257-11BC209D6345@bluezbox.com> References: To: James Milne X-Mailer: Apple Mail (2.3124) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: > On Aug 2, 2016, at 9:30 AM, James Milne wrote: > > I'm having a challenge getting ubldr to see my mmc card (even after I > u-boot from it). > > Specifically: > > Use the u-boot-utilite u-boot image on the SD card, copy of ubldr after > cross build. (Not using crochet) > > fatload mmc 2 0x10800000 ubldr (not using .bin atm, although both fail) > bootelf 0x10800000 > > I've tried to setenv loaderdev= to about everything I can think of: > > mmc 0 > mmc 2 > disk0 > etc > No luck. > > Any suggestions? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 23:18:05 -0000 > On Aug 2, 2016, at 9:30 AM, James Milne wrote: >=20 > I'm having a challenge getting ubldr to see my mmc card (even after I > u-boot from it). >=20 > Specifically: >=20 > Use the u-boot-utilite u-boot image on the SD card, copy of ubldr = after > cross build. (Not using crochet) >=20 > fatload mmc 2 0x10800000 ubldr (not using .bin atm, although both = fail) > bootelf 0x10800000 >=20 > I've tried to setenv loaderdev=3D to about everything I can think of: >=20 > mmc 0 > mmc 2 > disk0 > etc > No luck. >=20 > Any suggestions? Try setting it to plain =E2=80=9Cdisk=E2=80=9D (no quotes, no unit = number) or unset it at all.=20= From owner-freebsd-arm@freebsd.org Tue Aug 2 23:35:10 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F98EBACD8F for ; Tue, 2 Aug 2016 23:35:10 +0000 (UTC) (envelope-from michel@universal-devices.com) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0112.outbound.protection.outlook.com [104.47.34.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 347F1181D for ; Tue, 2 Aug 2016 23:35:09 +0000 (UTC) (envelope-from michel@universal-devices.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=universaldevices.onmicrosoft.com; s=selector1-universaldevices-com02c; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=A9aevljvZfk+GzNqysRIrBPKTD6bul+iyhN93QakEAA=; b=MUqqBuUsNYVn/oKB/U5SvZslkuWs1nM5DrgjYKy+YIWz3Sazz1/HdxkrZFSHMhAGP5Y5rRzLlxhZ5A3HzsYfSGi9qQ3NLJN98/Pn5ukUfiiV/45whXnTkL1YuBpU9sCtMkneI/9v5RP7JmTT8axfSHiPqRFZyqSDr+eVWq1HKJ8= Received: from SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) by SN1PR0201MB1533.namprd02.prod.outlook.com (10.163.129.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 23:02:28 +0000 Received: from SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) by SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) with mapi id 15.01.0549.022; Tue, 2 Aug 2016 23:02:30 +0000 From: Michel Kohanim To: Russell Haley , freebsd-arm Subject: RE: Paid Support for iMX6 Port Thread-Topic: Paid Support for iMX6 Port Thread-Index: AdHs1b5KsSu8z2xcTpKjv7T6+miKcwAK8ckAAACUROAAAetxgAAAevRpAAEcQCA= Date: Tue, 2 Aug 2016 23:02:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michel@universal-devices.com; x-originating-ip: [75.83.36.12] x-ms-office365-filtering-correlation-id: 9419f027-eb0f-421a-19cb-08d3bb291491 x-microsoft-exchange-diagnostics: 1; SN1PR0201MB1533; 6:kABtw5dAF5H0zvH9wEHi4dHCBC/r67AIO2KLn7DmZrXDK0BhPDypYfZ7T4UVh3Wf8gs9+FRcClmdbKBF28N7RLLXGh1mnd09zwc4LBDYJlbz7sUHFDFmG3CVwsTDBV4lVqOR8VnGwUtjbcxbttQFA9u6RluZH8pUMAgr+3WGY/mZDFQdvMMaNQU7tSrL1E4mwU0bxID/hvg/36DfMbYM0s8NkwinVjwO07CCKq0t7UsUT51YCcwP80hBK9SmA86IR3LK4UJBp/OQtiD0EPWsdXtzlSO0dASxNC5U9gHYAdvcE31KMN7AN5r8QuQslZH9; 5:u8te8tjgHwpv3dPdKgljIwM/8BOmk644cxdjCAbjIJ5iSi4QrAJOUjeTIvg9jv0uGrNUT15MBauleaE9y+LvdLcfebafRMiYh6waTNdPD2IwNr+oeZkATwo6qZoF6JbOwoABm+cuV0jOJBSPsi5O2Q==; 24:upVwAFoh1UlptehkXnxZOSVzPUX+qPZgLTXV6/hyYZyP7yyiGQoHIqKJe7rG+fP6ZWZbcP6yUp34fpbZaA0ZQjhUGs32AEyIhbhhrcAgE+c=; 7:FA6spfzJmA/PFfQhfeOg8ZOcKwxIcHiN56BeDA+4EjkwlCibFBOZJzo+w05Rvs12TD8wwl9AhYwn5EsHc6OKc3s8piy7qVv7orV1wS1rLFPKN+Yd8tTkAT8A4uZ9lJsBAiV4JWjUptIgOkgQzTxF3d9Wvd5h6v+yLzev76suAu/Vh3eIHwz+RXuKbeg4LexknDpWpDSQJedCLEfs9uRlXJ2gmLmm0hNxVXjRZ+ZFuuYWrCN9L8LerdNP9qc8TfJd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0201MB1533; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046); SRVR:SN1PR0201MB1533; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0201MB1533; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(24454002)(199003)(189002)(71364002)(377454003)(76576001)(74316002)(66066001)(586003)(2950100001)(15975445007)(8676002)(81156014)(81166006)(33656002)(305945005)(2900100001)(86362001)(87936001)(16601075003)(106356001)(77096005)(101416001)(6116002)(76176999)(50986999)(54356999)(9686002)(92566002)(8936002)(3846002)(5002640100001)(107886002)(68736007)(93886004)(7846002)(2906002)(7736002)(5001770100001)(102836003)(105586002)(97736004)(99286002)(122556002)(7696003)(10400500002)(19580395003)(19580405001)(3660700001)(189998001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0201MB1533; H:SN1PR0201MB1534.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: universal-devices.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: universal-devices.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 23:02:29.9926 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d628f750-5cc1-4a42-9d4c-463ac737d54f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1533 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 23:35:10 -0000 SGkgUnVzc2VsbCwNCg0KVGhhbmtzIHNvIHZlcnkgbXVjaC4gSSBoYXZlIGFscmVhZHkgYmVlbiB0 aGVyZSBtYW55IHRpbWVzLiANCg0KV2l0aCBraW5kIHJlZ2FyZHMsDQoNCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KwqAgTWljaGVsIEtvaGFuaW0NCsKgIENFTw0KwqANCsKgIChwKSA4 MTguNjMxLjAzMzMNCsKgIChmKcKgIDgxOC40MzYuMDcwMg0KwqAgaHR0cDovL3d3dy51bml2ZXJz YWwtZGV2aWNlcy5jb20gDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJ1c3NlbGwgSGFsZXkgW21haWx0bzpydXNzLmhh bGV5QGdtYWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMiwgMjAxNiAzOjMwIFBNDQpU bzogZnJlZWJzZC1hcm0gPGZyZWVic2QtYXJtQGZyZWVic2Qub3JnPjsgTWljaGVsIEtvaGFuaW0g PG1pY2hlbEB1bml2ZXJzYWwtZGV2aWNlcy5jb20+DQpTdWJqZWN0OiBSZTogUGFpZCBTdXBwb3J0 IGZvciBpTVg2IFBvcnQNCg0KT24gVHVlLCBBdWcgMiwgMjAxNiBhdCAzOjE2IFBNLCBSdXNzZWxs IEhhbGV5IDxydXNzLmhhbGV5QGdtYWlsLmNvbT4gd3JvdGU6DQo+IFNvcnJ5LCByZXBseSBpbnN0 ZWFkIG9mIHJlcGx5IGFsbC4uLg0KPg0KPg0KPiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdl IC0tLS0tLS0tLS0NCj4gRnJvbTogUnVzc2VsbCBIYWxleSA8cnVzcy5oYWxleUBnbWFpbC5jb20+ DQo+IERhdGU6IFR1ZSwgQXVnIDIsIDIwMTYgYXQgMzoxNiBQTQ0KPiBTdWJqZWN0OiBSZTogUGFp ZCBTdXBwb3J0IGZvciBpTVg2IFBvcnQNCj4gVG86IE1pY2hlbCBLb2hhbmltIDxtaWNoZWxAdW5p dmVyc2FsLWRldmljZXMuY29tPg0KPg0KPg0KPiBPbiBUdWUsIEF1ZyAyLCAyMDE2IGF0IDI6Mzkg UE0sIE1pY2hlbCBLb2hhbmltIA0KPiA8bWljaGVsQHVuaXZlcnNhbC1kZXZpY2VzLmNvbT4gd3Jv dGU6DQo+PiBIaSBSdXNzZWxsLA0KDQo+IEdpdmUgbWUgYSBmZXcgZGF5cywgSSBqdXN0IGdvdCBi YWNrIGZyb20gdmFjYXRpb24gYW5kIGtpZHMgZG9uJ3Qgc2xlZXAgDQo+IHdlbGwgZHVyaW5nIHN1 bW1lciBob3VycyBzbyBJIGhhdmUgdmVyeSBsaW1pdGVkIHRpbWUgcmlnaHQgbm93LCBidXQgSSAN Cj4gd2lsbCBnZXQgeW91IHdoYXQgSSBoYXZlIHNvIGZhci4NCg0KTW9zdCBvZiB3aGF0IHlvdSBu ZWVkIGlzIGhlcmU6DQoNCmh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9GcmVlQlNEL2FybS9jcm9z c2J1aWxkDQoNCmFuZCBldmVuIHNwZWNpZmllcyB0aGUgcmlnaHQga2VybmVsIGNvbmYhDQoNClJ1 c3MNCg== From owner-freebsd-arm@freebsd.org Wed Aug 3 00:35:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40BF4BA5155 for ; Wed, 3 Aug 2016 00:35:01 +0000 (UTC) (envelope-from michel@universal-devices.com) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0112.outbound.protection.outlook.com [104.47.34.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E923719F1 for ; Wed, 3 Aug 2016 00:34:59 +0000 (UTC) (envelope-from michel@universal-devices.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=universaldevices.onmicrosoft.com; s=selector1-universaldevices-com02c; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fybwiTyugdViaj1lnJc7BMqFAJ8NiucqrGpOvHdCeKQ=; b=hbcW2OywnQOdstMJ8xrbR6zjAhrjFy3Jfrz4Af8M8TeEW6V7XGB+1qSSL8QOZv5plGCB12kyZoXGkRQ0b6bs+zOnVVYuGt1dBvZXk2N/olHNdQI6oBFr+59BCat/u6rv68b68oQRtoLkExo4oKtoSTyqSLEUKtM0fy6qPidBV08= Received: from SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) by SN1PR0201MB1535.namprd02.prod.outlook.com (10.163.129.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 23:02:50 +0000 Received: from SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) by SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) with mapi id 15.01.0549.022; Tue, 2 Aug 2016 23:02:51 +0000 From: Michel Kohanim To: Russell Haley , Warner Losh CC: freebsd-arm Subject: RE: Paid Support for iMX6 Port Thread-Topic: Paid Support for iMX6 Port Thread-Index: AdHs1b5KsSu8z2xcTpKjv7T6+miKcwAK8ckAAAA2ZIAAAm1hgAAAKisAAAFOtJA= Date: Tue, 2 Aug 2016 23:02:51 +0000 Message-ID: References: <241D6B3A-A780-4206-A4E8-18F3C91E3D99@bsdimp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michel@universal-devices.com; x-originating-ip: [75.83.36.12] x-ms-office365-filtering-correlation-id: 08d0f66f-33f0-415e-a0ca-08d3bb292181 x-microsoft-exchange-diagnostics: 1; SN1PR0201MB1535; 6:I34KhaYKEBs9rg0KIcHEt1pAGhNDqlvtdnGBpkgqNOqzkWIfBa2BX86Usr2UWYRDRa4acO7hEZuPBB+VJUkA1NWCWeEvviGpr2IDCAUGuaBIXaBBwylKlgP0Gj/UaDQeEsiw4OrIqYv3shY9xgmz/6+ybAMG/q7fBP5K/yZ7LGiFA5TbrAiBA80AaZm4jxcCqNt2UDIJ7zYd14iikdC8WDl5wZE3hNEDJuz+QGMkZsHXrkmJPJRAe6nIXXuAb858HiTf7rN+WyRFA2Fr5O9U2O0C2ifak0DG/TIxpHdlRXmoTY8LEIfvVPq1bJFglHMR; 5:THLYFjVNNYDyoh6mAuR9F81nmztiz2+EAIcnFWmSGgc47x2eCT4Uu/1fNYdCplLyPmJLDf94bQn4M75Wq6gzixHdEZLCothQKqd1Pdf5Zy7wm7InRERB+jo1DAHtbw8FehIaAVVkDhMUFShXDJo05Q==; 24:VG1VSRQFwfM9i11Xc3q6hADCavK0QHiiy5TRGT3V3FOKKnYODU+X35m9Zt2ibToTfy5MoofCMkl5+RvxdzL9y4PRbCWs4bb0rhB3XoJPwIg=; 7:qDGOgFCka0mT8GeCL3KsorIeDBJo2IYtESeJXv6n7O7lU6+2bHcCCNFU3e6xNLe3SKdsz+xazCYJRMPI+QHHw+XnDiFmvAZssgfRy/Y4ld14zMR0wgJY24COuxtXA+auDzZjThZNB33E+602+IN5bACvy6N5yY29fn4F8GMKrCq7LedqHOVJxvT5zJt2Ng9ZCJAbb1O/1Wiw9Jmu7hrMHAz41XoBh69giZqc3DAqXWb6dAzkVZZHQlxrgeEmMgAk x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0201MB1535; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046); SRVR:SN1PR0201MB1535; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0201MB1535; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(71364002)(24454002)(13464003)(199003)(189002)(33656002)(122556002)(87936001)(106356001)(19580405001)(19580395003)(93886004)(81166006)(54356999)(50986999)(81156014)(92566002)(3660700001)(10400500002)(102836003)(3280700002)(3846002)(86362001)(76176999)(68736007)(586003)(6116002)(8936002)(2950100001)(2900100001)(99286002)(8676002)(16601075003)(5002640100001)(4326007)(77096005)(15975445007)(97736004)(7846002)(189998001)(66066001)(76576001)(2906002)(5001770100001)(101416001)(74316002)(7736002)(7696003)(9686002)(105586002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0201MB1535; H:SN1PR0201MB1534.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: universal-devices.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: universal-devices.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 23:02:51.7776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d628f750-5cc1-4a42-9d4c-463ac737d54f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1535 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 00:35:01 -0000 ZU1NQyBpcyBhbHNvIE9LLiANCg0KV2l0aCBraW5kIHJlZ2FyZHMsDQoNCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KwqAgTWljaGVsIEtvaGFuaW0NCsKgIENFTw0KwqANCsKgIChwKSA4 MTguNjMxLjAzMzMNCsKgIChmKcKgIDgxOC40MzYuMDcwMg0KwqAgaHR0cDovL3d3dy51bml2ZXJz YWwtZGV2aWNlcy5jb20gDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJ1c3NlbGwgSGFsZXkgW21haWx0bzpydXNzLmhh bGV5QGdtYWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMiwgMjAxNiAzOjI1IFBNDQpU bzogV2FybmVyIExvc2ggPHdsb3NoQGJzZGltcC5jb20+DQpDYzogTWljaGVsIEtvaGFuaW0gPG1p Y2hlbEB1bml2ZXJzYWwtZGV2aWNlcy5jb20+OyBmcmVlYnNkLWFybSA8ZnJlZWJzZC1hcm1AZnJl ZWJzZC5vcmc+DQpTdWJqZWN0OiBSZTogUGFpZCBTdXBwb3J0IGZvciBpTVg2IFBvcnQNCg0KT24g VHVlLCBBdWcgMiwgMjAxNiBhdCAzOjIwIFBNLCBXYXJuZXIgTG9zaCA8d2xvc2hAYnNkaW1wLmNv bT4gd3JvdGU6DQo+DQo+PiBPbiBBdWcgMiwgMjAxNiwgYXQgMzoxMSBQTSwgUnVzc2VsbCBIYWxl eSA8cnVzcy5oYWxleUBnbWFpbC5jb20+IHdyb3RlOg0KPj4NCj4+Pj4gNS4gICAgICAgU3VwcG9y dCBmb3IgYm9vdGluZyBmcm9tIE5BTkQgZmxhc2ggb3IgZU1NQw0KPj4+IE5vLCB0aGVyZSBpcyBu byBzdXBwb3J0IGF0IHRoaXMgdGltZS4gVGhlcmUgaXMgYmFzaWMgTkFORCBzdXBwb3J0IG9uIA0K Pj4+IG9uZSBvZiB0aGUgY2hpcHMsIGJ1dCBpdCBoYXMgcHJvdmVuIHRvIGJlIHRvbyBkZWZpY2ll bnQgdG8gYmUgb2YgDQo+Pj4gbXVjaCB1c2UgKHNpbmdsZSBiaXQgcGFyaXR5LCBubyB1c2Ugb2Yg aGFyZHdhcmUgRUNDIGFuZCBvdGhlciBtYWpvciANCj4+PiBkZWZpY2llbmNpZXMpLg0KPj4gU29y cnksIGV2ZW4gaWYgdGhlcmUgd2FzIGEgZHJpdmVyIGZvciBpdCwgdGhlcmUgaXMgbm8gRmlsZXN5 c3RlbSANCj4+IGRlc2lnbmVkIHRvIHVzZSBlTU1DIG9yIE5BTkQgZGlyZWN0bHkuIE15IHVuZGVy c3RhbmRpbmcgaXMgdHlwaWNhbGx5IA0KPj4gdGhlIGZsYXNoIGNvbnRyb2xsZXIgcHJvdmlkZXMg YSBzdGFuZGFyZGl6ZWQgU0FUQSBwYXRoIGZvciBhY2Nlc3NpbmcgDQo+PiB0aGUgTkFORCBhcyBp ZiBpdCdzIGEgZGlzayAoeWV0IGFub3RoZXIgZGV2ZWxvcGVyIG1ha2Ugc3BlYWsgbW9yZSB0byAN Cj4+IHRoaXMpLiBHTlUvTGludXggZXF1aXZhbGVudCBpcyB5YWZmcyBvciBqZnMyIChJIHRoaW5r KS4NCj4NCj4gbmFuZGZzIHdpbGwgd29yayBvbiBOQU5EIGRpcmVjdGx5LCBidXQgbmVlZHMgbG90 cyBvZiB3b3JrLg0KPg0KPiB1ZnMgd29ya3MgZmluZSBvbiBlTU1DIHNpbmNlIHRoZSBlTU1DIHBh cnRzIGRvIHdlYXIgbGV2ZWxpbmcgaW4gdGhlIA0KPiBwYXJ0LiBJdCBpc27igJl0IGRlc2lnbmVk IHNwZWNpZmljYWxseSBmb3IgdGhhdCwgYnV0IHRob3VzYW5kcyBvZiANCj4gc3lzdGVtcyBhcmUg cnVubmluZyB1ZnMgb24gU0QgY2FyZHMganVzdCBmaW5lIGFuZCBlTU1DIGlzIHRoZSBzYW1lIA0K PiB0aGluZyAoYnV0IHdpdGggZGlmZmVyZW50IGxvdy1sZXZlbCBjb21tYW5kcykuDQoNClNvcnJ5 LCBhYnNvbHV0ZWx5IGNvcnJlY3QuIE15IG1pc3Rha2UuIE15IGNvbW1lbnQgd2FzIGluIHRlcm1z IG9mIGJvYXJkcyB0aGF0IGRvbid0IGhhdmUgZU1NQyBhbmQgb25seSByYXcgTkFORCBzdXBwb3J0 LiBJIHRoaW5rIHRoZSBiZWFnbGVib25lIGJsYWNrIChUSSwgbm90IEZyZWVzY2FsZSkgaGFzIGFu IGVNTUMgY2hpcCB0aGF0IGlzIGF2YWlsYWJsZSB0byB1c2VycywgYnV0IG15IChhbmVjZG90YWwp IGV4cGVyaWVuY2UgaGFzIGJlZW4gZU1NQyB3YXMgbm90IHdpZGVseSBhdmFpbGFibGUgb24gaU1Y NiBib2FyZHMgd2l0aG91dCBjdXN0b21pemF0aW9uLg0KDQpSdXNzDQo= From owner-freebsd-arm@freebsd.org Wed Aug 3 01:21:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35AB8BA5F97 for ; Wed, 3 Aug 2016 01:21:58 +0000 (UTC) (envelope-from milne.james@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F32DC1EFF for ; Wed, 3 Aug 2016 01:21:57 +0000 (UTC) (envelope-from milne.james@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id f6so285592209ith.1 for ; Tue, 02 Aug 2016 18:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=deTkAQE6AS7kw0ufUJi440p1EsT5dBQBOy+PFEDa+VA=; b=FBFQl9RU64qGjr89OG0rKAM0xgvo19ZEYZyLqAc8PIg/4G5JrI5voUTSmTkGj0JoXL XGnnUYJAMUfXXk/EN4GokGGrVGfrZjmuwnhEvK/Q4Q1obx5FeTi4jU7yDafz7PgnZYWT ohPIJ1c8hDevNYPNeK48fCXXEil5hLx5jWLZrmyUrR6zx9fAtv3qYtfFq/tIUv96OZlb ISn8adZKmbTNXZmwckIMeOTrN/2MHjqVrn68vqcWaqC2QVstFK4axLUwc1ZTsXzgrN8J ACwMs8A9wTZizK0InmxcbSnPHKaynJQQ/XsDfN8YLx0QhVBYfg1zLrk4ccCKu+OlJmzh 6EGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=deTkAQE6AS7kw0ufUJi440p1EsT5dBQBOy+PFEDa+VA=; b=EBZKotE+ZtTN3WpUpiQy8s8PbHHbswplFmTP3Zb5DBqDFK6rOcR3uqlBVn0khjKsjG WuiD+jBkPycHsuj3NJUEzHs6SA75NxhZpH5TOsV0wYtqzDLgN7uc1XozmeWWkLQDLTzV g84TVuzGLwAoAlDOq6JsC1URszHYV/9d+UMLRAEbQYbQginChcpkMsypUE9Mt9wBYsnG sxaoPMwLUwAdZutqGt06auIveLQGi3cQFoL12y25q1FzdBhPswdClT/b5Xeb743UhQva OssVH0IRn8OEXUTeczsDYgry3WyKr0vNtJXqXJX6nsq3Uh4YpOwuJpOv0rh3jUYvsNPE 3aKA== X-Gm-Message-State: AEkoous3I/phwU+ZfocDmxwtciBrvlnAnI9eNSWW36yTXKyU9GjpHKHF7DXKRaPTDARumqe6RxvSpR4rKtuxUw== X-Received: by 10.36.116.131 with SMTP id o125mr66025625itc.7.1470187317290; Tue, 02 Aug 2016 18:21:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.17 with HTTP; Tue, 2 Aug 2016 18:21:56 -0700 (PDT) In-Reply-To: <6A76F16A-9EA5-412E-B257-11BC209D6345@bluezbox.com> References: <6A76F16A-9EA5-412E-B257-11BC209D6345@bluezbox.com> From: James Milne Date: Tue, 2 Aug 2016 20:21:56 -0500 Message-ID: Subject: Re: Utilite CM-FX6 FreeBSD with ubldr To: Oleksandr Tymoshenko Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 01:21:58 -0000 Did both, no luck. Did get to a loader prompt but still doesn't see the car= d On Tuesday, August 2, 2016, Oleksandr Tymoshenko wrote= : > > > On Aug 2, 2016, at 9:30 AM, James Milne > wrote: > > > > I'm having a challenge getting ubldr to see my mmc card (even after I > > u-boot from it). > > > > Specifically: > > > > Use the u-boot-utilite u-boot image on the SD card, copy of ubldr after > > cross build. (Not using crochet) > > > > fatload mmc 2 0x10800000 ubldr (not using .bin atm, although both fail) > > bootelf 0x10800000 > > > > I've tried to setenv loaderdev=3D to about everything I can think of: > > > > mmc 0 > > mmc 2 > > disk0 > > etc > > No luck. > > > > Any suggestions? > > Try setting it to plain =E2=80=9Cdisk=E2=80=9D (no quotes, no unit number= ) or unset it at > all. From owner-freebsd-arm@freebsd.org Wed Aug 3 03:32:29 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2045BACCD8 for ; Wed, 3 Aug 2016 03:32:29 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 61A3C118E for ; Wed, 3 Aug 2016 03:32:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u733Sd28039355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Aug 2016 05:28:45 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u733SVd9010981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2016 05:28:32 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u733SVFM021402; Wed, 3 Aug 2016 05:28:31 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u733SUGP021401; Wed, 3 Aug 2016 05:28:30 +0200 (CEST) (envelope-from ticso) Date: Wed, 3 Aug 2016 05:28:30 +0200 From: Bernd Walter To: FreeBSD-arm@freebsd.org Cc: Bernd Walter Subject: SPI on Raspberry B+ Message-ID: <20160803032830.GB18406@cicely7.cicely.de> Reply-To: ticso@cicely.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 03:32:29 -0000 I'm currently writing a kernel driver for APA102 LEDs on 11-BETA3. With some help of older threads on this list I've managed to get my driver attached and sending data. However, what I didn't manged yet is setting the SPI parameters. The SPI mode seems to match fine. The byte order is unfortunately wrong. I need MSB first and the driver is sending LSB first. Of course I could rotate all the bits, but would like to avoid it for performance reasons. The clock is only 500kHz according to scope. I've heared that there is no device specific speed support, but since I'm not using any other SPI device setting the global speed would be fine. I'm calling SPIBUS_TRANSFER with multiple bytes. There is a gap of 2 microseconds between the bytes. Don't know if it just skipping a full clock cycle and the gap will be shorter with a higher clockrate, or if the driver really needs 2 full microseconds between each bytes. I somehow believe (and hope) it is just a full cycle in the controller. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Aug 3 03:40:56 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66B19BACE96 for ; Wed, 3 Aug 2016 03:40:56 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh505-vm5.bullet.mail.kks.yahoo.co.jp (nh505-vm5.bullet.mail.kks.yahoo.co.jp [183.79.57.107]) by mx1.freebsd.org (Postfix) with SMTP id C66961448 for ; Wed, 3 Aug 2016 03:40:55 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.140] by nh505.bullet.mail.kks.yahoo.co.jp with NNFMP; 03 Aug 2016 03:38:03 -0000 Received: from [183.79.100.132] by t503.bullet.mail.kks.yahoo.co.jp with NNFMP; 03 Aug 2016 03:38:03 -0000 Received: from [127.0.0.1] by omp501.mail.kks.yahoo.co.jp with NNFMP; 03 Aug 2016 03:38:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 142121.14757.bm@omp501.mail.kks.yahoo.co.jp Received: (qmail 24418 invoked by uid 60001); 3 Aug 2016 03:38:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1470195482; bh=VOLF9ESo9mEafsESWcXGRzBY9Hf87HyyFZ4LDZ8v67w=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=oDTZnyfQKglJT013Y3ImLQYBSPXBaV2u9n3jfeSsh2pGbnJSFMPS6YqXZbvvxswdxUe6I6f1GUbEjHvE1eGXvKmlbsuBRFkTgcADiSUvpMPdB2cjXaWGlu/IDqEqexr0VaaWhzt33c0ZxMNp3UfKc0NW278svbiMpP4lbRzM284= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=TCOs7vhuQXAop2Q2HLGL+wMHiwzkFj9Lc5OHFoLDMAPxV2TZ/VJr0txgsoMzvVFuYT9J3iuk8+a1+qwupzCHFTEf5VNFxrSiMRzus6koiKNUEq/NjuUSsDE87wNfOZZntkPu1C/pNN/irvR9+10waehwcTLqxk53saOwqk/crfE=; Message-ID: <804749.19762.qm@web101706.mail.ssk.yahoo.co.jp> X-YMail-OSG: Ofab9NcVM1ltq4N.1lbJMUTlfOAFYL6ixfytGaoUvRulyylO9FaT6Accd7XQc5vNvi7JwGBp2xzCaWNJqnUR..eiyfBwYGMwkEmiGfQvBg7Ufi3mpZsdSyxBJP4WM.C5WfMTUdKf7vyieoCILsvk97BR4GixABME8mkH_KN_N_iXkg9Hyeq4dpmb3_lTyqkdXZrzUTQEK5.9cNdHk7uAeCxT0wF2wkl81DHQmxpeIGgXCZG.fPhJT1lfK.B2VigcuBiJ4jRb57g4eTvVWWjj1vPaH9BGFXrOjIXZ.BkiMXnEqe3_y3qdunlPqJty.m.suASGSLLU0dF_zO9H4WBMbOZ7YV0YBPODpWdiQldA.eVGoU5xGZkf.c22KsqpnzF46Fz1coaSNb58BV989jhouRdSqLXjqxI0gQcmmIOWoFeetKis.QwcAdEGnSdDozjS.nJjEWM7mWawzzeO4QBST6GB0sSPhuylLRGERQn4kCa_vJn7hJcsYUcnkQQnrSNcAiXHlzzvtAWQyDkf5oN36FJeWvJ5KDtiEPeZS0dCQiRS8b2xNQsDp2aTiw-- Received: from [110.134.196.53] by web101706.mail.ssk.yahoo.co.jp via HTTP; Wed, 03 Aug 2016 12:38:02 JST X-Mailer: YahooMailWebService/0.8.111_69 X-YMail-JAS: BHE.wtYVM1nTl6oNy5ws1XYn5a3baRr_EKInFnby6vEq6EbwL5PYWlrViD8VDzdj_YnJa3t7jPOtQrMiKiRMUs9y7989EcJZB9ZHgoiPS4LDgGbgXBVwIaPkBlpgbYTcAWko Date: Wed, 3 Aug 2016 12:38:02 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: objdump patch for sbin/init Segmentation fault To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 03:40:56 -0000 Hi=0A=0AI have problem sbin/init=C2=A0disassemble by objdump command. I mak= e path this problem.=C2=A0=0A=0Amicroserver % `find tmp/arm.arm/ -name objd= ump -type f | head -1` -d Planex_MZK-=0AW04G_rootfs_clean/sbin/init=0A=0APl= anex_MZK-W04G_rootfs_clean/sbin/init: =C2=A0 =C2=A0 file format elf32-littl= earm=0A=0ADisassembly of section .init:=0A=0A00008140 <.init>:=0ASegmentati= on fault (core dumped)=0Amicroserver % gdb `find tmp/arm.arm/ -name objdump= -type f | head -1` objdump.co=0Are=0AGNU gdb 6.1.1 [FreeBSD]=0ACopyright 2= 004 Free Software Foundation, Inc.=0AGDB is free software, covered by the G= NU General Public License, and you are=0Awelcome to change it and/or distri= bute copies of it under certain conditions.=0AType "show copying" to see th= e conditions.=0AThere is absolutely no warranty for GDB.=C2=A0 Type "show w= arranty" for details.=0AThis GDB was configured as "amd64-marcel-freebsd"..= .=0ACore was generated by `objdump'.=0AProgram terminated with signal 11, S= egmentation fault.=0A#0=C2=A0 0x00000000004311a6 in print_insn (pc=3D33088,= info=3D0x7fffffffe800, little=3D1)=0A=C2=A0 =C2=A0 at /storage/home/hiroki= /freebsd/gnu/usr.bin/binutils/libopcodes/../../../../=0Acontrib/binutils/op= codes/arm-dis.c:3990=0A3990=C2=A0 =C2=A0 =C2=A0 if (info->symtab !=3D NULL= =0A(gdb) where=0A#0=C2=A0 0x00000000004311a6 in print_insn (pc=3D33088, inf= o=3D0x7fffffffe800, little=3D1)=0A=C2=A0 =C2=A0 at /storage/home/hiroki/fre= ebsd/gnu/usr.bin/binutils/libopcodes/../../../../=0Acontrib/binutils/opcode= s/arm-dis.c:3990=0A#1=C2=A0 0x000000000040314e in disassemble_section (abfd= =3D0x800c09140,=C2=A0=0A=C2=A0 =C2=A0 section=3D0x800c32140, info=3D0x7ffff= fffe800)=0A=C2=A0 =C2=A0 at /storage/home/hiroki/freebsd/gnu/usr.bin/binuti= ls/objdump/../../../../con=0Atrib/binutils/binutils/objdump.c:1470=0A#2=C2= =A0 0x0000000000436d1c in uM=E7=8A=AFIH=E6=B3=A2Q0=E8=9D=9F ()=0A#3=C2=A0 0= x0000000000401bf6 in dump_bfd (abfd=3D0x800c09140)=0A=C2=A0 =C2=A0 at /stor= age/home/hiroki/freebsd/gnu/usr.bin/binutils/objdump/../../../../con=0Atrib= /binutils/binutils/objdump.c:2012=0A#4=C2=A0 0x0000000000400de3 in display_= bfd (abfd=3D)=0A=C2=A0 =C2=A0 at /storage/home/hiroki/= freebsd/gnu/usr.bin/binutils/objdump/../../../../con=0Atrib/binutils/binuti= ls/objdump.c:2945=0A#5=C2=A0 0x0000000000400d2b in display_file (filename= =3D,=C2=A0=0A=C2=A0 =C2=A0 target=3D)=0A=C2=A0 =C2=A0 at /storage/home/hiroki/freebsd/gnu/usr.bin/binutils/o= bjdump/../../../../con=0Atrib/binutils/binutils/objdump.c:3026=0A#6=C2=A0 0= x0000000000400adb in main (argc=3D3, argv=3D0x7fffffffea08)=0A=C2=A0 =C2=A0= at /storage/home/hiroki/freebsd/gnu/usr.bin/binutils/objdump/../../../../c= on=0Atrib/binutils/binutils/objdump.c:3265=0ACurrent language:=C2=A0 auto; = currently minimal=0A(gdb) p info->symtab=0A$1 =3D (asymbol **) 0x800c30058= =0A(gdb) p *info->symtab=0A$2 =3D (asymbol *) 0x0=0A(gdb)=C2=A0=0A=0A=0Adif= f --git a/contrib/binutils/opcodes/arm-dis.c b/contrib/binutils/opcodes/arm= -dis.c=0Aindex b6ce5c6..6fb6930 100644=0A--- a/contrib/binutils/opcodes/arm= -dis.c=0A+++ b/contrib/binutils/opcodes/arm-dis.c=0A@@ -3988,6 +3988,7 @@ p= rint_insn (bfd_vma pc, struct disassemble_info *info, bfd_boolean li=0Attle= )=0A=C2=A0=C2=A0 /* First check the full symtab for a mapping symbol, even = if there=0A=C2=A0 =C2=A0 =C2=A0 are no usable non-mapping symbols for this = address.=C2=A0 */=0A=C2=A0=C2=A0 if (info->symtab !=3D NULL=0A+=C2=A0 =C2= =A0 =C2=A0 && *info->symtab !=3D NULL=0A=C2=A0=C2=A0 =C2=A0 =C2=A0 && bfd_a= symbol_flavour (*info->symtab) =3D=3D bfd_target_elf_flavour)=0A=C2=A0=C2= =A0 =C2=A0 {=0A=C2=A0=C2=A0 =C2=A0 =C2=A0 bfd_vma addr;=0A=0A=0ARegards=0A= =0AHiroki Mori From owner-freebsd-arm@freebsd.org Wed Aug 3 03:49:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60A1BBAB134 for ; Wed, 3 Aug 2016 03:49:13 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D97B5190B for ; Wed, 3 Aug 2016 03:49:11 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u733mvwP039474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Aug 2016 05:48:58 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u733mqG0011218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2016 05:48:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u733mqJR021444; Wed, 3 Aug 2016 05:48:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u733mpOM021443; Wed, 3 Aug 2016 05:48:51 +0200 (CEST) (envelope-from ticso) Date: Wed, 3 Aug 2016 05:48:51 +0200 From: Bernd Walter To: FreeBSD-arm@freebsd.org Cc: Bernd Walter Subject: Re: SPI on Raspberry B+ Message-ID: <20160803034851.GC18406@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20160803032830.GB18406@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160803032830.GB18406@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 03:49:13 -0000 On Wed, Aug 03, 2016 at 05:28:30AM +0200, Bernd Walter wrote: > I'm currently writing a kernel driver for APA102 LEDs on 11-BETA3. > With some help of older threads on this list I've managed to > get my driver attached and sending data. > However, what I didn't manged yet is setting the SPI parameters. > > The SPI mode seems to match fine. > > The byte order is unfortunately wrong. > I need MSB first and the driver is sending LSB first. > Of course I could rotate all the bits, but would like to avoid it > for performance reasons. > > The clock is only 500kHz according to scope. > I've heared that there is no device specific speed support, but since I'm > not using any other SPI device setting the global speed would be fine. I've found out about sysctl dev.spi.0.clock. That works fine. > I'm calling SPIBUS_TRANSFER with multiple bytes. > There is a gap of 2 microseconds between the bytes. > Don't know if it just skipping a full clock cycle and the gap will > be shorter with a higher clockrate, or if the driver really needs > 2 full microseconds between each bytes. > I somehow believe (and hope) it is just a full cycle in the controller. It also remains at one clock cycle gap, so with higher speed the gap will be shorter as well. Unfortunately there is no byteorder sysctl. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Aug 3 15:27:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC98CBAEB6A for ; Wed, 3 Aug 2016 15:27:31 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84BBF11AA for ; Wed, 3 Aug 2016 15:27:31 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bUy4o-0007tE-LB; Wed, 03 Aug 2016 17:27:23 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm , "Russell Haley" Subject: Re: Fwd: Paid Support for iMX6 Port References: Date: Wed, 03 Aug 2016 17:27:21 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: f4db13d1ab50da585241c80c5e12767b X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 15:27:31 -0000 On Wed, 03 Aug 2016 00:16:55 +0200, Russell Haley wrote: > Sorry, reply instead of reply all... > > > ---------- Forwarded message ---------- > From: Russell Haley > Date: Tue, Aug 2, 2016 at 3:16 PM > Subject: Re: Paid Support for iMX6 Port > To: Michel Kohanim > > > On Tue, Aug 2, 2016 at 2:39 PM, Michel Kohanim > wrote: >> Hi Russell, >> >> Thanks so very much for getting in touch. Hopefully the experienced >> iMX6 developer will chime in. Again, I am willing to pay for services >> and then share the results with the community. >> >> 1. Would love to read your notes on Hummingboard. I am using Wandboard >> and Wandboard Dual for testing purposes and have been able to get >> FreeBSD binary image (from the website) loaded and functioning albeit >> it's way too slow even for rudimentary tasks such as vi (on the Solo). >> I suspect 512MB is not sufficient. Ultimately, I would like to be able >> to make a smaller image ourselves but have been having a hell of a time >> with Crochet > > Give me a few days, I just got back from vacation and kids don't sleep > well during summer hours so I have very limited time right now, but I > will get you what I have so far. > > > >> 6. NAND flash/eMMC ... our main goal is that - at the minimum - the >> kernel should be on a flash chip of some sort so that boot up does NOT >> require an SD Card. Are you aware of any flash chip that can be used by >> uboot to boot FreeBSD? > It's possible to run u-boot from NAND and then run ubldr/kernel from a > different source. It may even be possible to manually load ubldr from > NAND (or even manually load the kernel from NAND in u-boot) but you > would need to find an alternative for the kernel and rootfs, > especially if you want to update your kernel ever. Not what I would > call desirable, but I have *heard* of production systems running like > this. My Sheevaplug loads the kernel from NAND which mounts the rootfs from USB-stick. And does this for a couple of years already. I used to have a rootfs on nandfs(5) also, but nandfs is not stable enough. # nandtool erase dev=/dev/gnand0s.fbsd-boot # dd if=/tmp/kernel.bin of=/dev/gnand0s.fbsd-boot bs=2k conv=sync Cheers, Ronald. >> 8. SATA ... may be an interesting option instead of using flash. The >> main issue is that our products are price sensitive and using SATA adds >> at least $10.00 to the BOM. As such - or unless I am mistaken on the >> price - SATA is not a requirement for me > Hmmm... at work we use an apacer solder on 2 GB chip that comes in > considerably under $10 I believe. Not sure if a little 2GB chip is > still available. http://us.apacer.com/products/SDC4-18-pin. > Regardless, there is no support at this time. > > > Russ > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Aug 3 16:28:00 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 131B0BAE0A8 for ; Wed, 3 Aug 2016 16:28:00 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BB03127A for ; Wed, 3 Aug 2016 16:27:58 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u73GRakf049567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Aug 2016 18:27:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u73GRTRK020409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2016 18:27:30 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u73GRTXa022770; Wed, 3 Aug 2016 18:27:29 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u73GRSjb022769; Wed, 3 Aug 2016 18:27:28 +0200 (CEST) (envelope-from ticso) Date: Wed, 3 Aug 2016 18:27:28 +0200 From: Bernd Walter To: FreeBSD-arm@freebsd.org Cc: Bernd Walter Subject: Re: SPI on Raspberry B+ Message-ID: <20160803162728.GE18406@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20160803032830.GB18406@cicely7.cicely.de> <20160803034851.GC18406@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160803034851.GC18406@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 16:28:00 -0000 On Wed, Aug 03, 2016 at 05:48:51AM +0200, Bernd Walter wrote: > On Wed, Aug 03, 2016 at 05:28:30AM +0200, Bernd Walter wrote: > > I'm currently writing a kernel driver for APA102 LEDs on 11-BETA3. > > With some help of older threads on this list I've managed to > > get my driver attached and sending data. > > However, what I didn't manged yet is setting the SPI parameters. > > > > The SPI mode seems to match fine. > > > > The byte order is unfortunately wrong. > > I need MSB first and the driver is sending LSB first. > > Of course I could rotate all the bits, but would like to avoid it > > for performance reasons. > > > > The clock is only 500kHz according to scope. > > I've heared that there is no device specific speed support, but since I'm > > not using any other SPI device setting the global speed would be fine. > > I've found out about sysctl dev.spi.0.clock. > That works fine. > > > I'm calling SPIBUS_TRANSFER with multiple bytes. > > There is a gap of 2 microseconds between the bytes. > > Don't know if it just skipping a full clock cycle and the gap will > > be shorter with a higher clockrate, or if the driver really needs > > 2 full microseconds between each bytes. > > I somehow believe (and hope) it is just a full cycle in the controller. > > It also remains at one clock cycle gap, so with higher speed the > gap will be shorter as well. > > Unfortunately there is no byteorder sysctl. Oh - stupid me. I've left some test pattern in my testcode. The drivers byteorder is in fact MSB first. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Aug 3 20:52:45 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9AA18BAE105 for ; Wed, 3 Aug 2016 20:52:45 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (Client CN "rcdn-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 630A81D71 for ; Wed, 3 Aug 2016 20:52:45 +0000 (UTC) (envelope-from bmcgover@cisco.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1280; q=dns/txt; s=iport; t=1470257565; x=1471467165; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=B9pGBDdEH9Rtrm2R5eiyPp7NmpeKpcZwSvvOnbY5J6g=; b=RR/5FTs3yGy4YTztizBB7VBit9/xPy92gFaBsVj93mV6m5o6ae0+nADc vyW3evyHnIJwfkOZrRrgukG/L2TicJrRtQ7XUH7KwuGT7Dy+hyhW0h4VT 8HJ4Bh2aQIa+1ftXTohsgasmQg58rqfaSTd+auA0QxCHS64+EEZ+eu35v 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AgC1WKJX/4oNJK1dg0WBWbkqgX2Hb?= =?us-ascii?q?DgUAQEBAQEBAV0cC4RlOlEBPkInBBuIKZ9tn2IBAQEHAQEBAQEihiqOaAWOF4s?= =?us-ascii?q?dAY53j0eQJgEeNoN6iEl/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,467,1464652800"; d="scan'208";a="136610358" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Aug 2016 20:52:43 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u73KqhjP027688 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Aug 2016 20:52:43 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 3 Aug 2016 16:52:43 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Wed, 3 Aug 2016 16:52:43 -0400 From: "Brian McGovern (bmcgover)" To: "freebsd-arm@freebsd.org" Subject: Beaglebone Black ADC with 11-BETAs? Thread-Topic: Beaglebone Black ADC with 11-BETAs? Thread-Index: AQHR7cj6ivaCCqu7Z02Zdd8OVreSBw== Date: Wed, 3 Aug 2016 20:52:42 +0000 Message-ID: <91547185801847a4951c4456d9d1dfb2@XCH-RTP-005.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.65.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 20:52:45 -0000 Its been 6+ months since I've worked with a BBB and the analog inputs. "Bac= k in the day", I used the interface as described by ti_adc(4) man page. How= ever, the last couple of days, I've built up an image using the code that i= s on the 11.0 release path. The problem I'm seeing is that the ADC controll= er appear to be disabled in this builds... root@beaglebone:~ # dmesg | grep adc ti_adc0: mem 0x44e0d000-0x44e0dfff disabled on simplebu= s0 ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0 ... and the sysctl interface seems to be similarly truncated.... root@beaglebone:~ # sysctl -a | grep adc dev.ti_adc.0.clockdiv: 2400 dev.ti_adc.0.%parent: simplebus0 dev.ti_adc.0.%pnpinfo: name=3Dtscadc@44e0d000 compat=3Dti,am3359-tscadc dev.ti_adc.0.%location:=20 dev.ti_adc.0.%driver: ti_adc dev.ti_adc.0.%desc: TI ADC controller dev.ti_adc.%parent:=20 I noticed in the /boot/msdos/bboneblk.dts file that tscadc@44e0d000 had a s= tatus =3D "disabled". I changed it to "okay" per other nodes, recompiled it= to bboneblk.dtb via dtc, rebooted, and still no joy. Is the boot process using these files, or is the device tree built in to th= e kernel (meaning I have to make fixes elsewhere and re-run the build)?= From owner-freebsd-arm@freebsd.org Thu Aug 4 03:04:20 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58D65BAE827 for ; Thu, 4 Aug 2016 03:04:20 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 078651CC1 for ; Thu, 4 Aug 2016 03:04:19 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=UPOfJ2Xy c=1 sm=1 tr=0 a=dx250bZxW1HngxdpQMIA3g==:117 a=dx250bZxW1HngxdpQMIA3g==:17 a=IkcTkHD0fZMA:10 a=OA2lqS22AAAA:8 a=YfCOm-DyAAAA:8 a=i5rowgypW5fFHoL2NJMA:9 a=z74lWWcead9heiOj:21 a=A1HTwXzq2kNMgf4y:21 a=dlp_2DpfmD4A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=NWVoK91CQySWRX1oVYDe:22 a=QDc1yJBve2YiRQBk1mDn:22 a=047cQLXTEfCjWPUe_kQW:22 a=zQLMK8awuJ6_Hvp-_9Ux:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 24.148.20.233 is neither permitted nor denied by domain of rcn.com) Received: from [24.148.20.233] ([24.148.20.233:26733] helo=[192.168.3.100]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.23.54417 r(Core:3.6.23.0)) with ESMTPSA (cipher=DHE-RSA-AES256-SHA) id B6/89-61435-9FBA2A75; Wed, 03 Aug 2016 22:44:09 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: U-boot issues on Banana Pi M2 From: Erik Moe In-Reply-To: <0403B533-40BC-4674-84CC-2CC3F732B45E@rcn.com> Date: Wed, 3 Aug 2016 21:44:09 -0500 Cc: manu@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0403B533-40BC-4674-84CC-2CC3F732B45E@rcn.com> To: freebsd-arm X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 03:04:20 -0000 I spent some time looking into this issue. I believe that the = u-boot-bananapim2 port is broken because the underlining u-boot code is = broken, at least for the BPI M2. I built u-boot directly from source = trying both the v2016.07 and v2016.09-rc1 releases and saw the same = failure: "Net: data abort". I built u-boot from HEAD as of 26fb8db = since there were a number of commits for sunxi. I=E2=80=99m not sure = which one resolved the issue, but by checking out the latest sources and = applying the freebsd patches I was able to get my BPI M2 to boot: U-Boot SPL 2016.09-rc1-00211-g26fb8db-dirty (Aug 02 2016 - 04:43:10) DRAM: 1024 MiB Trying to boot from MMC1 U-Boot 2016.09-rc1-00211-g26fb8db-dirty (Aug 02 2016 - 04:43:10 -0500) = Allwinner Technology CPU: Allwinner A31s (SUN6I) Model: Sinovoip BPI-M2 DRAM: 1 GiB WARNING: Caches not enabled MMC: SUNXI SD/MMC: 0 reading u-boot.env ** Unable to read "u-boot.env" from mmc0:1 ** Using default environment In: serial Out: serial Err: serial Net: eth0: ethernet@01c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 2 USB Device(s) found Hit any key to stop autoboot: 0 Booting from: mmc 0 ubldr.bin reading ubldr.bin 224660 bytes read in 51 ms (4.2 MiB/s) ## No elf image at address 0x42000000 ## Starting application at 0x42000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x7af3f4e8 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@dora, Sat Jul 16 04:11:42 CDT 2016) DRAM: 1024MB MMC Device 1 not found Number of U-Boot devices: 1 U-Boot env: loaderdev=3D'mmc 0' Found U-Boot device: disk Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: /boot/kernel/kernel data=3D0x65cd64+0x12729c = syms=3D[0x4+0x8e630+0x4+0xa3375] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/dtb/bananapim2.dtb size=3D0x6151 Loaded DTB from file 'bananapim2.dtb'. Kernel entry at 0x42200100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 24eff34(master): Sat Jul 16 04:23:13 CDT 2016 = root@dora:/usr/home/emoe/Projects/ARM/bannapi-m2/obj/arm.armv6/usr/home/em= oe/Projects/ARM/src/sys/ALLWINNER arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on = LLVM 3.8.0) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. CPU: Cortex A7 rev 3 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB enabled LABT branch prediction disabled LoUU:2 LoC:3 LoUIS:2 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 2-way instruction cache Read-Alloc Cache level 2: 1024KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory =3D 1073741824 (1024 MB) avail memory =3D 1035898880 (987 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: entropy device external interface kbd0 at kbdmux0 ofwbus0: aw_ccu0: on ofwbus0 . . . Thanks, Erik > On Jul 28, 2016, at 6:49 PM, Erik Moe wrote: >=20 > I=E2=80=99m having some issues with the u-boot-bananapim2 in ports. = It looks like a data abort exception. Does anybody else have a BPI M2 = that this port is working for them? If I read this right it=E2=80=99s = dying in the following function: >=20 > 4a00218c g F .text 00000038 sunxi_gpio_set_cfgpin >=20 > I think someone reported a similar but not the same issue upstream: = http://lists.denx.de/pipermail/u-boot/2016-June/258837.html >=20 > Thanks, > Erik >=20 >=20 > U-Boot SPL 2016.07 (Jul 16 2016 - 02:40:04) > DRAM: 1024 MiB > Trying to boot from MMC1 >=20 >=20 > U-Boot 2016.07 (Jul 16 2016 - 02:40:04 -0500) Allwinner Technology >=20 > CPU: Allwinner A31s (SUN6I) > Model: Sinovoip BPI-M2 > DRAM: 1 GiB > WARNING: Caches not enabled > MMC: SUNXI SD/MMC: 0 > reading u-boot.env >=20 > ** Unable to read "u-boot.env" from mmc0:1 ** > Using default environment >=20 > In: serial > Out: serial > Err: serial > Net: data abort > pc : [<7ef5f180>] lr : [<00000000>] > reloc pc : [<4a002180>] lr : [] > sp : 7af35f84 ip : 7efab502 fp : 00000017 > r10: 7efaaefe r9 : 7af3cee8 r8 : 000040a0 > r7 : 7ef9ee14 r6 : 00000000 r5 : 00000001 r4 : 00000000 > r3 : 0000000f r2 : 00000001 r1 : 00000000 r0 : ea00000e > Flags: nzCv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... >=20 > resetting ... >=20 From owner-freebsd-arm@freebsd.org Thu Aug 4 06:13:30 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13ECABAE855 for ; Thu, 4 Aug 2016 06:13:30 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A376F1C53 for ; Thu, 4 Aug 2016 06:13:29 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-ua0-x244.google.com with SMTP id 74so1674021uau.3 for ; Wed, 03 Aug 2016 23:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=lZ7Xy9qEHQMjxelWOzY9nwhOLRza+uylYRyp8JAdVYQ=; b=AMCxq8D/FoUu7eywoDxQYq432nrHYPPRMRrkCTEItsLBfYvPypdPPIvJRqBsNy4pH9 cIHfHhy0KBMc9XaeoFcuHJMyfCd3O61V0YN6nKAe7usYh3/o/cV6xHsqa+QIt76rPMQ+ wcStJziC0Q8AbOMsvokimZGmXTnwhiRQQ3ndYfK+9RW6ep2YGuOhS7iQdJyzCLYVTUrT 0n/QNOJuDrILZIMOaIZJa9VOK4qBqIBCcgRG1erzBq8my5Tc3JoNQ2HSQl824c0lCpiI U9B5TyKhwZNEanPocmQ2m2fYAEv69B4edlfgSC0CowlIq2xMd/vRZQ+AHFO98QVkXpZA jBGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lZ7Xy9qEHQMjxelWOzY9nwhOLRza+uylYRyp8JAdVYQ=; b=TKfPSvrFPKvrMVMo9wUvhk7hd47lJu8YrZaFWPCKYVhMK3CtD6IfinBPZC8v8cB8lj 9PMb12pVpJW2JKOfgcoz7nn6jQI6TWweCCKSwN34bzQDqkJzucScXyn7pCmabYohBPsg /kTSkcthSkYRycTPmU4YdO8QihEIIdcpY5XvLRL/GuMeI0dWYC5hExaM8c/JpIoezi2l fmS/s0FidhehBFoEiACyWY2x+rGvx3srFR9ejRdTKLgc5JtE2bHnIOIZT9XDkZv+PUnJ SwyLuuSFTwzk0KP0WTD0vLID/gXQO/feM7G5pnC6EVrdHNGNFFY1+bBcBYHIu5PV6lzj hGzg== X-Gm-Message-State: AEkooutMy8SSXcdTsFCmkDxJWI/KwcsqDvoC0e61cZOiTEnm21tiT9Vwmw8/M5DugfN6OyBwwRAQp5WhD1PoBQ== X-Received: by 10.159.33.5 with SMTP id 5mr34969842uab.36.1470291207312; Wed, 03 Aug 2016 23:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.54.75 with HTTP; Wed, 3 Aug 2016 23:13:26 -0700 (PDT) From: Russell Haley Date: Wed, 3 Aug 2016 23:13:26 -0700 Message-ID: Subject: u-boot-cubox-hummingboard port fails to build with arm-none-eabi-gcc-5.3.0 on 10.3-RELEASE p5 To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 06:13:30 -0000 Hello, In order to answer Mr. Michel Kohanim I decided to give building an image a try again. Fortunately or un-fortunately, I did so just after a 10.3-RELEASE update that pushed my arm-none-eabi-gcc version from 4.9.2 to 5.3.0. The u-boot port for the hummingboard fails during the installation of gcc: install -m 0644 b-header-vars /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/plugin/include/b-header-vars gmake[3]: Leaving directory '/usr/ports/devel/arm-none-eabi-gcc492/work/build-gcc/gcc' gmake[3]: Entering directory '/usr/ports/devel/arm-none-eabi-gcc492/work/build-gcc/arm-none-eabi/libgcc' /bin/sh ../.././../gcc-4.9.2/libgcc/../mkinstalldirs /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2 install -m 0644 libgcc.a /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/ chmod 644 /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/libgcc.a /usr/local/arm-none-eabi/bin/ranlib /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/libgcc.a install -m 0644 libgcov.a /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/ chmod 644 /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/libgcov.a /usr/local/arm-none-eabi/bin/ranlib /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/libgcov.a parts="crtbegin.o crtend.o crti.o crtn.o"; \ for file in $parts; do \ rm -f /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/$file; \ install -m 0644 $file /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/; \ case $file in \ *.a) \ /usr/local/arm-none-eabi/bin/ranlib ../.././gcc/$file ;; \ esac; \ done /bin/sh ../.././../gcc-4.9.2/libgcc/../mkinstalldirs /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/include install -m 0644 unwind.h /usr/ports/devel/arm-none-eabi-gcc492/work/stage/usr/local/lib/gcc/arm-none-eabi/4.9.2/include gmake[3]: Leaving directory '/usr/ports/devel/arm-none-eabi-gcc492/work/build-gcc/arm-none-eabi/libgcc' gmake[2]: Leaving directory '/usr/ports/devel/arm-none-eabi-gcc492/work/build-gcc' ====> Compressing man pages (compress-man) ===> Installing for arm-none-eabi-gcc492-4.9.2_2 ===> Checking if arm-none-eabi-gcc492 already installed ===> Registering installation for arm-none-eabi-gcc492-4.9.2_2 as automatic Installing arm-none-eabi-gcc492-4.9.2_2... pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with arm-none-eabi-gcc-5.3.0 (installs files into the same place). Problematic file: /usr/local/bin/arm-none-eabi-c++ *** Error code 70 Stop. make[1]: stopped in /usr/ports/devel/arm-none-eabi-gcc492 *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/u-boot-cubox-hummingboard So I tried modifying the port to use arm-none-eabi-gcc version 5.3.0. That didn't work: sudo make ===> License GPLv2 accepted by the user ===> u-boot-cubox-hummingboard-2013.10_1 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by u-boot-cubox-hummingboard-2013.10_1 for building ===> Extracting for u-boot-cubox-hummingboard-2013.10_1 => SHA256 Checksum OK for SolidRun-u-boot-imx6-2013.10-e4bc4c3_GH0.tar.gz. ===> Patching for u-boot-cubox-hummingboard-2013.10_1 ===> Applying FreeBSD patches for u-boot-cubox-hummingboard-2013.10_1 ===> u-boot-cubox-hummingboard-2013.10_1 depends on executable: arm-none-eabi-gcc-5.3.0 - found ===> u-boot-cubox-hummingboard-2013.10_1 depends on executable: gmake - found ===> Configuring for u-boot-cubox-hummingboard-2013.10_1 cd /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3; gmake ARCH=arm CC=arm-none-eabi-gcc-5.3.0 CROSS_COMPILE=arm-none-eabi- HOSTCC=cc DESTDIR=/usr/ports/sysutils/u-boot-cubox-hummingboard/work/stage mx6_cubox-i_config gmake[1]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3' Configuring for mx6_cubox-i - Board: mx6_cubox-i, Options: IMX_CONFIG=board/solidrun/mx6_cubox-i/imx6image.cfg,MX6QDL,SPL,FSL_ENV_IN_MMC gmake[1]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3' ===> Building for u-boot-cubox-hummingboard-2013.10_1 gmake[1]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3' Generating include/autoconf.mk In file included from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler.h:40:0, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/byteorder/little_endian.h:12, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/byteorder.h:29, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/compiler.h:112, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/image.h:19, from include/common.h:100: /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler-gcc.h:93:30: fatal error: linux/compiler-gcc5.h: No such file or directory compilation terminated. Generating include/autoconf.mk.dep In file included from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler.h:40:0, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/byteorder/little_endian.h:12, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/byteorder.h:29, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/compiler.h:112, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/image.h:19, from include/common.h:100: /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler-gcc.h:93:30: fatal error: linux/compiler-gcc5.h: No such file or directory compilation terminated. Generating include/spl-autoconf.mk Generating include/tpl-autoconf.mk In file included from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler.h:40:0, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/byteorder/little_endian.h:12, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/byteorder.h:29, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/compiler.h:112, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/image.h:19, from include/common.h:100: /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler-gcc.h:93:30: fatal error: linux/compiler-gcc5.h: No such file or directory compilation terminated. In file included from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler.h:40:0, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/byteorder/little_endian.h:12, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/byteorder.h:29, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/compiler.h:112, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/image.h:19, from include/common.h:100: /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler-gcc.h:93:30: fatal error: linux/compiler-gcc5.h: No such file or directory compilation terminated. arm-none-eabi-gcc-5.3.0 -DDO_DEPS_ONLY \ -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage \ -o lib/asm-offsets.s lib/asm-offsets.c -c -S if [ -f arch/arm/cpu/armv7/mx6/asm-offsets.c ];then \ arm-none-eabi-gcc-5.3.0 -DDO_DEPS_ONLY \ -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage \ -o arch/arm/cpu/armv7/mx6/asm-offsets.s arch/arm/cpu/armv7/mx6/asm-offsets.c -c -S; \ else \ touch arch/arm/cpu/armv7/mx6/asm-offsets.s; \ fi Generating include/generated/asm-offsets.h tools/scripts/make-asm-offsets arch/arm/cpu/armv7/mx6/asm-offsets.s include/generated/asm-offsets.h In file included from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler.h:40:0, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/byteorder/little_endian.h:12, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/byteorder.h:29, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/compiler.h:112, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/image.h:19, from /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/common.h:100, from lib/asm-offsets.c:15: /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/linux/compiler-gcc.h:93:30: fatal error: linux/compiler-gcc5.h: No such file or directory compilation terminated. gmake[1]: *** [Makefile:747: lib/asm-offsets.s] Error 1 gmake[1]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/u-boot-cubox-hummingboard So, I then copied .../include/linux/compiler-gcc4.h to .../include/linux/compiler-gcc5.h, which ran a little further until: sudo make ===> Building for u-boot-cubox-hummingboard-2013.10_1 gmake[1]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3' arm-none-eabi-gcc-5.3.0 -DDO_DEPS_ONLY \ -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage \ -o lib/asm-offsets.s lib/asm-offsets.c -c -S Generating include/generated/generic-asm-offsets.h tools/scripts/make-asm-offsets lib/asm-offsets.s include/generated/generic-asm-offsets.h for dir in tools examples/standalone examples/api arch/arm/cpu/armv7 ; do \ gmake -C $dir _depend ; done gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools' cat /dev/null >.depend gmake[2]: Nothing to be done for '_depend'. gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools' gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/examples/standalone' arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ hello_world.o hello_world.c >.depend.hello_world arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ stubs.o stubs.c >.depend.stubs cat /dev/null .depend.hello_world .depend.stubs >.depend gmake[2]: Nothing to be done for '_depend'. gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/examples/standalone' gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/examples/api' cat /dev/null >.depend gmake[2]: Nothing to be done for '_depend'. gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/examples/api' gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7' arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ start.o start.S >.depend.start arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ cache_v7.o cache_v7.c >.depend.cache_v7 arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ cpu.o cpu.c >.depend.cpu arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ syslib.o syslib.c >.depend.syslib cat /dev/null .depend.start .depend.cache_v7 .depend.cpu .depend.syslib >.depend gmake[2]: Nothing to be done for '_depend'. gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7' gmake -C tools all gmake -C arch/arm/cpu/armv7 start.o gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools' gmake -C /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/ u-boot.lds gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7' gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu' gmake[2]: Nothing to be done for 'u-boot.lds'. gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu' arm-none-eabi-gcc-5.3.0 -E -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/u-boot/u-boot.lds.h -DCPUDIR=arch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - u-boot.lds arm-none-eabi-gcc-5.3.0 -D__ASSEMBLY__ -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -o start.o start.S -c cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o crc32.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/crc32.c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o mkenvimage.o mkenvimage.c -c gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7' cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o os_support.o os_support.c -c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o aisimage.o aisimage.c -c cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -c -o image-sig.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/common/image-sig.c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o default_image.o default_image.c -c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o fit_image.o fit_image.c -c cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -c -o image-fit.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/common/image-fit.c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o image-host.o image-host.c -c cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -c -o image.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/common/image.c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o imximage.o imximage.c -c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o kwbimage.o kwbimage.c -c cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o md5.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/md5.c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o mkimage.o mkimage.c -c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o mxsimage.o mxsimage.c -c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o omapimage.o omapimage.c -c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o pblimage.o pblimage.c -c cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o sha1.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/sha1.c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o ublimage.o ublimage.c -c pblimage.c:179:16: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (crc32_val < 0) { ~~~~~~~~~ ^ ~ cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -c -o fdt.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt/fdt.c /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/sha1.c:392:19: warning: unused variable '_sha1_src' [-Wunused-const-variable] static const char _sha1_src[] = "_sha1_src"; ^ cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -c -o fdt_ro.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt/fdt_ro.c cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -c -o fdt_rw.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt/fdt_rw.c cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -c -o fdt_strerror.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt/fdt_strerror.c 1 warning generated. cc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -c -o fdt_wip.o /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt/fdt_wip.c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -o proftool.o proftool.c -c cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -o mkenvimage crc32.o mkenvimage.o os_support.o gmake[3]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools/kernel-doc' cat /dev/null >.depend strip mkenvimage cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pedantic -o docproc docproc.c docproc.c:182:58: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign] static void adddep2(char * file, char * line) { line = line; adddep(file); } ~~~~ ^ ~~~~ docproc.c:183:46: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign] static void noaction(char * line) { line = line; } ~~~~ ^ ~~~~ docproc.c:184:58: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign] static void noaction2(char * file, char * line) { file = file; line = line; } ~~~~ ^ ~~~~ docproc.c:184:71: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign] static void noaction2(char * file, char * line) { file = file; line = line; } ~~~~ ^ ~~~~ cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -o proftool proftool.o strip proftool 1 warning generated. cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/libfdt_env.h -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include2 -idirafter /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/lib/libfdt -I /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -o mkimage aisimage.o image-sig.o crc32.o default_image.o fit_image.o image-fit.o image-host.o image.o imximage.o kwbimage.o md5.o mkimage.o mxsimage.o omapimage.o os_support.o pblimage.o sha1.o ublimage.o fdt.o fdt_ro.o fdt_rw.o fdt_strerror.o fdt_wip.o 4 warnings generated. strip docproc gmake[3]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools/kernel-doc' strip mkimage gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/tools' gmake -C api/ gmake -C arch/arm/cpu/armv7/ gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/api' gmake -C arch/arm/cpu/armv7/mx6/ gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7' gmake -C arch/arm/imx-common/ gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7/mx6' gmake -C arch/arm/lib/ gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/imx-common' gmake -C common/ gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/lib' gmake -C disk/ gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/common' gmake -C drivers/bios_emulator/ gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/disk' cat /dev/null >.depend gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/bios_emulator' arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ soc.o soc.c >.depend.soc arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ cpu.o cpu.c >.depend.cpu arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ _ashldi3.o _ashldi3.S >.depend._ashldi3 arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cache_v7.o cache_v7.c -c arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ cmd_boot.o cmd_boot.c >.depend.cmd_boot cat /dev/null >.depend cat /dev/null >.depend arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ _ashrdi3.o _ashrdi3.S >.depend._ashrdi3 arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ _divsi3.o _divsi3.S >.depend._divsi3 rm -f libapi.o; arm-none-eabi-ar rcs libapi.o gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/api' arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ clock.o clock.c >.depend.clock arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ _lshrdi3.o _lshrdi3.S >.depend._lshrdi3 rm -f libdisk.o; arm-none-eabi-ar rcs libdisk.o arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ iomux-v3.o iomux-v3.c >.depend.iomux-v3 arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cpu.o cpu.c -c gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/disk' rm -f libatibiosemu.o; arm-none-eabi-ar rcs libatibiosemu.o gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/bios_emulator' cat /dev/null .depend.soc .depend.clock >.depend arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ misc.o misc.c >.depend.misc arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o soc.o soc.c -c arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ speed.o speed.c >.depend.speed arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ cmd_disk.o cmd_disk.c >.depend.cmd_disk arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ _modsi3.o _modsi3.S >.depend._modsi3 arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o clock.o clock.c -c arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ _udivsi3.o _udivsi3.S >.depend._udivsi3 arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ _umodsi3.o _umodsi3.S >.depend._umodsi3 arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ div0.o div0.c >.depend.div0 arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ crt0.o crt0.S >.depend.crt0 arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ relocate.o relocate.S >.depend.relocate arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ board.o board.c >.depend.board arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ sections.o sections.c >.depend.sections arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ interrupts.o interrupts.c >.depend.interrupts arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ reset.o reset.c >.depend.reset arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ cache.o cache.c >.depend.cache arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ timer.o timer.c >.depend.timer arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o syslib.o syslib.c -c gmake -C drivers/block/ arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ cmd_help.o cmd_help.c >.depend.cmd_help arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -MQ cache-cp15.o cache-cp15.c >.depend.cache-cp15 gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/block' gmake -C drivers/crypto/ gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/crypto' cat /dev/null >.depend gmake -C drivers/dfu/ cat /dev/null .depend.cpu .depend.iomux-v3 .depend.misc .depend.speed .depend.timer >.depend gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/dfu' cat /dev/null >.depend cat /dev/null .depend._ashldi3 .depend._ashrdi3 .depend._divsi3 .depend._lshrdi3 .depend._modsi3 .depend._udivsi3 .depend._umodsi3 .depend.div0 .depend.crt0 .depend.relocate .depend.board .depend.sections .depend.interrupts .depend.reset .depend.cache .depend.cache-cp15 >.depend cat /dev/null >.depend rm -f libblock.o; arm-none-eabi-ar rcs libblock.o gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/block' arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ cmd_load.o cmd_load.c >.depend.cmd_load gmake -C drivers/dma/ rm -f libcrypto.o; arm-none-eabi-ar rcs libcrypto.o arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cpu.o cpu.c -c gmake[2]: Entering directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/dma' arm-none-eabi-gcc-5.3.0 -D__ASSEMBLY__ -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -o crt0.o crt0.S -c gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/crypto' arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o iomux-v3.o iomux-v3.c -c rm -f libdfu.o; arm-none-eabi-ar rcs libdfu.o arm-none-eabi-gcc-5.3.0 -D__ASSEMBLY__ -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -o relocate.o relocate.S -c gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/dfu' arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ cmd_nvedit.o cmd_nvedit.c >.depend.cmd_nvedit cat /dev/null >.depend arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o misc.o misc.c -c arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ cmd_pcmcia.o cmd_pcmcia.c >.depend.cmd_pcmcia rm -f libdma.o; arm-none-eabi-ar rcs libdma.o gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/drivers/dma' arm-none-eabi-ld.bfd -r -o libmx6.o soc.o clock.o arm-none-eabi-ld.bfd -r -o libarmv7.o cache_v7.o cpu.o syslib.o clock.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesb' soc.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here clock.o: In function `get_ipg_clk': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7/mx6/clock.c:195: multiple definition of `__raw_writesw' soc.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here clock.o: In function `get_ipg_clk': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7/mx6/clock.c:195: multiple definition of `__raw_writesl' soc.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7' clock.o: In function `get_ipg_clk': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7/mx6/clock.c:195: multiple definition of `__raw_readsb' soc.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here clock.o: In function `get_ipg_clk': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7/mx6/clock.c:195: multiple definition of `__raw_readsw' soc.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here clock.o: In function `get_ipg_clk': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7/mx6/clock.c:195: multiple definition of `__raw_readsl' soc.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here gmake[2]: *** [Makefile:23: libmx6.o] Error 1 gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/cpu/armv7/mx6' arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ cmd_version.o cmd_version.c >.depend.cmd_version arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ command.o command.c >.depend.command arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ console.o console.c >.depend.console arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o board.o board.c -c gmake -C drivers/fpga/ gmake[1]: *** [Makefile:600: arch/arm/cpu/armv7/mx6/libmx6.o] Error 2 arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o sections.o sections.c -c gmake[1]: *** Waiting for unfinished jobs.... arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ dlmalloc.o dlmalloc.c >.depend.dlmalloc arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o speed.o speed.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o interrupts.o interrupts.c -c arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ env_attr.o env_attr.c >.depend.env_attr arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ env_callback.o env_callback.c >.depend.env_callback arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o timer.o timer.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o reset.o reset.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cache.o cache.c -c arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ env_common.o env_common.c >.depend.env_common arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cache-cp15.o cache-cp15.c -c board.c:66:6: error: 'coloured_LED_init' aliased to external symbol '__coloured_LED_init' void coloured_LED_init(void) ^ board.c:83:6: error: 'blue_led_off' aliased to external symbol '__blue_led_off' void blue_led_off(void) __attribute__((weak, alias("__blue_led_off"))); ^ board.c:81:6: error: 'blue_led_on' aliased to external symbol '__blue_led_on' void blue_led_on(void) __attribute__((weak, alias("__blue_led_on"))); ^ board.c:79:6: error: 'yellow_led_off' aliased to external symbol '__yellow_led_off' void yellow_led_off(void) __attribute__((weak, alias("__yellow_led_off"))); ^ board.c:77:6: error: 'yellow_led_on' aliased to external symbol '__yellow_led_on' void yellow_led_on(void) __attribute__((weak, alias("__yellow_led_on"))); ^ board.c:75:6: error: 'green_led_off' aliased to external symbol '__green_led_off' void green_led_off(void) __attribute__((weak, alias("__green_led_off"))); ^ board.c:73:6: error: 'green_led_on' aliased to external symbol '__green_led_on' void green_led_on(void) __attribute__((weak, alias("__green_led_on"))); ^ board.c:71:6: error: 'red_led_off' aliased to external symbol '__red_led_off' void red_led_off(void) __attribute__((weak, alias("__red_led_off"))); ^ board.c:69:6: error: 'red_led_on' aliased to external symbol '__red_led_on' void red_led_on(void) __attribute__((weak, alias("__red_led_on"))); ^ gmake[2]: *** [/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/config.mk:374: board.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ env_flags.o env_flags.c >.depend.env_flags arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ exports.o exports.c >.depend.exports arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ flash.o flash.c >.depend.flash arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ hash.o hash.c >.depend.hash arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ image.o image.c >.depend.image arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ main.o main.c >.depend.main arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ memsize.o memsize.c >.depend.memsize arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ s_record.o s_record.c >.depend.s_record arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ splash.o splash.c >.depend.splash arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ stdio.o stdio.c >.depend.stdio arm-none-eabi-gcc-5.3.0 -M -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -I.. -MQ xyzModem.o xyzModem.c >.depend.xyzModem cat /dev/null .depend.cmd_boot .depend.cmd_disk .depend.cmd_help .depend.cmd_load .depend.cmd_nvedit .depend.cmd_pcmcia .depend.cmd_version .depend.command .depend.console .depend.dlmalloc .depend.env_attr .depend.env_callback .depend.env_common .depend.env_flags .depend.exports .depend.flash .depend.hash .depend.image .depend.main .depend.memsize .depend.s_record .depend.splash .depend.stdio .depend.xyzModem >.depend arm-none-eabi-ld.bfd -r -o libimx-common.o cpu.o iomux-v3.o misc.o speed.o timer.o iomux-v3.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesb' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here iomux-v3.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesw' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here iomux-v3.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesl' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here iomux-v3.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_readsb' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here iomux-v3.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_readsw' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here iomux-v3.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_readsl' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here misc.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesb' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here misc.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesw' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here misc.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesl' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here misc.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_readsb' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here misc.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_readsw' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here misc.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_readsl' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here timer.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesb' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here timer.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesw' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here timer.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_writesl' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here timer.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_readsb' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here timer.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_readsw' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here timer.o: In function `__raw_writesb': /usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: multiple definition of `__raw_readsl' cpu.o:/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include/asm/io.h:79: first defined here gmake[2]: *** [Makefile:34: libimx-common.o] Error 1 gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/imx-common' gmake[1]: *** [Makefile:600: arch/arm/imx-common/libimx-common.o] Error 2 arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cmd_boot.o cmd_boot.c -c gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/arch/arm/lib' arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cmd_disk.o cmd_disk.c -c gmake[1]: *** [Makefile:600: arch/arm/lib/libarm.o] Error 2 arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cmd_help.o cmd_help.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cmd_load.o cmd_load.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cmd_nvedit.o cmd_nvedit.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cmd_pcmcia.o cmd_pcmcia.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cmd_version.o cmd_version.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o command.o command.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o console.o console.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o dlmalloc.o dlmalloc.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o env_attr.o env_attr.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o env_callback.o env_callback.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o env_common.o env_common.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o env_flags.o env_flags.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o exports.o exports.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o flash.o flash.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o hash.o hash.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o image.o image.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o main.o main.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o memsize.o memsize.c -c arm-none-eabi-gcc-5.3.0 -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -I/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/lib/gcc/arm-none-eabi/5.3.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o s_record.o s_record.c -c main.c:31:6: error: 'show_boot_progress' aliased to external symbol '__show_boot_progress' void show_boot_progress (int val) __attribute__((weak, alias("__show_boot_progress"))); ^ gmake[2]: *** [/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/config.mk:374: main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... gmake[2]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3/common' gmake[1]: *** [Makefile:600: common/libcommon.o] Error 2 gmake[1]: Leaving directory '/usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-imx6-e4bc4c3' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/u-boot-cubox-hummingboard At this point I am out of my depth and pretty sure my copy of the linux/compiler-gcc4.h file wasn't really correct. Any input would be grand. Thanks, Russ From owner-freebsd-arm@freebsd.org Thu Aug 4 09:31:40 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4C49BAE0CD; Thu, 4 Aug 2016 09:31:40 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F4FE1BCA; Thu, 4 Aug 2016 09:31:40 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 160693ACCB; Thu, 4 Aug 2016 11:31:31 +0200 (CEST) From: Michal Meloun Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> <57A09F34.4050400@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" X-Enigmail-Draft-Status: N1110 Message-ID: <57A30B72.7070809@FreeBSD.org> Date: Thu, 4 Aug 2016 11:31:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Thu, 04 Aug 2016 11:31:31 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 09:31:41 -0000 Dne 02.08.2016 v 17:31 Nathan Whitehorn napsal(a): > > > On 08/02/16 06:25, Michal Meloun wrote: >> I'm sorry for delayed response. We have serious trouble @work so I >> cannot spend to much time on FreeBSB for next 2 or 3 days. > > Understood. > >> >> Dne 02.08.2016 v 6:00 Nathan Whitehorn napsal(a): >>> >>> On 07/31/16 11:43, Nathan Whitehorn wrote: >>>> >>>> On 07/31/16 08:40, Michal Meloun wrote: >>>>> Dne 31.07.2016 v 8:11 Nathan Whitehorn napsal(a): >>>>> [snip] >>>>>>> The current API is certainly a bit of a hack and I would be >>>>>>> pleased to >>>>>>>> see it go; but the replacement needs to be more functional and >>>>>>>> more >>>>>>>> robust. As far as I can tell, I literally *cannot* move PowerPC >>>>>>>> over >>>>>>>> to this architecture. >>>>>>> Yes, at this time, I agree. If you can accept enhancement of >>>>>>> (owf_)bus_map_intr() then we can move to next, significantly less >>>>>>> hackish, state. >>>>>> OK, sure. I wrote some code this afternoon (attached) to sketch >>>>>> this. >>>>>> It does not compile or run or anything useful, but it should >>>>>> illustrate the important parts of what I think is an API that should >>>>>> work for everyone. I'm happy to finish it if it looks reasonable >>>>>> -- I >>>>>> may in any case just to replace PowerPC's increasingly teetering >>>>>> intr_machdep.c. >>>>>> >>>>>> The OF part is essentially unchanged from how it currently works: >>>>>> there's a method that you pass the interrupt specifier and interrupt >>>>>> parent to, and it spits back an IRQ that means that combination of >>>>>> things in perpetuity. OFW_BUS_MAP_INTR() in nexus.c, with its >>>>>> current >>>>>> API, can be implemented in terms of it in one line. Whenever the >>>>>> relevant PIC attaches, it is told to use the given IRQ to refer to >>>>>> that opaque bytestring. >>>>>> >>>>>> I've added a set of equivalent functions for ACPI that take the >>>>>> contents of an ACPI interrupt specifier and do the same things. It >>>>>> tries to have the IRQ be human-meaningful, if possible, by matching >>>>>> the ACPI interrupt number. Having separate functions seemed a little >>>>>> cleaner than exposing the enums and unions as part of the KPI, >>>>>> but I'm >>>>>> not wedded to it -- this is just an example. >>>>>> >>>>>> PICs register (and deregister) themselves with either an OF >>>>>> phandle or >>>>>> an ACPI resource string or (god help us) both as needed. The PICs >>>>>> have >>>>>> corresponding methods for interpreting various kinds of interrupt >>>>>> specifiers. >>>>>> >>>>>> Whether it allows bus_alloc_resource(), bus_setup_intr(), etc. to >>>>>> succeed before the PICs are attached is gated on an #ifdef. That can >>>>>> probably be off by default on ARM. A PowerPC version of this code >>>>>> would have to keep it on until various bus drivers are fixed. >>>>>> >>>>>> Here's the general flow: >>>>>> - Parent bus enumerates children, maps IRQs as needed, adds to >>>>>> resource list. The struct resources involved aren't special (just a >>>>>> single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are trivial to >>>>>> implement (and already are implemented, in general, for OF/FDT >>>>>> drivers). >>>>>> - bus_alloc_resource() does nothing special >>>>>> - bus_setup_intr() calls into the PIC and does what is needed, as in >>>>>> r301453 (to within that #ifdef) >>>>>> >>>>>> This should keep all the best pieces of everything: >>>>>> - ACPI and OF are supported together, and easy to extend for other >>>>>> types of mapping technologies without breaking either KBI or KPI >>>>>> (just >>>>>> add new functions) >>>>>> - No APIs change for existing Open Firmware code >>>>>> - The support code can live entirely in machine-dependent >>>>>> directories, >>>>>> with no code changes at all required in kern/ or dev/ofw/ >>>>>> - bus_setup_intr() and friends behave as in r301453 and succeed or >>>>>> fail for real >>>>>> - PCI code is not an issue >>>>>> - No disconnected interrupt state maintained in mapping table >>>>>> (unless >>>>>> the transitional #ifdef is on) and the mapping table content is only >>>>>> larger than r301453 by having a copy of the original interrupt >>>>>> specifier. >>>>>> >>>>>> If and when we manage to fix the kernel APIs to allow non-scalar >>>>>> interrupt specifiers, this should also be easy to gradually >>>>>> transmogrify to support that case since there exists a 1:1 >>>>>> mapping of >>>>>> scalar IRQs to rich data and the control flow would be identical: >>>>>> interrupt specifiers are read at enumeration time and a resulting >>>>>> handle -- struct resource or scalar IRQ -- used afterward to refer >>>>>> to it. >>>>>> >>>>> Nice, nice, i think that we are very close at this point. >>>>> The problem with the above workflow is that maps IRQ function is >>>>> called >>>>> at parent bus enumeration time, generally at BUS_PASS_BUS pass. >>>>> And at >>>>> this time, PICs are not exist. >>>>> Also, 'static struct intr_irqsrc *irq_sources[NIRQ];' is not a >>>>> mapping >>>>> table, it doesn't provide this functionality. >>>>> But yes, i understand that mapping table is important and necessary >>>>> for you. >>>>> >>>>> So, if i can extend our concept a little bit, then: >>>>> We can add new table (map_data_tbl for example) that holds a >>>>> copy of >>>>> the original interrupt specifier, index to irq_sources table and >>>>> probably some flags. >>>>> And we can modify the above workflow to: >>>>> - Parent bus enumerates children, allocates entries from >>>>> map_data_tbl, >>>>> adds to resource list. The struct resources involved aren't special >>>>> (just a single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are >>>>> trivial to implement (and already are implemented, in general, for >>>>> OF/FDT drivers). Index to map_data_tbl is used as resource ID. >>>>> - bus_alloc_resource() sets 'ALLOCATED' in map_data_tbl flags field, >>>>> *maps IRQs* and stores result in 'index' field. >>>>> - bus_setup_intr() sets 'SETUP_DONE' in map_data_tbl flags field, >>>>> calls >>>>> into the PIC and does what is needed, as in r301453. (to within that >>>>> #ifdef) >>>>> >>>>> And, in PPC case, newly attached PIC scans whole map_data_tbl table, >>>>> finds his entries and makes what needs. >>>>> >>>>> Does that make sense? >>>>> I hope that postponing of map IRQ call is not a problem for PPC, >>>>> everything else looks easy. >>>>> Moreover, this additional level of indirection also solves all my >>>>> 'hypothetical corner cases' with N:1 mappings (between original >>>>> interrupt specifier and real interrupt number). >>>> Yes, I think we are converging. >>>> >>>> My qualm about bus_alloc_resource() is twofold: >>>> 1. Traditionally, with interrupts, bus_alloc_resource() has no side >>>> effects and I'm not sure it propagates cleanly down the tree in all >>>> cases. >>>> 2. There are a few bus APIs (bus_config_intr() comes to mind) that >>>> use raw IRQ IDs and, so far as I know, can be, and sometimes are >>>> called before bus_alloc_resource(). If the PIC doesn't know about the >>>> IRQ yet when bus_config_intr() (etc.) is called, things will just >>>> break. >>>> >>>> So you would need to make sure that any bus method handling a >>>> resource ID causes it to be mapped on the PIC at that time. It's OK >>>> if that happens in bus_alloc_resource() so long as bus_config_intr(), >>>> bus_setup_intr(), etc. cause that to happen if it hasn't happened yet >>>> -- I don't care when these calls are made to the PIC driver so long >>>> as *what* calls will be made is set at enumeration time. >>>> >>>> I am also totally fine with having, on ARM, bus_config_intr(), >>>> bus_setup_intr() etc. fail if the PIC hasn't attached yet (On >>>> PowerPC, we can't do that yet, but after this conversation, I regard >>>> that as a bug and would fix that later), as well as delaying setup on >>>> the PIC to the first time any bus driver actually tries to *use* the >>>> interrupt (alloc_resource(), setup_intr(), config_intr(), whatever) >>>> rather than when the interrupt is originally allocated. >>>> >> I understand. And yes, bus_alloc_resource() isn't propagated cleanly >> down the tree in all cases. That's why we have 'INTRNG' hook in >> subr_bus.c, which is suboptimal. >> >> About bus_config_intr(). The only consumer of bus_config_intr() is ACPI >> code, in little hackish manner, as workaround for problem which is >> fully solved by INTRNG. >> Also, the semantic of bus_config_intr() is not clear, from INTRNG point >> of view. >> So i have tendency to ignore it :) > > Heh. Fair enough. I hadn't noticed that -- though I can see legitimate > uses for it in the context of GPIOs. In any case, I'm a little wary of > bus_alloc_resource() having side effects. Usually > bus_activate_resource() would do that kind of thing. Yes, good catch!! bus_activate_resource() is definitively best method. > >> >>>> ------------ The following is a large parenthesis ------------------- >>>> >>>> One other possible route here that would also work well would be to >>>> make ofwbus.c MD (it's a trivial piece of code anyway, so we don't >>>> gain a lot by sharing it) and implement ofw_bus_map_intr() locally as >>>> an ofwbus bus method. Then you could have the mapping table stored in >>>> ofwbus's softc -- the API was designed for this initially. You would >>>> need MD extensions for doing PIC registration there (which is fine), >>>> but that segregates all the OFW-specific information into >>>> OFW-specific code and would let the bus methods and the OFW interrupt >>>> mapping table interact cleanly in the same place. This still >>>> preserves the pre-r301453 API, makes PowerPC work, and maybe >>>> address's skra@'s concern about extensibility and letting core >>>> interrupt code know about FDT (or ACPI). I'd be happy to mock this up >>>> as well if you think it's a good approach. >>>> >>> [snip] >>>> This has the following features: >>>> - Existing OFW API and semantics unchanged >>>> - As such, PowerPC, PCI, etc. work fine with no changes >>>> - Details encapsulated in MD code, so individual platforms can >>>> implement this however they like >>>> - arm/arm/intr.c (or whatever) only needs a method to allocate a >>>> fresh interrupt, with no state, and anoter to set the device_t for an >>>> interrupt sometime later. >>>> - The internal table in the platform interrupt code has no knowledge >>>> of any mappings whatsoever except having the appropriate device_t for >>>> the PIC stored with the interrupt vector. >>>> - Device tree bits handled purely in device tree code >>>> - No action need be taken on any mapping until the interrupt is >>>> actually allocated/set up, like r301453 >>>> - Easy to add more mapping mechanisms (e.g. ACPI) by having similar >>>> enumeration-mechanism-specific code in the root bus for that mapping >>>> mechanism. >>>> >>>> -------------- End parenthesis ------------------------------- >>> Here's an implementation of the parenthesis I wrote on an airplane >>> this afternoon. It should be complete, though has not been tested. The >>> code is short and simple (+70 lines in ofwbus.c). This preserves the >>> pre-r301453 API and semantics relative to drivers, which means PowerPC >>> and PCI work out of the box, while keeping the semantics relative to >>> the interrupt layer of r301453 (PIC methods only called on resource >>> allocation, no allocatable IRQs on unattached PICs, encapsulation of >>> OFW-specific code in OFW-specific bits of the tree). It turns out >>> those two things are compatible, somewhat to my surprise, and that >>> makes the result very clean. I like this approach and would be happy >>> to move forward with it. There are five functions of interest: >>> >>> 1. OFW_BUS_MAP_INTR(). This has the semantics and API it has now: you >>> pass an interrupt specifier and parent, you get back an IRQ. No >>> changes. This is the core of the normal OFW interrupt API. >>> >>> 2. OFW_BUS_REGISTER_PIC(device_t pic, phandle_t phandle). This is a >>> new function that PIC drivers are supposed to use to register control >>> of an interrupt domain. This replaces machine-specific code like >>> powerpc_register_pic() to allow the PIC table to be in a bus parent >>> rather than in the interrupt core. >>> >>> 3. PIC_MAP_OFW_INTR(device_t pic, int irq, interrupt specifier). This >>> is a new function that PIC drivers that know how to handle device-tree >>> interrupt descriptors implement (analogous to various existing ones >>> that vary by platform). It tells the PIC that the given abstract IRQ >>> means the given opaque interrupt specifier. >>> >>> 4. arm_allocate_irq(int suggested). This allocates a new IRQ number >>> not (yet) attached to a PIC, as in r301453. I've added a parameter >>> that lets you pass a suggested number to try in case it is possible to >>> make it match an interrupt pin or something for human-readability. >>> >>> 5. arm_set_pic_for_irq(int irq, device_t). This tells the MD interrupt >>> layer to associate a given PIC device_t with an IRQ. That is all the >>> information the MD layer ever has about the IRQ mapping. >>> >>> Functions #1 and #2 are now implemented completely in ofwbus.c: there >>> are no callouts anywhere else and the interrupt mapping table is >>> maintained entirely internally to ofwbus (in its softc). In order to >>> implement ACPI, or some other strategy, you would implement analogs to >>> functions #1 and #2 that live somewhere in the bus hierarchy that is >>> guaranteed to be above all devices that might want that type of >>> interrupt (e.g. in acpi0), and some analog to #3 that PIC drivers >>> implementing the mapping scheme would provide. >>> >>> Since the system interrupt code has no knowledge at all of interrupt >>> mapping, of any type, in this scheme, adding new mapping types is >>> trivial and can be done on a driver-by-driver basis if necessary >>> without changing KPI and without any other part of the system even >>> being aware. For example, GPIOs can use a completely different >>> mechanism if they want and can do setup purely in the GPIO controller >>> driver. You could have a method GPIO_GET_INTERRUPT_FOR_PIN() on a GPIO >>> controller in which the GPIO controller allocates a generic IRQ, >>> assigns through some internal table just in the GPIO driver, and >>> returns to it to a consumer in some other device driver -- without a >>> GPIO mapping type, new bus functions, or modifications to the platform >>> interrupt code. >>> >>> The control flow goes like this: >>> - Bus driver enumerates children, parses interrupts properties, calls >>> OFW_BUS_MAP_INTR() to get IRQs for them (as pre-r301453), adds to >>> interrupt list. >>> - ofwbus receives the OFW_BUS_MAP_INTR() call, allocates a blank >>> disconnected IRQ from the MD interrupt layer, and stores the mapping >>> from the new IRQ to the given interrupt specifier and phandle in an >>> internal table in ofwbus's softc. >>> NB: Nothing else happens here, like post-r301453. Changing this does >>> not change any semantics of the API pre-r301453, which means it >>> remains fully compatible with PCI and PowerPC. Also, like >>> post-r301453, there is no involvement of nexus. >>> - PICs attach and call OFW_BUS_REGISTER_PIC(). ofwbus receives these >>> messages and adds a (device_t, phandle_t) mapping to a second internal >>> table. Note that the interrupt layer does not need to handle PIC >>> registration anymore at all (except for the root PIC). >>> - Bus child eventually calls a function that tries to set the >>> interrupt up (e.g. bus_setup_intr()). That propagates up the bus >>> hierarchy, eventually getting to ofwbus. ofwbus notes the IRQ number, >>> looks it up in the table, looks up the appropriate PIC from the PIC >>> table, then: >>> A) calls arm_set_pic_for_irq(irq, pic_device_t) -- this is the >>> interrupt layer's only interaction with the mapping code. All it deals >>> with is device_ts and abstract IRQ numbers. >>> B) calls PIC_MAP_OFW_INTR(pic, irq_number, interrupt-cells, >>> interrupt-specifier) to tell the PIC that the interrupt layer's IRQ >>> irq_number means the given specifier >>> C) finally, passes the call onto nexus, which will do whatever would >>> normally happen (unmasking the interrupt, setting handlers, etc.) in >>> terms only of the abstract IRQ and the device_t assigned by ofwbus. >>> >>> You would implement ACPI just by doing a s/OFW/ACPI/g >>> search-and-replace above -- since the interrupt layer doesn't know >>> about OFW or ACPI or anything else, there is no need to touch it. This >>> seems clean, simple, compartmentalized, preserves the existing API, >>> and should work on all of our various hardware. PowerPC can't quite >>> work with it yet without some multipass foo, but, since the API is >>> preserved, that transition can happen gradually without KPI changes. >>> For the same reason that it is API-preserving, I think this code is >>> also MFC-able. >>> -Nathan >> I think that we are slightly diverges in this place: >> - please note that PIC API (in kern/pic_if.m) is different from the >> one >> that PPC uses. > > Yes, which is fine (this is machine-dependent code anyway). On > consideration, the PIC_MAP_OFW_INTR() function should probably be > called OFW_BUS_PIC_MAP_INTR() and live in ofw_bus_if.m anyway, then be > implemented by PICs. > >> - we must be able to store configuration data (original interrupt >> specifier) in all cases, not only for OFW. That's reason why I have >> proposed >> to create 'mapping table'. > > It is stored in all cases, just not in the core interrupt code. I've > only mocked this up for OFW here. For ACPI, you would have the > equivalent table in acpi.c, along with ACPI_MAP_INTR(), > ACPI_REGISTER_PIC(), etc. in acpi_if.m and implemented in > dev/acpica/acpi.c. > > For GPIOs, you would have a mechanism that just traces however you are > representing GPIOs anyway. > >> Anyway, i think that we both talking about +/- same solution, only i >> want to move it from OFW specific level implemented at OFW bus level to >> bus/interrupt specifier format independent level implemented in >> subr_intr.c. > > This implements the same API in any case (identical to that > pre-r301453), so the implementation doesn't really matter at all in > terms of my needs. Perfect. > > That said, having it in the root bus for the mapping domain (ofwbus0, > acpi0) etc. seems cleaner to me, with no loss of functionality. The > core interrupt code (subr_intr.c or whatever) doesn't have any obvious > need to know anything at all about the mapping information so long as > it knows the PIC device_t that corresponds to every abstract IRQ so > that it can mask it or do other operations. Since, presumably, nothing > in an ACPI device tree references an interrupt in the OFW device tree > (if you even had both -- and how would you specify that, anyway?), > implementing the relevant bits one step up the bus hierarchy doesn't > change any behavior. > > And nothing can possibly be more flexible in terms of the mapping > table in subr_intr.c than not having a mapping table: you don't need > enums for mapping types, or unions that need to be expanded, breaking > KBI, or anything. You can delete all the PIC registration (and MSI) > code, all the switches, and all the unions from subr_intr.c and have a > totally mapping-mechanism-agnostic KPI. > Where you see "all the switches, and all the unions" in subr_intr.c? subr_intr.c uses nested structures approach, in exactly same way as is used in OFW bus. Moreover, subr_intr.c *IS* currently totally mapping-mechanism-agnostic KPI, and any form of mapping table must follow this rule. But allow me to make short summary: - we must support 3 'main' cases - OFW, ACPI and HINTS (for older arm and mips boards) based systems - single kernel must support all above cases, but only one can by 'active' (kernel must be able to select right one at runtime). - we must support 'direct' (interrupt specifier is defined by one of above methods) or 'indirect' (where interrupt is associated with other function - GPIO pin, but don't have direct description). - we must be able to access single physical pin by both methods, 'direct' and/or 'indirect'. - we must be able to add new interrupt type as simple as possible For interrupt controllers: - single controller must be able to parse multiple formats. 'direct' or 'indirect'. OFW or ACPI. ARM GIC must accept OFW or ACPI arguments (in single kernel), GPIO based interrupt controller must accept 'direct' or 'indirect' formats. For interrupt consumers: - 'direct' interrupts are easy - driver must be able to consume 'indirect' interrupt in 'root bus'/'mapping-mechanism' agnostic manner. For example, MMC driver must be able to get interrupt from CD gpio pin in all possible cases/combinations . Are we still connected? I don't think that all this is possible without single universal format of interrupt mapping specifier. And, if we must have universal format then why we needs different mapping databases? >> Most of your control flow can be implemented at general level as is, or >> already exist [intr_map_irq(), intr_pic_register()] . >> Also, impact for current PPC code is, by me, minimal. >> I can sketch my idea in more details, if you found it acceptable. > > All ideas are fine -- and the solution does not need to apply to all > platforms anyway, so long as the OFW_BUS_MAP_INTR() semantics (and, > ideally, API) are preserved. > >> Again, I'm sorry for delayed and very brief response. > > No worries; good luck with the work emergencies. > -Nathan All problems have been solved, sleep deficit remains :) Michal From owner-freebsd-arm@freebsd.org Thu Aug 4 12:14:17 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8B40BAF4B8 for ; Thu, 4 Aug 2016 12:14:17 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 619F21943 for ; Thu, 4 Aug 2016 12:14:17 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 8A8961A1C4C for ; Thu, 4 Aug 2016 07:07:39 -0500 (CDT) Subject: Re: U-boot issues on Banana Pi M2 To: freebsd-arm@freebsd.org References: <0403B533-40BC-4674-84CC-2CC3F732B45E@rcn.com> From: Karl Denninger Message-ID: <4f88ae8c-a7a0-edd7-1300-8b621318733e@denninger.net> Date: Thu, 4 Aug 2016 07:07:38 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080208050800080600000503" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 12:14:17 -0000 This is a cryptographically signed message in MIME format. --------------ms080208050800080600000503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/3/2016 21:44, Erik Moe wrote: > I=E2=80=99m not sure which one resolved the issue, *but by checking out= the latest sources and applying the freebsd > patches I was able to get my BPI M2 to boot:* That appears significant as there was a discussion about this (in relationship to USB keyboards) and the view was that the most-current u-boot sources were broken in another area (an API issue) that made them unusable. It would be extremely useful generally to roll u-boot forward if it is indeed functional as the usb keyboard capability during boot time is quite useful if you have a monitor connected (as opposed to a serial terminal) and something goes wrong during the boot process. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080208050800080600000503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MDQxMjA3MzhaME8GCSqGSIb3DQEJBDFCBEAo btvgu4Wi9KG3OrXLeVS5N/JWiuPV6U1l5JVwwAyV7cd0DAmVdLcDAJhrpMBSm8z4pM5EGgw8 N0lBKGieEXlOMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIASxn1HD8C 3i02WdbfNuLu4F64sZZrK9mi7sjtZf/QTlc1RNDv3VkiHq9pbkAvJAfl0K6TUWRYx1AqKJHc DCFqgeW+/JiGsv3D8wEhXgftPmkHX3Hfx755lfCf1xCTVH7UKnWOWMFDKdz1TGxEMJoyRFHS uRaqu6DEzqcfmGP7yzQk9Ma17jdxYnvsH1ZbfML12yCmo7dWQaqUQqRNHWzDRu19BlDss+gP 04JzxPy61jF2Stz8akw5+TzwQB4AvqgrBI3jYYhtRwARTvAmpgNs54b0VpVSeriWxeoHWnAh vKt+7kYk3+xl+JJlULJ2hmpQ8raASSD+Y89FtyRRNFTZCEmI83PX05rTGHsYkeiUa56MJb/Q wJQabmAmhf8IrglBnNnRmZUgsb9vOF7RxBJ+VgQ6oKWX4X2+pk7KzYzm3nntmkzB/EDI7qDk OVWqyBkt8tf4/8yTGhX2FyMa8gYqt/vu2l89f4AZ//5+9/S5jMZRXd9A7MABO2ldstiDSlli sBoTyv9Iur5wV1x6YW3OES8aEopgXW3lCKnnCMT6Raro0w3pzvUzFUehCxaSXyXXFjE/r0Ch ApNB2p+pt9qdIm9iEiR+OAbBnAJThdTYtatqJsaUKctxsAyByVA0RskZl/iBKE+PBLMRzY1e G+T5Uj3tx3y82qa6GyRzSrvLLVkAAAAAAAA= --------------ms080208050800080600000503-- From owner-freebsd-arm@freebsd.org Thu Aug 4 12:35:07 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6338BAF85D; Thu, 4 Aug 2016 12:35:07 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B814C13D1; Thu, 4 Aug 2016 12:35:07 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net ([172.56.13.252]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u74CYowF011910 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Aug 2016 05:34:56 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> <57A09F34.4050400@FreeBSD.org> <57A30B72.7070809@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> Date: Thu, 4 Aug 2016 05:34:50 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57A30B72.7070809@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------3EFCE033AD3743BB7374BC07" X-Sonic-CAuth: UmFuZG9tSVYTMvib3iK8t8OtonMY5p5XZ9h+jydHp6pTgJjTe9flGBKGidKY6bMTMv300NtwZ45DQAPm4TnMP/b9QGcG10/7b/Nr44LYeWI= X-Sonic-ID: C;PLZz1j9a5hGCN6/hcgQksw== M;/rHB2T9a5hGCN6/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 12:35:07 -0000 This is a multi-part message in MIME format. --------------3EFCE033AD3743BB7374BC07 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 08/04/16 02:31, Michal Meloun wrote: > Dne 02.08.2016 v 17:31 Nathan Whitehorn napsal(a): >> >> On 08/02/16 06:25, Michal Meloun wrote: >>> I'm sorry for delayed response. We have serious trouble @work so I >>> cannot spend to much time on FreeBSB for next 2 or 3 days. >> Understood. >> >>> Dne 02.08.2016 v 6:00 Nathan Whitehorn napsal(a): >>>> On 07/31/16 11:43, Nathan Whitehorn wrote: >>>>> On 07/31/16 08:40, Michal Meloun wrote: >>>>>> Dne 31.07.2016 v 8:11 Nathan Whitehorn napsal(a): >>>>>> [snip] >>>>>>>> The current API is certainly a bit of a hack and I would be >>>>>>>> pleased to >>>>>>>>> see it go; but the replacement needs to be more functional and >>>>>>>>> more >>>>>>>>> robust. As far as I can tell, I literally *cannot* move PowerPC >>>>>>>>> over >>>>>>>>> to this architecture. >>>>>>>> Yes, at this time, I agree. If you can accept enhancement of >>>>>>>> (owf_)bus_map_intr() then we can move to next, significantly less >>>>>>>> hackish, state. >>>>>>> OK, sure. I wrote some code this afternoon (attached) to sketch >>>>>>> this. >>>>>>> It does not compile or run or anything useful, but it should >>>>>>> illustrate the important parts of what I think is an API that should >>>>>>> work for everyone. I'm happy to finish it if it looks reasonable >>>>>>> -- I >>>>>>> may in any case just to replace PowerPC's increasingly teetering >>>>>>> intr_machdep.c. >>>>>>> >>>>>>> The OF part is essentially unchanged from how it currently works: >>>>>>> there's a method that you pass the interrupt specifier and interrupt >>>>>>> parent to, and it spits back an IRQ that means that combination of >>>>>>> things in perpetuity. OFW_BUS_MAP_INTR() in nexus.c, with its >>>>>>> current >>>>>>> API, can be implemented in terms of it in one line. Whenever the >>>>>>> relevant PIC attaches, it is told to use the given IRQ to refer to >>>>>>> that opaque bytestring. >>>>>>> >>>>>>> I've added a set of equivalent functions for ACPI that take the >>>>>>> contents of an ACPI interrupt specifier and do the same things. It >>>>>>> tries to have the IRQ be human-meaningful, if possible, by matching >>>>>>> the ACPI interrupt number. Having separate functions seemed a little >>>>>>> cleaner than exposing the enums and unions as part of the KPI, >>>>>>> but I'm >>>>>>> not wedded to it -- this is just an example. >>>>>>> >>>>>>> PICs register (and deregister) themselves with either an OF >>>>>>> phandle or >>>>>>> an ACPI resource string or (god help us) both as needed. The PICs >>>>>>> have >>>>>>> corresponding methods for interpreting various kinds of interrupt >>>>>>> specifiers. >>>>>>> >>>>>>> Whether it allows bus_alloc_resource(), bus_setup_intr(), etc. to >>>>>>> succeed before the PICs are attached is gated on an #ifdef. That can >>>>>>> probably be off by default on ARM. A PowerPC version of this code >>>>>>> would have to keep it on until various bus drivers are fixed. >>>>>>> >>>>>>> Here's the general flow: >>>>>>> - Parent bus enumerates children, maps IRQs as needed, adds to >>>>>>> resource list. The struct resources involved aren't special (just a >>>>>>> single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are trivial to >>>>>>> implement (and already are implemented, in general, for OF/FDT >>>>>>> drivers). >>>>>>> - bus_alloc_resource() does nothing special >>>>>>> - bus_setup_intr() calls into the PIC and does what is needed, as in >>>>>>> r301453 (to within that #ifdef) >>>>>>> >>>>>>> This should keep all the best pieces of everything: >>>>>>> - ACPI and OF are supported together, and easy to extend for other >>>>>>> types of mapping technologies without breaking either KBI or KPI >>>>>>> (just >>>>>>> add new functions) >>>>>>> - No APIs change for existing Open Firmware code >>>>>>> - The support code can live entirely in machine-dependent >>>>>>> directories, >>>>>>> with no code changes at all required in kern/ or dev/ofw/ >>>>>>> - bus_setup_intr() and friends behave as in r301453 and succeed or >>>>>>> fail for real >>>>>>> - PCI code is not an issue >>>>>>> - No disconnected interrupt state maintained in mapping table >>>>>>> (unless >>>>>>> the transitional #ifdef is on) and the mapping table content is only >>>>>>> larger than r301453 by having a copy of the original interrupt >>>>>>> specifier. >>>>>>> >>>>>>> If and when we manage to fix the kernel APIs to allow non-scalar >>>>>>> interrupt specifiers, this should also be easy to gradually >>>>>>> transmogrify to support that case since there exists a 1:1 >>>>>>> mapping of >>>>>>> scalar IRQs to rich data and the control flow would be identical: >>>>>>> interrupt specifiers are read at enumeration time and a resulting >>>>>>> handle -- struct resource or scalar IRQ -- used afterward to refer >>>>>>> to it. >>>>>>> >>>>>> Nice, nice, i think that we are very close at this point. >>>>>> The problem with the above workflow is that maps IRQ function is >>>>>> called >>>>>> at parent bus enumeration time, generally at BUS_PASS_BUS pass. >>>>>> And at >>>>>> this time, PICs are not exist. >>>>>> Also, 'static struct intr_irqsrc *irq_sources[NIRQ];' is not a >>>>>> mapping >>>>>> table, it doesn't provide this functionality. >>>>>> But yes, i understand that mapping table is important and necessary >>>>>> for you. >>>>>> >>>>>> So, if i can extend our concept a little bit, then: >>>>>> We can add new table (map_data_tbl for example) that holds a >>>>>> copy of >>>>>> the original interrupt specifier, index to irq_sources table and >>>>>> probably some flags. >>>>>> And we can modify the above workflow to: >>>>>> - Parent bus enumerates children, allocates entries from >>>>>> map_data_tbl, >>>>>> adds to resource list. The struct resources involved aren't special >>>>>> (just a single number), so PCIB_ROUTE_INTERRUPT(), MSIs, etc. are >>>>>> trivial to implement (and already are implemented, in general, for >>>>>> OF/FDT drivers). Index to map_data_tbl is used as resource ID. >>>>>> - bus_alloc_resource() sets 'ALLOCATED' in map_data_tbl flags field, >>>>>> *maps IRQs* and stores result in 'index' field. >>>>>> - bus_setup_intr() sets 'SETUP_DONE' in map_data_tbl flags field, >>>>>> calls >>>>>> into the PIC and does what is needed, as in r301453. (to within that >>>>>> #ifdef) >>>>>> >>>>>> And, in PPC case, newly attached PIC scans whole map_data_tbl table, >>>>>> finds his entries and makes what needs. >>>>>> >>>>>> Does that make sense? >>>>>> I hope that postponing of map IRQ call is not a problem for PPC, >>>>>> everything else looks easy. >>>>>> Moreover, this additional level of indirection also solves all my >>>>>> 'hypothetical corner cases' with N:1 mappings (between original >>>>>> interrupt specifier and real interrupt number). >>>>> Yes, I think we are converging. >>>>> >>>>> My qualm about bus_alloc_resource() is twofold: >>>>> 1. Traditionally, with interrupts, bus_alloc_resource() has no side >>>>> effects and I'm not sure it propagates cleanly down the tree in all >>>>> cases. >>>>> 2. There are a few bus APIs (bus_config_intr() comes to mind) that >>>>> use raw IRQ IDs and, so far as I know, can be, and sometimes are >>>>> called before bus_alloc_resource(). If the PIC doesn't know about the >>>>> IRQ yet when bus_config_intr() (etc.) is called, things will just >>>>> break. >>>>> >>>>> So you would need to make sure that any bus method handling a >>>>> resource ID causes it to be mapped on the PIC at that time. It's OK >>>>> if that happens in bus_alloc_resource() so long as bus_config_intr(), >>>>> bus_setup_intr(), etc. cause that to happen if it hasn't happened yet >>>>> -- I don't care when these calls are made to the PIC driver so long >>>>> as *what* calls will be made is set at enumeration time. >>>>> >>>>> I am also totally fine with having, on ARM, bus_config_intr(), >>>>> bus_setup_intr() etc. fail if the PIC hasn't attached yet (On >>>>> PowerPC, we can't do that yet, but after this conversation, I regard >>>>> that as a bug and would fix that later), as well as delaying setup on >>>>> the PIC to the first time any bus driver actually tries to *use* the >>>>> interrupt (alloc_resource(), setup_intr(), config_intr(), whatever) >>>>> rather than when the interrupt is originally allocated. >>>>> >>> I understand. And yes, bus_alloc_resource() isn't propagated cleanly >>> down the tree in all cases. That's why we have 'INTRNG' hook in >>> subr_bus.c, which is suboptimal. >>> >>> About bus_config_intr(). The only consumer of bus_config_intr() is ACPI >>> code, in little hackish manner, as workaround for problem which is >>> fully solved by INTRNG. >>> Also, the semantic of bus_config_intr() is not clear, from INTRNG point >>> of view. >>> So i have tendency to ignore it :) >> Heh. Fair enough. I hadn't noticed that -- though I can see legitimate >> uses for it in the context of GPIOs. In any case, I'm a little wary of >> bus_alloc_resource() having side effects. Usually >> bus_activate_resource() would do that kind of thing. > Yes, good catch!! bus_activate_resource() is definitively best method. > >>>>> ------------ The following is a large parenthesis ------------------- >>>>> >>>>> One other possible route here that would also work well would be to >>>>> make ofwbus.c MD (it's a trivial piece of code anyway, so we don't >>>>> gain a lot by sharing it) and implement ofw_bus_map_intr() locally as >>>>> an ofwbus bus method. Then you could have the mapping table stored in >>>>> ofwbus's softc -- the API was designed for this initially. You would >>>>> need MD extensions for doing PIC registration there (which is fine), >>>>> but that segregates all the OFW-specific information into >>>>> OFW-specific code and would let the bus methods and the OFW interrupt >>>>> mapping table interact cleanly in the same place. This still >>>>> preserves the pre-r301453 API, makes PowerPC work, and maybe >>>>> address's skra@'s concern about extensibility and letting core >>>>> interrupt code know about FDT (or ACPI). I'd be happy to mock this up >>>>> as well if you think it's a good approach. >>>>> >>>> [snip] >>>>> This has the following features: >>>>> - Existing OFW API and semantics unchanged >>>>> - As such, PowerPC, PCI, etc. work fine with no changes >>>>> - Details encapsulated in MD code, so individual platforms can >>>>> implement this however they like >>>>> - arm/arm/intr.c (or whatever) only needs a method to allocate a >>>>> fresh interrupt, with no state, and anoter to set the device_t for an >>>>> interrupt sometime later. >>>>> - The internal table in the platform interrupt code has no knowledge >>>>> of any mappings whatsoever except having the appropriate device_t for >>>>> the PIC stored with the interrupt vector. >>>>> - Device tree bits handled purely in device tree code >>>>> - No action need be taken on any mapping until the interrupt is >>>>> actually allocated/set up, like r301453 >>>>> - Easy to add more mapping mechanisms (e.g. ACPI) by having similar >>>>> enumeration-mechanism-specific code in the root bus for that mapping >>>>> mechanism. >>>>> >>>>> -------------- End parenthesis ------------------------------- >>>> Here's an implementation of the parenthesis I wrote on an airplane >>>> this afternoon. It should be complete, though has not been tested. The >>>> code is short and simple (+70 lines in ofwbus.c). This preserves the >>>> pre-r301453 API and semantics relative to drivers, which means PowerPC >>>> and PCI work out of the box, while keeping the semantics relative to >>>> the interrupt layer of r301453 (PIC methods only called on resource >>>> allocation, no allocatable IRQs on unattached PICs, encapsulation of >>>> OFW-specific code in OFW-specific bits of the tree). It turns out >>>> those two things are compatible, somewhat to my surprise, and that >>>> makes the result very clean. I like this approach and would be happy >>>> to move forward with it. There are five functions of interest: >>>> >>>> 1. OFW_BUS_MAP_INTR(). This has the semantics and API it has now: you >>>> pass an interrupt specifier and parent, you get back an IRQ. No >>>> changes. This is the core of the normal OFW interrupt API. >>>> >>>> 2. OFW_BUS_REGISTER_PIC(device_t pic, phandle_t phandle). This is a >>>> new function that PIC drivers are supposed to use to register control >>>> of an interrupt domain. This replaces machine-specific code like >>>> powerpc_register_pic() to allow the PIC table to be in a bus parent >>>> rather than in the interrupt core. >>>> >>>> 3. PIC_MAP_OFW_INTR(device_t pic, int irq, interrupt specifier). This >>>> is a new function that PIC drivers that know how to handle device-tree >>>> interrupt descriptors implement (analogous to various existing ones >>>> that vary by platform). It tells the PIC that the given abstract IRQ >>>> means the given opaque interrupt specifier. >>>> >>>> 4. arm_allocate_irq(int suggested). This allocates a new IRQ number >>>> not (yet) attached to a PIC, as in r301453. I've added a parameter >>>> that lets you pass a suggested number to try in case it is possible to >>>> make it match an interrupt pin or something for human-readability. >>>> >>>> 5. arm_set_pic_for_irq(int irq, device_t). This tells the MD interrupt >>>> layer to associate a given PIC device_t with an IRQ. That is all the >>>> information the MD layer ever has about the IRQ mapping. >>>> >>>> Functions #1 and #2 are now implemented completely in ofwbus.c: there >>>> are no callouts anywhere else and the interrupt mapping table is >>>> maintained entirely internally to ofwbus (in its softc). In order to >>>> implement ACPI, or some other strategy, you would implement analogs to >>>> functions #1 and #2 that live somewhere in the bus hierarchy that is >>>> guaranteed to be above all devices that might want that type of >>>> interrupt (e.g. in acpi0), and some analog to #3 that PIC drivers >>>> implementing the mapping scheme would provide. >>>> >>>> Since the system interrupt code has no knowledge at all of interrupt >>>> mapping, of any type, in this scheme, adding new mapping types is >>>> trivial and can be done on a driver-by-driver basis if necessary >>>> without changing KPI and without any other part of the system even >>>> being aware. For example, GPIOs can use a completely different >>>> mechanism if they want and can do setup purely in the GPIO controller >>>> driver. You could have a method GPIO_GET_INTERRUPT_FOR_PIN() on a GPIO >>>> controller in which the GPIO controller allocates a generic IRQ, >>>> assigns through some internal table just in the GPIO driver, and >>>> returns to it to a consumer in some other device driver -- without a >>>> GPIO mapping type, new bus functions, or modifications to the platform >>>> interrupt code. >>>> >>>> The control flow goes like this: >>>> - Bus driver enumerates children, parses interrupts properties, calls >>>> OFW_BUS_MAP_INTR() to get IRQs for them (as pre-r301453), adds to >>>> interrupt list. >>>> - ofwbus receives the OFW_BUS_MAP_INTR() call, allocates a blank >>>> disconnected IRQ from the MD interrupt layer, and stores the mapping >>>> from the new IRQ to the given interrupt specifier and phandle in an >>>> internal table in ofwbus's softc. >>>> NB: Nothing else happens here, like post-r301453. Changing this does >>>> not change any semantics of the API pre-r301453, which means it >>>> remains fully compatible with PCI and PowerPC. Also, like >>>> post-r301453, there is no involvement of nexus. >>>> - PICs attach and call OFW_BUS_REGISTER_PIC(). ofwbus receives these >>>> messages and adds a (device_t, phandle_t) mapping to a second internal >>>> table. Note that the interrupt layer does not need to handle PIC >>>> registration anymore at all (except for the root PIC). >>>> - Bus child eventually calls a function that tries to set the >>>> interrupt up (e.g. bus_setup_intr()). That propagates up the bus >>>> hierarchy, eventually getting to ofwbus. ofwbus notes the IRQ number, >>>> looks it up in the table, looks up the appropriate PIC from the PIC >>>> table, then: >>>> A) calls arm_set_pic_for_irq(irq, pic_device_t) -- this is the >>>> interrupt layer's only interaction with the mapping code. All it deals >>>> with is device_ts and abstract IRQ numbers. >>>> B) calls PIC_MAP_OFW_INTR(pic, irq_number, interrupt-cells, >>>> interrupt-specifier) to tell the PIC that the interrupt layer's IRQ >>>> irq_number means the given specifier >>>> C) finally, passes the call onto nexus, which will do whatever would >>>> normally happen (unmasking the interrupt, setting handlers, etc.) in >>>> terms only of the abstract IRQ and the device_t assigned by ofwbus. >>>> >>>> You would implement ACPI just by doing a s/OFW/ACPI/g >>>> search-and-replace above -- since the interrupt layer doesn't know >>>> about OFW or ACPI or anything else, there is no need to touch it. This >>>> seems clean, simple, compartmentalized, preserves the existing API, >>>> and should work on all of our various hardware. PowerPC can't quite >>>> work with it yet without some multipass foo, but, since the API is >>>> preserved, that transition can happen gradually without KPI changes. >>>> For the same reason that it is API-preserving, I think this code is >>>> also MFC-able. >>>> -Nathan >>> I think that we are slightly diverges in this place: >>> - please note that PIC API (in kern/pic_if.m) is different from the >>> one >>> that PPC uses. >> Yes, which is fine (this is machine-dependent code anyway). On >> consideration, the PIC_MAP_OFW_INTR() function should probably be >> called OFW_BUS_PIC_MAP_INTR() and live in ofw_bus_if.m anyway, then be >> implemented by PICs. >> >>> - we must be able to store configuration data (original interrupt >>> specifier) in all cases, not only for OFW. That's reason why I have >>> proposed >>> to create 'mapping table'. >> It is stored in all cases, just not in the core interrupt code. I've >> only mocked this up for OFW here. For ACPI, you would have the >> equivalent table in acpi.c, along with ACPI_MAP_INTR(), >> ACPI_REGISTER_PIC(), etc. in acpi_if.m and implemented in >> dev/acpica/acpi.c. >> >> For GPIOs, you would have a mechanism that just traces however you are >> representing GPIOs anyway. >> >>> Anyway, i think that we both talking about +/- same solution, only i >>> want to move it from OFW specific level implemented at OFW bus level to >>> bus/interrupt specifier format independent level implemented in >>> subr_intr.c. >> This implements the same API in any case (identical to that >> pre-r301453), so the implementation doesn't really matter at all in >> terms of my needs. > Perfect. >> That said, having it in the root bus for the mapping domain (ofwbus0, >> acpi0) etc. seems cleaner to me, with no loss of functionality. The >> core interrupt code (subr_intr.c or whatever) doesn't have any obvious >> need to know anything at all about the mapping information so long as >> it knows the PIC device_t that corresponds to every abstract IRQ so >> that it can mask it or do other operations. Since, presumably, nothing >> in an ACPI device tree references an interrupt in the OFW device tree >> (if you even had both -- and how would you specify that, anyway?), >> implementing the relevant bits one step up the bus hierarchy doesn't >> change any behavior. >> >> And nothing can possibly be more flexible in terms of the mapping >> table in subr_intr.c than not having a mapping table: you don't need >> enums for mapping types, or unions that need to be expanded, breaking >> KBI, or anything. You can delete all the PIC registration (and MSI) >> code, all the switches, and all the unions from subr_intr.c and have a >> totally mapping-mechanism-agnostic KPI. >> > Where you see "all the switches, and all the unions" in subr_intr.c? > subr_intr.c uses nested structures approach, in exactly same way as is > used in OFW bus. Moreover, subr_intr.c *IS* currently totally > mapping-mechanism-agnostic KPI, and any form of mapping table must > follow this rule. That was hyperbolic; my apologies. The point was that you don't need intr_map_data, or the intr_map_data_type enum, this way. One of the nice things about that is that you don't need to add more entries to the enum to add new one-off mapping types. For example, the PS3 platform on PPC has its own non-device-tree, non-ACPI bus description and interrupt system. Needing to make new enums (or anything) like INTR_MAP_DATA_PS3 in sys/bus.h seems a little silly, though hardly very bad. I've attached a version of PowerPC's intr_machdep.c and pic_if.m that fully implements this distributed-table scheme. The code ends up being very short and clean (a third the number of lines of code as kern/subr_intr.c, for example) and the diff to PowerPC, including the new ofwbus.c code, ends up being net-negative. > But allow me to make short summary: > - we must support 3 'main' cases - OFW, ACPI and HINTS (for older arm > and mips boards) based systems > - single kernel must support all above cases, but only one can by > 'active' (kernel must be able to select right one at runtime). > - we must support 'direct' (interrupt specifier is defined by one of > above methods) or 'indirect' (where interrupt is associated with other > function - GPIO pin, but don't have direct description). > - we must be able to access single physical pin by both methods, > 'direct' and/or 'indirect'. > - we must be able to add new interrupt type as simple as possible Agreed with all of this. > > For interrupt controllers: > - single controller must be able to parse multiple formats. 'direct' or > 'indirect'. OFW or ACPI. ARM GIC must accept OFW or ACPI arguments (in > single kernel), GPIO based interrupt controller must accept 'direct' or > 'indirect' formats. > > For interrupt consumers: > - 'direct' interrupts are easy > - driver must be able to consume 'indirect' interrupt in 'root > bus'/'mapping-mechanism' agnostic manner. > For example, MMC driver must be able to get interrupt from CD gpio > pin in all possible cases/combinations . > Are we still connected? And this. > I don't think that all this is possible without single universal format > of interrupt mapping specifier. > And, if we must have universal format then why we needs different > mapping databases? It actually works just fine in this mapping-table-in-the-root-bus model. If you have an OFW-type of interrupt, it is set up by ofwbus.c. Since everything that would use an OFW interrupt is a child of ofwbus, this is totally indistinguishable from a global table from the perspective of client code. For ACPI interrupts, they are set up by acpi.c, which is indistinguishable from a global table for the same reason. For hints -- and single-domain systems generally -- you can just have the machine-dependent code assume that interrupts it doesn't explicitly know about belong to the root PIC. This is what you call the "direct" case. For the "indirect" case, there are as usual a few things you could do. They match the set of things you would do in any implementation: 1. Set up one or more global registries for "indirect" PICs, with corresponding mapping methods, either as bus methods on some high-level bus or on the machine-specific nexus, or just a global function that you call. 2. Use the global registry that you already have to have for GPIO controllers and provide a mapping method on the GPIO controller (GPIO_GET_INTERRUPT_FOR_PIN() or something) that returns a mapped IRQ. One of the nice things about distributing the tables this way is that you have lots of flexibility with things like these "indirect" interrupts and are free to do things like #2 at will locally in some machine-specific set of drivers. For example, in the PS3 code, I don't need to add a new "PS3" mapping type *anywhere*. The ps3bus root driver just has a table when it hands out interrupts and talks to ps3pic internally. -Nathan >>> Most of your control flow can be implemented at general level as is, or >>> already exist [intr_map_irq(), intr_pic_register()] . >>> Also, impact for current PPC code is, by me, minimal. >>> I can sketch my idea in more details, if you found it acceptable. >> All ideas are fine -- and the solution does not need to apply to all >> platforms anyway, so long as the OFW_BUS_MAP_INTR() semantics (and, >> ideally, API) are preserved. >> >>> Again, I'm sorry for delayed and very brief response. >> No worries; good luck with the work emergencies. >> -Nathan > All problems have been solved, sleep deficit remains :) > Michal > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > --------------3EFCE033AD3743BB7374BC07 Content-Type: text/plain; charset=UTF-8; name="intr_machdep.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="intr_machdep.c" /*- * Copyright (c) 1991 The Regents of the University of California. * All rights reserved. * * This code is derived from software contributed to Berkeley by * William Jolitz. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ /*- * Copyright (c) 2002 Benno Rice. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * from: @(#)isa.c 7.2 (Berkeley) 5/13/91 * form: src/sys/i386/isa/intr_machdep.c,v 1.57 2001/07/20 * * $FreeBSD: head/sys/powerpc/powerpc/intr_machdep.c 296177 2016-02-29 03:38:00Z jhibbits $ */ #include "opt_isa.h" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "pic_if.h" #define MAX_STRAY_LOG 5 static MALLOC_DEFINE(M_INTR, "intr", "interrupt handler data"); struct powerpc_intr { struct intr_event *event; long *cntp; u_int irq; u_int vector; device_t pic; u_int cntindex; cpuset_t cpu; int ipi; }; static u_int intrcnt_index = 0; static struct mtx intr_table_lock; static struct powerpc_intr *powerpc_intrs[INTR_VECTORS]; static u_int nvectors; /* Allocated vectors */ static u_int nirqs = 0; /* Allocated IRQs. */ static u_int stray_count; u_long intrcnt[INTR_VECTORS]; char intrnames[INTR_VECTORS * MAXCOMLEN]; size_t sintrcnt = sizeof(intrcnt); size_t sintrnames = sizeof(intrnames); device_t root_pic; #ifdef SMP static void *ipi_cookie; #endif static void intr_init(void *dummy __unused) { mtx_init(&intr_table_lock, "intr sources lock", NULL, MTX_DEF); } SYSINIT(intr_init, SI_SUB_INTR, SI_ORDER_FIRST, intr_init, NULL); #ifdef SMP static void smp_intr_init(void *dummy __unused) { struct powerpc_intr *i; int vector; for (vector = 0; vector < nvectors; vector++) { i = powerpc_intrs[vector]; if (i != NULL && i->event != NULL && i->pic == root_pic) PIC_BIND(i->pic, i->irq, i->cpu); } } SYSINIT(smp_intr_init, SI_SUB_SMP, SI_ORDER_ANY, smp_intr_init, NULL); #endif static void intrcnt_setname(const char *name, int index) { snprintf(intrnames + (MAXCOMLEN + 1) * index, MAXCOMLEN + 1, "%-*s", MAXCOMLEN, name); } void intrcnt_add(const char *name, u_long **countp) { int idx; idx = atomic_fetchadd_int(&intrcnt_index, 1); *countp = &intrcnt[idx]; intrcnt_setname(name, idx); } static struct powerpc_intr * intr_lookup(u_int irq); { struct powerpc_intr *i; int vector; mtx_lock(&intr_table_lock); for (vector = 0; vector < nvectors; vector++) { i = powerpc_intrs[vector]; if (i != NULL && i->irq == irq) { mtx_unlock(&intr_table_lock); return (i); } } mtx_unlock(&intr_table_lock); return (NULL); } int powerpc_alloc_intr(int suggested) { char intrname[16]; struct powerpc_intr *i, *iscan; int vector, irq; mtx_lock(&intr_table_lock); if (suggested <= 0) { for (vector = 0; vector < nvectors; vector++) { i = powerpc_intrs[vector]; if (i != NULL && i->irq == suggested) { suggested = 0; break; } } } /* * If no suggestion, or we couldn't provide it, use max(1000, max_irq+1) */ if (suggested <= 0) { irq = 1000; for (vector = 0; vector < nvectors; vector++) { i = powerpc_intrs[vector]; if (i != NULL && i->irq == suggested) irq = max(irq, i->irq + 1); } } i = malloc(sizeof(*i), M_INTR, M_NOWAIT); if (i == NULL) { mtx_unlock(&intr_table_lock); return (NULL); } i->event = NULL; i->cntp = NULL; i->irq = irq; i->pic = NULL; i->vector = -1; i->ipi = 0; #ifdef SMP i->cpu = all_cpus; #else CPU_SETOF(0, &i->cpu); #endif for (vector = 0; vector < INTR_VECTORS; vector++) { iscan = powerpc_intrs[vector]; if (iscan == NULL && i->vector == -1) { i->vector = vector; break; } } if (i->vector != -1) { powerpc_intrs[i->vector] = i; i->cntindex = atomic_fetchadd_int(&intrcnt_index, 1); i->cntp = &intrcnt[i->cntindex]; sprintf(intrname, "irq%u:", i->irq); intrcnt_setname(intrname, i->cntindex); nvectors++; } mtx_unlock(&intr_table_lock); if (i->vector == -1) { free(i, M_INTR); i = NULL; } return (i); } int powerpc_set_pic_for_irq(int irq, device_t pic) { struct powerpc_intr *i; i = irq_lookup(irq); KASSERT(i != NULL, ("%s: NULL IRQ %d", __func__, irq)); i->pic = pic; return (0); } static void powerpc_intr_eoi(void *arg) { struct powerpc_intr *i = arg; PIC_EOI(i->pic, i->irq); } static void powerpc_intr_pre_ithread(void *arg) { struct powerpc_intr *i = arg; PIC_MASK(i->pic, i->irq); PIC_EOI(i->pic, i->irq); } static void powerpc_intr_post_ithread(void *arg) { struct powerpc_intr *i = arg; PIC_UNMASK(i->pic, i->irq); } static int powerpc_assign_intr_cpu(void *arg, int cpu) { #ifdef SMP struct powerpc_intr *i = arg; if (cpu == NOCPU) i->cpu = all_cpus; else CPU_SETOF(cpu, &i->cpu); if (!cold && i->pic != NULL && i->pic == root_pic) PIC_BIND(i->pic, i->irq, i->cpu); return (0); #else return (EOPNOTSUPP); #endif } int powerpc_enable_intr(void) { struct powerpc_intr *i; int error, vector; #ifdef SMP int ipi_irq; #endif if (npics == 0) panic("no PIC detected\n"); if (root_pic == NULL) panic("no root PIC\n"); #ifdef SMP /* Install an IPI handler. */ if (mp_ncpus > 1) { ipi_irq = powerpc_alloc_intr(4096); error = PIC_MAP_IPI(root_pic, ipi_irq); KASSERT(error == 0, ("%s: SMP root PIC failed to map IPI", __func__, error)); error = powerpc_setup_intr("IPI", ipi_irq, powerpc_ipi_handler, NULL, NULL, INTR_TYPE_MISC | INTR_EXCL, &ipi_cookie); if (error) { printf("unable to setup IPI handler\n"); return (error); } /* * Some subterfuge: disable late EOI and mark this * as an IPI to the dispatch layer. */ i = intr_lookup(ipi_irq, FALSE); i->event->ie_post_filter = NULL; i->ipi = 1; } #endif for (vector = 0; vector < nvectors; vector++) { i = powerpc_intrs[vector]; if (i == NULL) continue; if (i->pic == NULL) continue; if (i->event != NULL) PIC_ENABLE(i->pic, i->irq, vector); } return (0); } int powerpc_setup_intr(const char *name, u_int irq, driver_filter_t filter, driver_intr_t handler, void *arg, enum intr_type flags, void **cookiep) { struct powerpc_intr *i; int error, enable = 0; i = intr_lookup(irq, FALSE); if (i == NULL) return (ENOMEM); if (i->event == NULL) { error = intr_event_create(&i->event, (void *)i, 0, irq, powerpc_intr_pre_ithread, powerpc_intr_post_ithread, powerpc_intr_eoi, powerpc_assign_intr_cpu, "irq%u:", irq); if (error) return (error); enable = 1; } error = intr_event_add_handler(i->event, name, filter, handler, arg, intr_priority(flags), flags, cookiep); mtx_lock(&intr_table_lock); intrcnt_setname(i->event->ie_fullname, i->cntindex); mtx_unlock(&intr_table_lock); if (!cold && i->pic != NULL) if (i->pic == root_pic) PIC_BIND(i->pic, i->irq, i->cpu); if (enable) PIC_ENABLE(i->pic, i->irq, i->vector); } return (error); } int powerpc_teardown_intr(void *cookie) { return (intr_event_remove_handler(cookie)); } #ifdef SMP int powerpc_bind_intr(u_int irq, u_char cpu) { struct powerpc_intr *i; i = intr_lookup(irq); if (i == NULL) return (ENOMEM); return (intr_event_bind(i->event, cpu)); } #endif int powerpc_config_intr(int irq, enum intr_trigger trig, enum intr_polarity pol) { struct powerpc_intr *i; i = intr_lookup(irq); if (i == NULL) return (ENOMEM); i->trig = trig; i->pol = pol; if (i->pic != NULL) PIC_CONFIG(i->pic, i->irq, trig, pol); return (0); } void powerpc_dispatch_intr(u_int vector, struct trapframe *tf) { struct powerpc_intr *i; struct intr_event *ie; i = powerpc_intrs[vector]; if (i == NULL) goto stray; (*i->cntp)++; ie = i->event; KASSERT(ie != NULL, ("%s: interrupt without an event", __func__)); /* * IPIs are magical and need to be EOI'ed before filtering. * This prevents races in IPI handling. */ if (i->ipi) PIC_EOI(i->pic, i->irq); if (intr_event_handle(ie, tf) != 0) { goto stray; } return; stray: stray_count++; if (stray_count <= MAX_STRAY_LOG) { printf("stray irq %d\n", i ? i->irq : -1); if (stray_count >= MAX_STRAY_LOG) { printf("got %d stray interrupts, not logging anymore\n", MAX_STRAY_LOG); } } if (i != NULL) PIC_MASK(i->pic, i->irq); } void powerpc_intr_mask(u_int irq) { struct powerpc_intr *i; i = intr_lookup(irq); if (i == NULL || i->pic == NULL) return; PIC_MASK(i->pic, i->irq); } void powerpc_intr_unmask(u_int irq) { struct powerpc_intr *i; i = intr_lookup(irq); if (i == NULL || i->pic == NULL) return; PIC_UNMASK(i->pic, i->irq); } --------------3EFCE033AD3743BB7374BC07 Content-Type: text/plain; charset=UTF-8; name="pic_if.m" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pic_if.m" #- # Copyright (c) 1998 Doug Rabson # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # from: src/sys/kern/bus_if.m,v 1.21 2002/04/21 11:16:10 markm Exp # $FreeBSD: head/sys/powerpc/powerpc/pic_if.m 257059 2013-10-24 15:37:32Z nwhitehorn $ # #include #include #include INTERFACE pic; METHOD void bind { device_t dev; u_int irq; cpuset_t cpumask; }; METHOD void config { device_t dev; u_int irq; enum intr_trigger trig; enum intr_polarity pol; }; METHOD void dispatch { device_t dev; struct trapframe *tf; }; METHOD void enable { device_t dev; u_int irq; u_int vector; }; METHOD void eoi { device_t dev; u_int irq; }; METHOD void ipi { device_t dev; u_int cpu; }; METHOD void mask { device_t dev; u_int irq; }; METHOD void unmask { device_t dev; u_int irq; }; METHOD int map_ipi { device_t dev; }; --------------3EFCE033AD3743BB7374BC07-- From owner-freebsd-arm@freebsd.org Thu Aug 4 18:42:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A29CBAED94 for ; Thu, 4 Aug 2016 18:42:33 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18F9617DB for ; Thu, 4 Aug 2016 18:42:32 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id E69592039C8 for ; Thu, 4 Aug 2016 13:42:30 -0500 (CDT) Subject: -HEAD U-Boot *DOES* work on Raspberry PI2 [[WAS Re: U-boot issues on Banana Pi M2]] To: freebsd-arm@freebsd.org References: <0403B533-40BC-4674-84CC-2CC3F732B45E@rcn.com> From: Karl Denninger Message-ID: <551e8983-e529-b3c3-86f5-73d68c4b7fd2@denninger.net> Date: Thu, 4 Aug 2016 13:42:28 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060507060801060700020200" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 18:42:33 -0000 This is a cryptographically signed message in MIME format. --------------ms060507060801060700020200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Heh lookie here: I just checked out the new u-boot code, patched it (manually, since some paths and names internally have changed) with the RPI2 patch set, and....= KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.= FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-BETA1 #0 r302412: Fri Jul 8 14:08:42 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) VT: init without driver. sema_sysinit CPU: Cortex A7 rev 5 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB enabled LABT branch prediction disabled LoUU:2 LoC:3 LoUIS:2 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 2-way instruction cache Read-Alloc Cache level 2: 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory =3D 989851648 (943 MB) avail memory =3D 957444096 (913 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: mem 0x3f000000-0x3fffffff on ofwbus0 local_intc0: mem 0x40000000-0x400000ff on simplebus0 generic_timer0: on ofwbus0 =2E.... It works. But I thought we were told it didn't due to changes in the API component? Note that this version supports a USB keyboard.... I can break into the boot with it; I get a complaint about an interrupt timeout on the console that repeats every few seconds during the time I've done so (once I do so) but it doesn't impact being able to get commands to the system and see the outcome. The only thing I needed to do was hard-code one buffer size to the minimum passed from the realloc call since the variable was undefined.=20 Other than that -- it works. Now about rolling forward our u-boot version..... not sure what has to be done in that regard but the actual patching against HEAD in the u-boot git tree only took me about 15 minutes, and if we DID have a current u-boot we'd have a USB keyboard for the Raspberry Pi2s (at least, and possibly others in the series) all the way through the boot sequence. On 8/3/2016 21:44, Erik Moe wrote: > I spent some time looking into this issue. I believe that the u-boot-b= ananapim2 port is broken because the underlining u-boot code is broken, a= t least for the BPI M2. I built u-boot directly from source trying both = the v2016.07 and v2016.09-rc1 releases and saw the same failure: "Net: = data abort". I built u-boot from HEAD as of 26fb8db since there were a n= umber of commits for sunxi. I=E2=80=99m not sure which one resolved the i= ssue, but by checking out the latest sources and applying the freebsd pat= ches I was able to get my BPI M2 to boot: > > U-Boot SPL 2016.09-rc1-00211-g26fb8db-dirty (Aug 02 2016 - 04:43:10) > DRAM: 1024 MiB > Trying to boot from MMC1 > > > U-Boot 2016.09-rc1-00211-g26fb8db-dirty (Aug 02 2016 - 04:43:10 -0500) = Allwinner Technology > > CPU: Allwinner A31s (SUN6I) > Model: Sinovoip BPI-M2 > DRAM: 1 GiB > WARNING: Caches not enabled > MMC: SUNXI SD/MMC: 0 > reading u-boot.env > > ** Unable to read "u-boot.env" from mmc0:1 ** > Using default environment > > In: serial > Out: serial > Err: serial > Net: eth0: ethernet@01c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 2 USB Device(s) found > Hit any key to stop autoboot: 0 > Booting from: mmc 0 ubldr.bin > reading ubldr.bin > 224660 bytes read in 51 ms (4.2 MiB/s) > ## No elf image at address 0x42000000 > ## Starting application at 0x42000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x7af3f4e8 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@dora, Sat Jul 16 04:11:42 CDT 2016) > > DRAM: 1024MB > MMC Device 1 not found > Number of U-Boot devices: 1 > U-Boot env: loaderdev=3D'mmc 0' > Found U-Boot device: disk > Checking unit=3D0 slice=3D partition=3D... good. > Booting from disk0s2a: > /boot/kernel/kernel data=3D0x65cd64+0x12729c syms=3D[0x4+0x8e630+0x4+0x= a3375] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > /boot/dtb/bananapim2.dtb size=3D0x6151 > Loaded DTB from file 'bananapim2.dtb'. > Kernel entry at 0x42200100... > Kernel args: (null) > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > The Regents of the University of California. All rights reserve= d. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT #0 24eff34(master): Sat Jul 16 04:23:13 CDT 2016 > root@dora:/usr/home/emoe/Projects/ARM/bannapi-m2/obj/arm.armv6/usr/= home/emoe/Projects/ARM/src/sys/ALLWINNER arm > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on L= LVM 3.8.0) > WARNING: WITNESS option enabled, expect reduced performance. > VT: init without driver. > CPU: Cortex A7 rev 3 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB enabled LABT branch prediction disabled > LoUU:2 LoC:3 LoUIS:2 > Cache level 1: > 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 2-way instruction cache Read-Alloc > Cache level 2: > 1024KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > real memory =3D 1073741824 (1024 MB) > avail memory =3D 1035898880 (987 MB) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > aw_ccu0: on ofwbus0 > . > . > . > > Thanks, > Erik > >> On Jul 28, 2016, at 6:49 PM, Erik Moe wrote: >> >> I=E2=80=99m having some issues with the u-boot-bananapim2 in ports. I= t looks like a data abort exception. Does anybody else have a BPI M2 tha= t this port is working for them? If I read this right it=E2=80=99s dying= in the following function: >> >> 4a00218c g F .text 00000038 sunxi_gpio_set_cfgpin >> >> I think someone reported a similar but not the same issue upstream: h= ttp://lists.denx.de/pipermail/u-boot/2016-June/258837.html >> >> Thanks, >> Erik >> >> >> U-Boot SPL 2016.07 (Jul 16 2016 - 02:40:04) >> DRAM: 1024 MiB >> Trying to boot from MMC1 >> >> >> U-Boot 2016.07 (Jul 16 2016 - 02:40:04 -0500) Allwinner Technology >> >> CPU: Allwinner A31s (SUN6I) >> Model: Sinovoip BPI-M2 >> DRAM: 1 GiB >> WARNING: Caches not enabled >> MMC: SUNXI SD/MMC: 0 >> reading u-boot.env >> >> ** Unable to read "u-boot.env" from mmc0:1 ** >> Using default environment >> >> In: serial >> Out: serial >> Err: serial >> Net: data abort >> pc : [<7ef5f180>] lr : [<00000000>] >> reloc pc : [<4a002180>] lr : [] >> sp : 7af35f84 ip : 7efab502 fp : 00000017 >> r10: 7efaaefe r9 : 7af3cee8 r8 : 000040a0 >> r7 : 7ef9ee14 r6 : 00000000 r5 : 00000001 r4 : 00000000 >> r3 : 0000000f r2 : 00000001 r1 : 00000000 r0 : ea00000e >> Flags: nzCv IRQs off FIQs off Mode SVC_32 >> Resetting CPU ... >> >> resetting ... >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060507060801060700020200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MDQxODQyMjhaME8GCSqGSIb3DQEJBDFCBEB3 T89HqjhUS+G3c+QlYWe3oM5ZKCjyV4RBZvv2FMbQ6tNHhqKhhkIDL2bwevOaEYM6VxMht3bg g3dutXyZ/c4TMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAklxFhGk7 YMKy8Yjhr9LTJXeBTSTvyhkEYG0LXv4qgWqzBKcHkSCnkUfOU98jEggLETQskSb1pFKz+c3r OSGPfsvkX6Pl6P6wngEUTvyplJa5jp5OrXdsojVum5bEzwoK6j+rY4mrEszosqwq1d1w4z6O +WKNl4WTcXAFLZVORHGxhACpwbitQFsRfJj9laYnzjizVUwYc1vfHE9ET/5jK4ngBr8vEZds PTVb5tCLhwM5a+9jDPLvHzVSKMMJfj7xb93xvoqNF/LhC5//3UwjykQ0uWysTYBoA0VGBVxR xq/iRbALLU+LQJ0VZqsmJgeTGUrr0JxkmjlgKTSeqzXmudZFc7pMm0uQp3KdiBmDwIXUh531 16C1Ky4h3P/qFFzpYLRIbY13GcOa5qCLAE9q2xP2X2JZ1cEi8MLAqzks7HnSQLm8HrqKxaDf TX+8wL5nrsdgfpSTji21Rn1DAd9pAMbcKcJuRxnRQ71BIPrY2BWVistrFH344JzHAqpr0UdN nobOIYyWdPasCrgmAH4LnhKajW7RybPHMFGZf7VPemWYPVrocKbGlc+PbOBnL8T1hg3PdDwv wHxkwKAOVPLR9QvqovbNvTZfwYtlSG3yowAsOf/OrL1eukgULyVLjhOgyM5Zc7dBfSxxslBY o+Mm5SqJik+FEiTAg+4mI8ABam8AAAAAAAA= --------------ms060507060801060700020200-- From owner-freebsd-arm@freebsd.org Fri Aug 5 00:55:11 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6025FBAEAAE for ; Fri, 5 Aug 2016 00:55:11 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EDD3811D5 for ; Fri, 5 Aug 2016 00:55:09 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u750sfYp069135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 5 Aug 2016 02:54:47 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u750sZd9053969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2016 02:54:36 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u750sZG6026693; Fri, 5 Aug 2016 02:54:35 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u750sYHn026692; Fri, 5 Aug 2016 02:54:34 +0200 (CEST) (envelope-from ticso) Date: Fri, 5 Aug 2016 02:54:34 +0200 From: Bernd Walter To: freebsd-arm@freebsd.org Cc: Bernd Walter Subject: compiling modules and FDT define Message-ID: <20160805005433.GL18406@cicely7.cicely.de> Reply-To: ticso@cicely.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 00:55:11 -0000 I compile a driver as module and it seems that FDT isn't defined on a rpi. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Fri Aug 5 06:21:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F61EBAF017 for ; Fri, 5 Aug 2016 06:21:32 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 568E7173B for ; Fri, 5 Aug 2016 06:21:32 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-ua0-x234.google.com with SMTP id 74so5951168uau.0 for ; Thu, 04 Aug 2016 23:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X9wMN2j+IKUcQ+v/LPBe0GLGUBDMV1jgV5htL2CCAeY=; b=xZ20mG5BUHJUlGD/00kQ0ZMeHdRH9c+brruwAFoRCVuFpKzNERfCpookGA0P1qAmIb T9jWmAYO8BcuR5F7/75BjczU2ksmzppLi8u+L0BlYufH+GAyPo35w5rdq+YGvivb0FZH aIWy4iswQRm+3GR+7gmF1oLtw3MjGn9OKcQdk5KhQMVszwA8yKTGXFcSdsoAoa3sYbmu hAGX/6sxNq4N9T//rVefIzJMC8G5ELyoGpPJsx5+h2/XXNhu0YfUbc3qpkJJhjto1OR2 0xMHh6Vl3ByMIwgYkEoxMFiy2H3J4kB1NWXA8BAxuP9sY+q2ae9VGt3nGk7E1268Ct0u Q6nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X9wMN2j+IKUcQ+v/LPBe0GLGUBDMV1jgV5htL2CCAeY=; b=lWU2Yijy9Q5BQrgTqNtOeyNOdx6yR6Z8TAEKjkdQaEXCct2dUfEOQLER7TkkoEVrrf VgxaXR9f9fTfXs7zRTYE7ZdWMnuX0iTDnSUV0/e9sIKx1oTRU5z6jpk2FTCj9mjoB1A4 lxsnrDeUYr2WSCjLRzmY4b02rDq0uvSwQ9uBGAEgPqI6B/VhyLJKaWvmqzHAN9nWsGmS sxKbUPIJGhA56OKc2WwWNbLbdBcqm6x/As5aXqkirtSx7Kq3WpQorKv0sL0DxGQDAH1d sWKzA7vqwk7Fzt/JAaF9lHJL+j3L1rYXYDIumZvXT5aRKcOnJd2+KhSThvLnPge0fklO dkxQ== X-Gm-Message-State: AEkoouvPh+FenAPTRlB6zKYYUcDpnlHRlRAzigjy0MwqI5/p+BB6roAwCLST2X9ezKam3kMrce2csoNcMTTRWQ== X-Received: by 10.176.7.9 with SMTP id h9mr4555820uah.86.1470378091375; Thu, 04 Aug 2016 23:21:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.54.75 with HTTP; Thu, 4 Aug 2016 23:21:30 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Thu, 4 Aug 2016 23:21:30 -0700 Message-ID: Subject: Re: Paid Support for iMX6 Port To: Michel Kohanim Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 06:21:32 -0000 On Tue, Aug 2, 2016 at 4:02 PM, Michel Kohanim wrote: > Hi Russell, > > Thanks so very much. I have already been there many times. Okay here is roughly everything that I have up to this point. I haven't built an entire sd card in a while so there are lots of errors and omissions (and a couple to-dos). https://github.com/RussellHaley/RussellsCode/wiki/FreeBSD-and-Freescale-IMX6 This is shaping up to be a second installment of what I was thinking could be an article on Freescale IMX6 and FreeBSD. I thought I would submit it to the FreeBSD journal or BSD Magazine (thoughts anyone?). I know it's all on the wiki in various forms, but I've built this information up myself before I knew about the wiki entries so I consider it original content (as also stated in my Github wiki entry). Anyway, repeating this stuff and getting exposure for the project isn't a bad idea (especially if it prompts someone to look at the sata driver for me!!!). Cheers, Russ > -----Original Message----- > From: Russell Haley [mailto:russ.haley@gmail.com] > Sent: Tuesday, August 2, 2016 3:30 PM > To: freebsd-arm ; Michel Kohanim > Subject: Re: Paid Support for iMX6 Port > > On Tue, Aug 2, 2016 at 3:16 PM, Russell Haley wrote: >> Sorry, reply instead of reply all... >> >> >> ---------- Forwarded message ---------- >> From: Russell Haley >> Date: Tue, Aug 2, 2016 at 3:16 PM >> Subject: Re: Paid Support for iMX6 Port >> To: Michel Kohanim >> >> >> On Tue, Aug 2, 2016 at 2:39 PM, Michel Kohanim >> wrote: >>> Hi Russell, > >> Give me a few days, I just got back from vacation and kids don't sleep >> well during summer hours so I have very limited time right now, but I >> will get you what I have so far. > > Most of what you need is here: > > https://wiki.freebsd.org/FreeBSD/arm/crossbuild > > and even specifies the right kernel conf! > > Russ From owner-freebsd-arm@freebsd.org Fri Aug 5 13:44:24 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A275BAF9A9 for ; Fri, 5 Aug 2016 13:44:24 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13A5915C8 for ; Fri, 5 Aug 2016 13:44:23 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u75Di57W074119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 5 Aug 2016 15:44:06 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u75Di03D064936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2016 15:44:00 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u75DhxsY028399; Fri, 5 Aug 2016 15:43:59 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u75DhxcJ028398; Fri, 5 Aug 2016 15:43:59 +0200 (CEST) (envelope-from ticso) Date: Fri, 5 Aug 2016 15:43:59 +0200 From: Bernd Walter To: freebsd-arm@freebsd.org Cc: Bernd Walter Subject: out of tree kernel modules (was: compiling modules and FDT define) Message-ID: <20160805134358.GN18406@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20160805005433.GL18406@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160805005433.GL18406@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 13:44:24 -0000 On Fri, Aug 05, 2016 at 02:54:34AM +0200, Bernd Walter wrote: > I compile a driver as module and it seems that FDT isn't defined > on a rpi. When compiling kernel with modules you get an opt_platform.h containing #define FDT 1 For my out of tree module all I get is an empty file. I assume that also happens when you just manually compile anything in sys/modules. Do I really need to integrate the driver into the kernel source tree and always compile everything? The symptoms of missing FDT support is subtile, because everything may seem to work, the device probing just accepts more devices than it is supposed to handle. On a side note, the ofw_bus_is_compatible and ofw_bus_search_compatible functions are undocumented. At least they don't have a manpage. My only option was to blindly copy from another driver, without really understanding the differences between those two functions. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Fri Aug 5 18:01:41 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4145BAFC16 for ; Fri, 5 Aug 2016 18:01:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B36AD1C98 for ; Fri, 5 Aug 2016 18:01:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x242.google.com with SMTP id y195so24721322iod.0 for ; Fri, 05 Aug 2016 11:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gSWvGMhcYWveThcqQ/3DDtJOYD83dK3cGUuzEsjqwe8=; b=p1STB3KOiPqEJUsNZgcr9hJqHE2RujieXpsMOL/H9de+c0pbruo65phDAD3zNJxSln UNVV6hWFT1i9Ep8inCCf5S+xLWzp/H/X0FgNMBuzneNhhACAYtiTg5XAeRqKSwhaiveI Gl0/Uwn1zkAZwi8OWHU0MAjysHCQN7bCQX4GPpA2JhM31flQEYSh9jMbKwpfK7jmu4d1 8Uksw8RLr0K1ZGooQPu8uWLDcxHhQ6t6jYOx+S6fKUqjbUuyo+AQea+xoFIi89W7OrJf P1WZB5yqLhzU22jxEL//F+D1IFpy2iD10AZ1VG+MawOaUYWeQqioYKkV6G8MUFyDjcx/ HwSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gSWvGMhcYWveThcqQ/3DDtJOYD83dK3cGUuzEsjqwe8=; b=IVKDXqibNvTlrrPeH+8roqTUU6Ke8qB/ghU7sxCmc0aNkLJD0VgffZ96mRd7AN7PjT XacvYyYcma/fFuOmJuo/56ZGPvKPWxdZu7J6P1VDpuapIv5T5nGsTeh9vWwDSmZuE6sm JZpAZ5UxQB5SYASQKhx4JrMIO7G1TX260pHw9CnnmNJcMYg8qp7uL0OkC82ZnKZJ7cSl C46Plu2/THZWpL9dPv4+R87LvLqLgjbr9VbJiiSqnBlCA5+MviJOrkAL9/onBlLG5LIV PXWc9cgGHmbmn3xCXRY+vTitEopq+RaDJ3GpB/V/M5RxFgztE5pHqdCWj8kS55JNzRSQ Fcvw== X-Gm-Message-State: AEkooushDIelyvIa0xUnqN7hlHKSofbFqJKEw5shb43RCZ069DqLuCUa1eK68jL/g2Z6/thzwdQ4tHnuwKcmBg== X-Received: by 10.107.21.134 with SMTP id 128mr77874149iov.59.1470420100846; Fri, 05 Aug 2016 11:01:40 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.105 with HTTP; Fri, 5 Aug 2016 11:01:40 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: <20160805005433.GL18406@cicely7.cicely.de> References: <20160805005433.GL18406@cicely7.cicely.de> From: Warner Losh Date: Fri, 5 Aug 2016 12:01:40 -0600 X-Google-Sender-Auth: f8gmHnGbeE44Vm2ieBCGpB99khA Message-ID: Subject: Re: compiling modules and FDT define To: ticso@cicely.de Cc: "freebsd-arm@freebsd.org" , Bernd Walter Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 18:01:42 -0000 On Thu, Aug 4, 2016 at 6:54 PM, Bernd Walter wrote: > I compile a driver as module and it seems that FDT isn't defined > on a rpi. Which module? Warner From owner-freebsd-arm@freebsd.org Fri Aug 5 20:15:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62EB1BAF200 for ; Fri, 5 Aug 2016 20:15:52 +0000 (UTC) (envelope-from michel@universal-devices.com) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0122.outbound.protection.outlook.com [104.47.41.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA8C212F4 for ; Fri, 5 Aug 2016 20:15:50 +0000 (UTC) (envelope-from michel@universal-devices.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=universaldevices.onmicrosoft.com; s=selector1-universaldevices-com02c; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jwm6DGI6bTtHKEudQSlGyl4sjg2IcSrIRxiH3rHvIh0=; b=U80fctGoK2ju/eetGx1bAIIyBOzY1DD9f3QfnUILAGkK9THiNztI3UHVeT/BHIlsNwIeeSFmGaY4Tg6U6iylydQJP7iPmFjFeaoKoP8VYsUKuM3DO4/WswT862dyUWSEGOYGRy+R3bpA61z2n+3ciZtXG9wHrZRL1Tx6Lp69eF8= Received: from SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) by SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 5 Aug 2016 18:42:29 +0000 Received: from SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) by SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) with mapi id 15.01.0549.023; Fri, 5 Aug 2016 18:42:29 +0000 From: Michel Kohanim To: Russell Haley CC: freebsd-arm Subject: RE: Paid Support for iMX6 Port Thread-Topic: Paid Support for iMX6 Port Thread-Index: AdHs1b5KsSu8z2xcTpKjv7T6+miKcwAK8ckAAACUROAAAetxgAAAevRpAAEcQCAAc+5kAAAZu28w Date: Fri, 5 Aug 2016 18:42:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michel@universal-devices.com; x-originating-ip: [75.83.36.12] x-ms-office365-filtering-correlation-id: b9c64f90-ba9a-4a84-987e-08d3bd6040f6 x-microsoft-exchange-diagnostics: 1; SN1PR0201MB1534; 6:qO3I6UVedVFnRTzh6DhRgekR1opXt3Mt0kuPWId+WpYy/DIh02vdYxamAiI5aLwQJTYnVAwQNm038UZHS6B9iiQCazcBoxH8re4Qz2HvQbN4e6O4/XYYwMJMgmZGJewiKVes3GpUuyInkUaImusw1zNvbWA6l++2XJW2jcaBv6iyXgcRMYIIbvkHymKH87DJd1Qu4VGDR5PCtxK0UjKL8W27UlF+MzXZwxFENwWNT65DjeVpV+ar8UsrFm8/TatXn2YmAZwN7d+3yR6LZ/jU2G8qPHq9c0nIn9GiDU7BG/PDmn9lvgYAs/4ZE2Ls7HVe; 5:77D4Z18MvyYXyqyPzPzpxYt9+jsY8HXYjUOHmkMzhuykBW0tEYfwgbvJkyU2BdV7UP/u3gYB2rM2DnZQP1H/FgzHK7GQLhY9RvOX7cR9w7q/mZ+NzoCYIugzzz7urF7D4AdIqqCHiy3PkFYYadthvg==; 24:iuLDnv0GX6Q3whQH8/z85w5pCc5XhkGa5XR/ZA3yHVyzGXzsKMEO1YpzQnuh2+/fl/SatVfLEWfsUd+o8qNWK6879nfMWa0d80MLGBffg4I=; 7:KG6hd/xbp+qu7PmaGa3SfrDQIrWfANRxUhMCuIHtyYmdoIfkoMTE2rXjQgLQVKmwlNJKqiLxBwyM9tVjqY+s9bfenHUIA8FSS+fIjLJJuQVk4hdfKcmZXnMsfVTCiJBkIBo6egL9swuvdu49lJcPDCWmIDiof7o6aDUplrYitBzeM5f/qjYW39WDoBuW29zI3MjbNevJAjWOHrYxAWhLMmdguklT378ldyRBItda8tFGsn6uWwtcvbroVgXPzCoB x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0201MB1534; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:SN1PR0201MB1534; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0201MB1534; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(13464003)(377454003)(52314003)(199003)(71364002)(189002)(87936001)(76176999)(4326007)(68736007)(7736002)(10400500002)(7696003)(81156014)(8676002)(106356001)(110136002)(2906002)(74316002)(54356999)(19580405001)(19580395003)(33656002)(9686002)(305945005)(50986999)(8936002)(81166006)(11100500001)(3660700001)(189998001)(7846002)(3280700002)(66066001)(2900100001)(105586002)(3846002)(122556002)(77096005)(76576001)(102836003)(86362001)(16601075003)(99286002)(2950100001)(101416001)(6116002)(92566002)(586003)(15975445007)(5002640100001)(93886004)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0201MB1534; H:SN1PR0201MB1534.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: universal-devices.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: universal-devices.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2016 18:42:29.0791 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d628f750-5cc1-4a42-9d4c-463ac737d54f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1534 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 20:15:52 -0000 SGkgUnVzc2VsbCwNCg0KVGhhbmtzIFNPIHNvIHZlcnkgbXVjaC4gVGhpcyBpcyBxdWl0ZSBoZWxw ZnVsIGFuZCBlc3BlY2lhbGx5IHRoZSBzZWN0aW9uIG9uICJPdGhlciBidWlsZCB0cmlja3MiIGlz IHF1aXRlIGZhbnRhc3RpYyENCg0KDQpXaXRoIGtpbmQgcmVnYXJkcywNCg0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQrCoCBNaWNoZWwgS29oYW5pbQ0KwqAgQ0VPDQrCoA0KwqAgKHAp IDgxOC42MzEuMDMzMw0KwqAgKGYpwqAgODE4LjQzNi4wNzAyDQrCoCBodHRwOi8vd3d3LnVuaXZl cnNhbC1kZXZpY2VzLmNvbSANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnVzc2VsbCBIYWxleSBbbWFpbHRvOnJ1c3Mu aGFsZXlAZ21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgNCwgMjAxNiAxMToyMiBQ TQ0KVG86IE1pY2hlbCBLb2hhbmltIDxtaWNoZWxAdW5pdmVyc2FsLWRldmljZXMuY29tPg0KQ2M6 IGZyZWVic2QtYXJtIDxmcmVlYnNkLWFybUBmcmVlYnNkLm9yZz4NClN1YmplY3Q6IFJlOiBQYWlk IFN1cHBvcnQgZm9yIGlNWDYgUG9ydA0KDQpPbiBUdWUsIEF1ZyAyLCAyMDE2IGF0IDQ6MDIgUE0s IE1pY2hlbCBLb2hhbmltIDxtaWNoZWxAdW5pdmVyc2FsLWRldmljZXMuY29tPiB3cm90ZToNCj4g SGkgUnVzc2VsbCwNCj4NCj4gVGhhbmtzIHNvIHZlcnkgbXVjaC4gSSBoYXZlIGFscmVhZHkgYmVl biB0aGVyZSBtYW55IHRpbWVzLg0KDQpPa2F5IGhlcmUgaXMgcm91Z2hseSBldmVyeXRoaW5nIHRo YXQgSSBoYXZlIHVwIHRvIHRoaXMgcG9pbnQuIEkgaGF2ZW4ndCBidWlsdCBhbiBlbnRpcmUgc2Qg Y2FyZCBpbiBhIHdoaWxlIHNvIHRoZXJlIGFyZSBsb3RzIG9mIGVycm9ycyBhbmQgb21pc3Npb25z IChhbmQgYSBjb3VwbGUgdG8tZG9zKS4NCg0KaHR0cHM6Ly9naXRodWIuY29tL1J1c3NlbGxIYWxl eS9SdXNzZWxsc0NvZGUvd2lraS9GcmVlQlNELWFuZC1GcmVlc2NhbGUtSU1YNg0KDQpUaGlzIGlz IHNoYXBpbmcgdXAgdG8gYmUgYSBzZWNvbmQgaW5zdGFsbG1lbnQgb2Ygd2hhdCBJIHdhcyB0aGlu a2luZyBjb3VsZCBiZSBhbiBhcnRpY2xlIG9uIEZyZWVzY2FsZSBJTVg2IGFuZCBGcmVlQlNELiBJ IHRob3VnaHQgSSB3b3VsZCBzdWJtaXQgaXQgdG8gdGhlIEZyZWVCU0Qgam91cm5hbCBvciBCU0Qg TWFnYXppbmUgKHRob3VnaHRzIGFueW9uZT8pLiBJIGtub3cgaXQncyBhbGwgb24gdGhlIHdpa2kg aW4gdmFyaW91cyBmb3JtcywgYnV0IEkndmUgYnVpbHQgdGhpcyBpbmZvcm1hdGlvbiB1cCBteXNl bGYgYmVmb3JlIEkga25ldyBhYm91dCB0aGUgd2lraSBlbnRyaWVzIHNvIEkgY29uc2lkZXIgaXQg b3JpZ2luYWwgY29udGVudCAoYXMgYWxzbyBzdGF0ZWQgaW4gbXkgR2l0aHViIHdpa2kgZW50cnkp Lg0KQW55d2F5LCByZXBlYXRpbmcgdGhpcyBzdHVmZiBhbmQgZ2V0dGluZyBleHBvc3VyZSBmb3Ig dGhlIHByb2plY3QgaXNuJ3QgYSBiYWQgaWRlYSAoZXNwZWNpYWxseSBpZiBpdCBwcm9tcHRzIHNv bWVvbmUgdG8gbG9vayBhdCB0aGUgc2F0YSBkcml2ZXIgZm9yIG1lISEhKS4NCg0KQ2hlZXJzLA0K DQpSdXNzDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnVzc2VsbCBI YWxleSBbbWFpbHRvOnJ1c3MuaGFsZXlAZ21haWwuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBBdWd1 c3QgMiwgMjAxNiAzOjMwIFBNDQo+IFRvOiBmcmVlYnNkLWFybSA8ZnJlZWJzZC1hcm1AZnJlZWJz ZC5vcmc+OyBNaWNoZWwgS29oYW5pbSANCj4gPG1pY2hlbEB1bml2ZXJzYWwtZGV2aWNlcy5jb20+ DQo+IFN1YmplY3Q6IFJlOiBQYWlkIFN1cHBvcnQgZm9yIGlNWDYgUG9ydA0KPg0KPiBPbiBUdWUs IEF1ZyAyLCAyMDE2IGF0IDM6MTYgUE0sIFJ1c3NlbGwgSGFsZXkgPHJ1c3MuaGFsZXlAZ21haWwu Y29tPiB3cm90ZToNCj4+IFNvcnJ5LCByZXBseSBpbnN0ZWFkIG9mIHJlcGx5IGFsbC4uLg0KPj4N Cj4+DQo+PiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCj4+IEZyb206 IFJ1c3NlbGwgSGFsZXkgPHJ1c3MuaGFsZXlAZ21haWwuY29tPg0KPj4gRGF0ZTogVHVlLCBBdWcg MiwgMjAxNiBhdCAzOjE2IFBNDQo+PiBTdWJqZWN0OiBSZTogUGFpZCBTdXBwb3J0IGZvciBpTVg2 IFBvcnQNCj4+IFRvOiBNaWNoZWwgS29oYW5pbSA8bWljaGVsQHVuaXZlcnNhbC1kZXZpY2VzLmNv bT4NCj4+DQo+Pg0KPj4gT24gVHVlLCBBdWcgMiwgMjAxNiBhdCAyOjM5IFBNLCBNaWNoZWwgS29o YW5pbSANCj4+IDxtaWNoZWxAdW5pdmVyc2FsLWRldmljZXMuY29tPiB3cm90ZToNCj4+PiBIaSBS dXNzZWxsLA0KPg0KPj4gR2l2ZSBtZSBhIGZldyBkYXlzLCBJIGp1c3QgZ290IGJhY2sgZnJvbSB2 YWNhdGlvbiBhbmQga2lkcyBkb24ndCANCj4+IHNsZWVwIHdlbGwgZHVyaW5nIHN1bW1lciBob3Vy cyBzbyBJIGhhdmUgdmVyeSBsaW1pdGVkIHRpbWUgcmlnaHQgbm93LCANCj4+IGJ1dCBJIHdpbGwg Z2V0IHlvdSB3aGF0IEkgaGF2ZSBzbyBmYXIuDQo+DQo+IE1vc3Qgb2Ygd2hhdCB5b3UgbmVlZCBp cyBoZXJlOg0KPg0KPiBodHRwczovL3dpa2kuZnJlZWJzZC5vcmcvRnJlZUJTRC9hcm0vY3Jvc3Ni dWlsZA0KPg0KPiBhbmQgZXZlbiBzcGVjaWZpZXMgdGhlIHJpZ2h0IGtlcm5lbCBjb25mIQ0KPg0K PiBSdXNzDQo= From owner-freebsd-arm@freebsd.org Fri Aug 5 20:25:11 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15636BAF45C for ; Fri, 5 Aug 2016 20:25:11 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0ECF17CC for ; Fri, 5 Aug 2016 20:25:10 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x22c.google.com with SMTP id s189so199931431vkh.1 for ; Fri, 05 Aug 2016 13:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AhRN8KkuLDdaHCrDAKh/K9a7bqxDvWmhuamMlcZhO3M=; b=GBPs6gwhAssJF0g3mS3HqSQzHVEkiyPpWQWhxPkvq6SytFHeSL1geunz8nudHyuWxS 7jAcS8J9wbDIokAGK6HppjJW/4KvhnCDkidKafaf80t0TUjVoGd6j6bol015D9+1KpPn G7vtn2ZGwARX6OqpZc5TerjWzSehsSx05DWnAV3BSF0oXUPHcK8axKIeW1vWfnHL/kg6 j1gAaUDpn8cEKu9wXvb1JHWQjm0gmp95d1iFav2gBWTKPFo2RiTkbcilPn8Cib8zctyq G2KP4uujcooTyrwmv0oyAAsyt6IkFlBXaUTm0FvwZpU0iai3rs3e1e9T3AQqHyWucENm kOgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AhRN8KkuLDdaHCrDAKh/K9a7bqxDvWmhuamMlcZhO3M=; b=HlWSDwcTZ4uGrSxHM1VM55YvM1lm7b6dHyq3NjtovlgZU+BCUVxK2Idp9e4so16acO CY2xPOl3XfmVWVVt9vryJ4uEme0xp9qrSyf+FZU3whEjAecsn780ZJEbuctLpeZdvc8P Vd/lTf+X8323nN19BcCDEvOKyUo8hmlE4QXL+Pqv6zplZ3QXe6OyLM2jAUGC35MLjo6g VXgHvpOwtwQeRVhaweivJETr4WPtd4YroXAWmKXYoFmeMs9KvhJ3e8ukVGpJIGvMz9eU +FIlCV4DCNdAQNO96EL/zJp7RlgB9z3jImHlRuaK9np1ZylEUeMEA3a+oy70hZrMCHKX l8Iw== X-Gm-Message-State: AEkooutOUAXzi2jaX7qe9zGKsVyzmkst1jk5l37AMqibMPYKtjO3Z63g5a77qDIsyJEWphjRen9peSGdWMlb1w== X-Received: by 10.31.185.9 with SMTP id j9mr41797878vkf.144.1470428709796; Fri, 05 Aug 2016 13:25:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.54.75 with HTTP; Fri, 5 Aug 2016 13:25:09 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Fri, 5 Aug 2016 13:25:09 -0700 Message-ID: Subject: Re: Fwd: Paid Support for iMX6 Port To: Ronald Klop Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 20:25:11 -0000 On Wed, Aug 3, 2016 at 8:27 AM, Ronald Klop wrote: > On Wed, 03 Aug 2016 00:16:55 +0200, Russell Haley > wrote: > >> Sorry, reply instead of reply all... >> >> >> ---------- Forwarded message ---------- >> From: Russell Haley >> Date: Tue, Aug 2, 2016 at 3:16 PM >> Subject: Re: Paid Support for iMX6 Port >> To: Michel Kohanim >> >> >> On Tue, Aug 2, 2016 at 2:39 PM, Michel Kohanim >> wrote: >>> >>> Hi Russell, >>> >>> Thanks so very much for getting in touch. Hopefully the experienced iMX6 >>> developer will chime in. Again, I am willing to pay for services and then >>> share the results with the community. >>> >>> 1. Would love to read your notes on Hummingboard. I am using Wandboard >>> and Wandboard Dual for testing purposes and have been able to get FreeBSD >>> binary image (from the website) loaded and functioning albeit it's way too >>> slow even for rudimentary tasks such as vi (on the Solo). I suspect 512MB is >>> not sufficient. Ultimately, I would like to be able to make a smaller image >>> ourselves but have been having a hell of a time with Crochet >> >> >> Give me a few days, I just got back from vacation and kids don't sleep >> well during summer hours so I have very limited time right now, but I >> will get you what I have so far. >> >> >> >>> 6. NAND flash/eMMC ... our main goal is that - at the minimum - the >>> kernel should be on a flash chip of some sort so that boot up does NOT >>> require an SD Card. Are you aware of any flash chip that can be used by >>> uboot to boot FreeBSD? >> >> It's possible to run u-boot from NAND and then run ubldr/kernel from a >> different source. It may even be possible to manually load ubldr from >> NAND (or even manually load the kernel from NAND in u-boot) but you >> would need to find an alternative for the kernel and rootfs, >> especially if you want to update your kernel ever. Not what I would >> call desirable, but I have *heard* of production systems running like >> this. > > > > My Sheevaplug loads the kernel from NAND which mounts the rootfs from > USB-stick. And does this for a couple of years already. I used to have a > rootfs on nandfs(5) also, but nandfs is not stable enough. > > # nandtool erase dev=/dev/gnand0s.fbsd-boot > # dd if=/tmp/kernel.bin of=/dev/gnand0s.fbsd-boot bs=2k conv=sync Hi Ronald, So does this mean you used an freebsd slice for nandfs on the entire nand unit and placed u-boot and the kernel within the nandfs slice (I'll look at nandfs documentation when I get a chance)? It's probably implementation specific, but I wonder if the partition table and nandfs would affect the "hardware boot loaders" ability to find the u-boot binary (I don't understand the pre-u-boot boot process yet)? Also, are you saying that nandfs is "stable enough" to be used in a write-rarely/read-often scheme? Russ From owner-freebsd-arm@freebsd.org Fri Aug 5 21:29:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE2F8BB0396 for ; Fri, 5 Aug 2016 21:29:16 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 566BD18EA for ; Fri, 5 Aug 2016 21:29:15 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u75LSvxM076438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Aug 2016 23:28:58 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u75LSgAb070818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2016 23:28:43 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u75LSgd5029219; Fri, 5 Aug 2016 23:28:42 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u75LSfHv029218; Fri, 5 Aug 2016 23:28:41 +0200 (CEST) (envelope-from ticso) Date: Fri, 5 Aug 2016 23:28:41 +0200 From: Bernd Walter To: Warner Losh Cc: ticso@cicely.de, "freebsd-arm@freebsd.org" , Bernd Walter Subject: Re: compiling modules and FDT define Message-ID: <20160805212841.GO18406@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20160805005433.GL18406@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 21:29:16 -0000 On Fri, Aug 05, 2016 at 12:01:40PM -0600, Warner Losh wrote: > On Thu, Aug 4, 2016 at 6:54 PM, Bernd Walter wrote: > > I compile a driver as module and it seems that FDT isn't defined > > on a rpi. > > Which module? Self written for APA102 LED strings. I've placed it on freefall: /home/ticso/apa102led I've removed the FDT conditionals in that version. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Fri Aug 5 21:35:43 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC7BBBB06C4 for ; Fri, 5 Aug 2016 21:35:43 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C4EA1012 for ; Fri, 5 Aug 2016 21:35:42 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u75LZZa3076477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 5 Aug 2016 23:35:40 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u75LZTpJ070923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2016 23:35:29 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u75LZTwd029245; Fri, 5 Aug 2016 23:35:29 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u75LZTbH029244; Fri, 5 Aug 2016 23:35:29 +0200 (CEST) (envelope-from ticso) Date: Fri, 5 Aug 2016 23:35:29 +0200 From: Bernd Walter To: freebsd-arm@freebsd.org Cc: Bernd Walter Subject: ow_temp failed to read when loaded as module Message-ID: <20160805213528.GP18406@cicely7.cicely.de> Reply-To: ticso@cicely.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 21:35:44 -0000 It might be the loading order I'd used. kldload owc kldload ow kldload ow_temp owc0: at pin 4 on gpiobus0 ow0: <1 Wire Bus> on owc0 oops, starting over oops, starting over oops, starting over oops, starting over oops, starting over oops, starting over oops, starting over oops, starting over ow0: romid 28:b0:6b:29:05:00:00:ae: no driver ow0: romid 28:99:3b:29:05:00:00:1b: no driver ow_temp0: romid 28:b0:6b:29:05:00:00:ae on ow0 ow_temp1: romid 28:99:3b:29:05:00:00:1b on ow0 root@rpi-b:/home/freebsd # sysctl dev.ow_temp dev.ow_temp.1.parasite: 0 dev.ow_temp.1.reading_interval: 1000 dev.ow_temp.1.badread: 0 dev.ow_temp.1.badcrc: 0 dev.ow_temp.1.temperature: -1 dev.ow_temp.1.%parent: ow0 dev.ow_temp.1.%pnpinfo: romid=28:99:3b:29:05:00:00:1b dev.ow_temp.1.%location: dev.ow_temp.1.%driver: ow_temp dev.ow_temp.1.%desc: Advanced One Wire Temperature dev.ow_temp.0.parasite: 0 dev.ow_temp.0.reading_interval: 1000 dev.ow_temp.0.badread: 0 dev.ow_temp.0.badcrc: 0 dev.ow_temp.0.temperature: -1 dev.ow_temp.0.%parent: ow0 dev.ow_temp.0.%pnpinfo: romid=28:b0:6b:29:05:00:00:ae dev.ow_temp.0.%location: dev.ow_temp.0.%driver: ow_temp dev.ow_temp.0.%desc: Advanced One Wire Temperature dev.ow_temp.%parent: Compiled into the kernel everything runs fine: owc0: at pin 4 on gpiobus0 ow0: <1 Wire Bus> on owc0 ow_temp0: romid 28:b0:6b:29:05:00:00:ae on ow0 ow_temp1: romid 28:99:3b:29:05:00:00:1b on ow0 root@rpi-b:/home/freebsd # sysctl dev.ow_temp dev.ow_temp.1.parasite: 0 dev.ow_temp.1.reading_interval: 1000 dev.ow_temp.1.badread: 0 dev.ow_temp.1.badcrc: 5 dev.ow_temp.1.temperature: 29.312C dev.ow_temp.1.%parent: ow0 dev.ow_temp.1.%pnpinfo: romid=28:99:3b:29:05:00:00:1b dev.ow_temp.1.%location: dev.ow_temp.1.%driver: ow_temp dev.ow_temp.1.%desc: Advanced One Wire Temperature dev.ow_temp.0.parasite: 0 dev.ow_temp.0.reading_interval: 1000 dev.ow_temp.0.badread: 0 dev.ow_temp.0.badcrc: 4 dev.ow_temp.0.temperature: 29.437C dev.ow_temp.0.%parent: ow0 dev.ow_temp.0.%pnpinfo: romid=28:b0:6b:29:05:00:00:ae dev.ow_temp.0.%location: dev.ow_temp.0.%driver: ow_temp dev.ow_temp.0.%desc: Advanced One Wire Temperature dev.ow_temp.%parent: -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Sat Aug 6 03:20:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08377BAF1E2 for ; Sat, 6 Aug 2016 03:20:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6F671D77 for ; Sat, 6 Aug 2016 03:20:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x229.google.com with SMTP id 38so316075068iol.0 for ; Fri, 05 Aug 2016 20:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+CI9MvVmHNXLHh23Y8QksfoIC4xRoVKxQEY3dyO3I1I=; b=yZ8Uw6+3JcerpzqU8G6RobLqEvkrcumuTk2hgHxnUaYdtA7nQ2SE57y2qPfJRpc5Ub 52yLsD3m6BusrpGCzck6iXJ4dNkQx1TAuc+2llOIPeqT/uW3A7nKecrrX1W5refMIeRh PI5SnCDTh6VE0yXh3dsGraVi9cVLkRxZBpmfAnTBECekUy55dusfbxpWDW8x0qIQsg+F 65Q8wLWZifovyvnmDltNF04a2Im/jwKV5eoCLzhuaH1ijijqnzDgCSVezCmVymX8h4FR nxWkOWAH40kZtdezrhhk738bL5GLqovYo0mq9KhHZ+Ea18/q958CD26Rar4yuylRhEF3 OarA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+CI9MvVmHNXLHh23Y8QksfoIC4xRoVKxQEY3dyO3I1I=; b=XbvSjMGIfhWQStRTBMFvsbYYFWPlwA43ns8muSJdyXZsNnj2uCNHIt/w1x6TQP2jiN I/PhGB1b7qiBod7rOhYBDmBk28j2oKZt0QmbRbuT7dpFhtgFeJ/RC9aup2aFgbCMSlRn DyQqWqliCpPS0CAkUKTjjQilhREUDyxAj73wo/gud6C2kUkyLgTGG50rKmGo57i+Zmjq 9q0EYRwhneIvncBofArtNXp/5I+y1WQpvN2eC+AxaBiklIbu485lrC5vCQRfil/Q9w6C ukvMwgZCa/noyXBG57/9kQGi0SDZ2Xl1YzbBqhUN6mSejNYR8K+3YvVyud9AL2OhLMtG qLUQ== X-Gm-Message-State: AEkoouuG47aSBKPrH5mbZFyW9eMNWtTBcCxM23CugBE+reM7cQG/2KyIS0dH5Mwx1T4RtEu4Kjqui7PTKocC1A== X-Received: by 10.107.144.10 with SMTP id s10mr80066169iod.165.1470453612134; Fri, 05 Aug 2016 20:20:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Fri, 5 Aug 2016 20:20:11 -0700 (PDT) In-Reply-To: <20160805134358.GN18406@cicely7.cicely.de> References: <20160805005433.GL18406@cicely7.cicely.de> <20160805134358.GN18406@cicely7.cicely.de> From: Adrian Chadd Date: Fri, 5 Aug 2016 20:20:11 -0700 Message-ID: Subject: Re: out of tree kernel modules (was: compiling modules and FDT define) To: ticso@cicely.de Cc: "freebsd-arm@freebsd.org" , Bernd Walter Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 03:20:13 -0000 Hi, Try adding opt_platform.h to SRCS in the module makefile? You don't need to add it to the tree. You just have to setup your path to point things /at/ a kernel build tree withall the opt_xxx.h in them. here's what I do: #!/bin/sh X_SRCDIR=${X_SRCDIR:="/home/adrian/work/freebsd/head/src/"} X_KERNDIR=${X_KERNDIR:="/home/adrian/work/freebsd/head/obj/usr/home/adrian/work/freebsd/head/src/sys/GERTRUDE/"} X_KMODOWN=${X_KMODOWN:="adrian"} X_KMODGRP=${X_KMODGRP:="adrian"} # This allows for -HEAD includes for net80211 .. env CFLAGS="-I../../../sys/" \ make \ MODULES_OVERRIDE="" \ DEBUG_FLAGS="-g" \ DEBUG_FLAGS="-g" \ KMODDIR="/home/adrian/git/github/erikarn/athp/otus/freebsd/modules/" \ KMODOWN="${X_KMODOWN}" \ KMODGRP="${X_KMODGRP}" \ MAKESYSPATH="${X_SRCDIR}/share/mk" \ SYSDIR="${X_SRCDIR}/sys/" \ KERNBUILDDIR="${X_KERNDIR}" \ KERN_DEBUGDIR="" \ $@ That gets me all the bits I need to be able to run make in module directories and get the correct includes/links setup. -a On 5 August 2016 at 06:43, Bernd Walter wrote: > On Fri, Aug 05, 2016 at 02:54:34AM +0200, Bernd Walter wrote: >> I compile a driver as module and it seems that FDT isn't defined >> on a rpi. > > When compiling kernel with modules you get an opt_platform.h containing > #define FDT 1 > > For my out of tree module all I get is an empty file. > I assume that also happens when you just manually compile anything in > sys/modules. > > Do I really need to integrate the driver into the kernel source tree > and always compile everything? > > The symptoms of missing FDT support is subtile, because everything > may seem to work, the device probing just accepts more devices than > it is supposed to handle. > > On a side note, the ofw_bus_is_compatible and ofw_bus_search_compatible > functions are undocumented. > At least they don't have a manpage. > My only option was to blindly copy from another driver, without really > understanding the differences between those two functions. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Aug 6 13:06:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97A54BAF9DE for ; Sat, 6 Aug 2016 13:06:22 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46C7B16C0 for ; Sat, 6 Aug 2016 13:06:22 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id v123so153737885qkh.3 for ; Sat, 06 Aug 2016 06:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=JfyzTq/V4Vvcpk3txkZGmZ0+5pPudXlV/1E9wdJx3E4=; b=pKbJKfmASjq/UbHyVni+LIZA10ouZ8goR3Eu82EAcKKEXN6ImsCd7ypaevDeCDeyis bR9Ay+Yvy05pKUR9LpzdlCeeNatLZqQQ3AKJE7ZcuvceJny9XOaDFe2jioTGA/3pZr7q 49v1le7IcXWMlnNBK+9qsn2+kJ4/vvqZsLCdt1PnwoYMDC9UdL3d55mf40MKwL+kNge8 J0UlIQ55+wbCi0fxHpfX/Wjd2HNBXkma2HOvUeXIRtA7NemoSyggtka9gfrLSrTci448 YAL2poIbw3XfURni9zQ5O+3FvKEee7RXu0pCN1TO++N+zVEE2cSxqgrZR9UYtobN4jKR ZXYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=JfyzTq/V4Vvcpk3txkZGmZ0+5pPudXlV/1E9wdJx3E4=; b=RU+cbWIyTX+6PMDgLDXDXm0kyrDEMdHESZ2x+n0XXjohGnV9g0EvvKeQtA6+40wHtl 6NORA8iy2A8QuQVUdt/GdZhBmLoD1bvr5uZh4CQcEcgEvHkom3Ri4LTGxhvZuKYtPstJ b6BKqcPNiTW3nnS9LwhilxM5k6UEGuLkShrNTlLR+a97uDZOIiASZotF5SCRzblltUBu cHZ0gQg6j3X/1cH0GENgVIaBE2jJYtcjRxGwlg7Ibnok1fewCMdCgEygnxQF8kM5EsXI nlMbeE7HAOrtRa41+d2JZ0vM0TUk6hBG+lnRi6PKD5zB4Gh/N+KxSIqFpVLKmKfMCtME 2YXQ== X-Gm-Message-State: AEkoousrFx9E6YHkcU2w755JeIIHOmTptFQFGCzyGZE0lqL5tAsAPBk/0vlobwCf65CJTue5HS/wc8J+kmwZKQ== X-Received: by 10.55.75.76 with SMTP id y73mr19895612qka.12.1470488781211; Sat, 06 Aug 2016 06:06:21 -0700 (PDT) MIME-Version: 1.0 Sender: r.c.ladan@gmail.com Received: by 10.55.73.80 with HTTP; Sat, 6 Aug 2016 06:06:20 -0700 (PDT) Received: by 10.55.73.80 with HTTP; Sat, 6 Aug 2016 06:06:20 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Ren=C3=A9_Ladan?= Date: Sat, 6 Aug 2016 15:06:20 +0200 X-Google-Sender-Auth: RMWzXugqwbl2PowX4NrowbyBmPU Message-ID: Subject: Raspberry Pi B stuck during boot? To: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 13:06:22 -0000 Hi, With recent versions of 11 (alpha3 and beta3) my raspberry b gets stuck near the end of the boot. I checked the SD card and updated it to 11-beta3 using these commands (if I remember correctly, but nothing unusual): % make buildworld TARGET=3Darm TARGET_ARCH=3Darmv6 % make buildkernel KERNCONF=3DRPI-B TARGET=3Darm TARGET_ARCH=3Darmv6 # make installworld TARGET=3Darm TARGET_ARCH=3Darmv6 DESTDIR=3D/mnt # make installkernel TARGET=3Darm TARGET_ARCH=3Darmv6 DESTDIR=3D/mnt KERNCONF=3DRPI-B # make delete-old TARGET=3Darm TARGET_ARCH=3Darmv6 DESTDIR=3D/mnt # make delete-old-libs TARGET=3Darm TARGET_ARCH=3Darmv6 DESTDIR=3D/mnt # mergemaster -A armv6 -D /mnt -p # mergemaster -A armv6 -D /mnt -U -i See https://rene-ladan.nl/IMG_20160804_193031.jpg for a phone picture of the TV screen where it gets stuck. Any ideas if what could be wrong? Regards, Ren=C3=A9 From owner-freebsd-arm@freebsd.org Sat Aug 6 14:23:59 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4818EBB0C3D for ; Sat, 6 Aug 2016 14:23:59 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CD8361914; Sat, 6 Aug 2016 14:23:57 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u76ENUMn082079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Aug 2016 16:23:36 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u76ENNFr089176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Aug 2016 16:23:24 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u76ENNEV031678; Sat, 6 Aug 2016 16:23:23 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u76ENNeW031677; Sat, 6 Aug 2016 16:23:23 +0200 (CEST) (envelope-from ticso) Date: Sat, 6 Aug 2016 16:23:23 +0200 From: Bernd Walter To: =?iso-8859-1?Q?Ren=E9?= Ladan Cc: freebsd-arm Subject: Re: Raspberry Pi B stuck during boot? Message-ID: <20160806142322.GB31491@cicely7.cicely.de> Reply-To: ticso@cicely.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 14:23:59 -0000 On Sat, Aug 06, 2016 at 03:06:20PM +0200, René Ladan wrote: > Hi, > > With recent versions of 11 (alpha3 and beta3) my raspberry b gets stuck > near the end of the boot. I checked the SD card and updated it to 11-beta3 > using these commands (if I remember correctly, but nothing unusual): > > % make buildworld TARGET=arm TARGET_ARCH=armv6 > % make buildkernel KERNCONF=RPI-B TARGET=arm TARGET_ARCH=armv6 > # make installworld TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt > # make installkernel TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt > KERNCONF=RPI-B > # make delete-old TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt > # make delete-old-libs TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt > # mergemaster -A armv6 -D /mnt -p > # mergemaster -A armv6 -D /mnt -U -i > > See https://rene-ladan.nl/IMG_20160804_193031.jpg for a phone picture of > the TV screen where it gets stuck. > > Any ideas if what could be wrong? It might be hanging in single user mode prompt on serial console. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Sat Aug 6 14:30:34 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31BEABB0D24; Sat, 6 Aug 2016 14:30:34 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D276A1A4C; Sat, 6 Aug 2016 14:30:33 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 270AE3AC81; Sat, 6 Aug 2016 16:30:25 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> <57A09F34.4050400@FreeBSD.org> <57A30B72.7070809@FreeBSD.org> <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <57A5F480.20309@FreeBSD.org> Date: Sat, 6 Aug 2016 16:30:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Sat, 06 Aug 2016 16:30:25 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 14:30:34 -0000 Dne 04.08.2016 v 14:34 Nathan Whitehorn napsal(a): [snip] > >> >>>>>> ------------ The following is a large parenthesis >>>>>> ------------------- >>>>>> >>>>>> One other possible route here that would also work well would be to >>>>>> make ofwbus.c MD (it's a trivial piece of code anyway, so we don't >>>>>> gain a lot by sharing it) and implement ofw_bus_map_intr() >>>>>> locally as >>>>>> an ofwbus bus method. Then you could have the mapping table >>>>>> stored in >>>>>> ofwbus's softc -- the API was designed for this initially. You would >>>>>> need MD extensions for doing PIC registration there (which is fine), >>>>>> but that segregates all the OFW-specific information into >>>>>> OFW-specific code and would let the bus methods and the OFW >>>>>> interrupt >>>>>> mapping table interact cleanly in the same place. This still >>>>>> preserves the pre-r301453 API, makes PowerPC work, and maybe >>>>>> address's skra@'s concern about extensibility and letting core >>>>>> interrupt code know about FDT (or ACPI). I'd be happy to mock >>>>>> this up >>>>>> as well if you think it's a good approach. >>>>>> >>>>> [snip] >>>>>> This has the following features: >>>>>> - Existing OFW API and semantics unchanged >>>>>> - As such, PowerPC, PCI, etc. work fine with no changes >>>>>> - Details encapsulated in MD code, so individual platforms can >>>>>> implement this however they like >>>>>> - arm/arm/intr.c (or whatever) only needs a method to allocate a >>>>>> fresh interrupt, with no state, and anoter to set the device_t >>>>>> for an >>>>>> interrupt sometime later. >>>>>> - The internal table in the platform interrupt code has no knowledge >>>>>> of any mappings whatsoever except having the appropriate device_t >>>>>> for >>>>>> the PIC stored with the interrupt vector. >>>>>> - Device tree bits handled purely in device tree code >>>>>> - No action need be taken on any mapping until the interrupt is >>>>>> actually allocated/set up, like r301453 >>>>>> - Easy to add more mapping mechanisms (e.g. ACPI) by having similar >>>>>> enumeration-mechanism-specific code in the root bus for that mapping >>>>>> mechanism. >>>>>> >>>>>> -------------- End parenthesis ------------------------------- >>>>> Here's an implementation of the parenthesis I wrote on an airplane >>>>> this afternoon. It should be complete, though has not been tested. >>>>> The >>>>> code is short and simple (+70 lines in ofwbus.c). This preserves the >>>>> pre-r301453 API and semantics relative to drivers, which means >>>>> PowerPC >>>>> and PCI work out of the box, while keeping the semantics relative to >>>>> the interrupt layer of r301453 (PIC methods only called on resource >>>>> allocation, no allocatable IRQs on unattached PICs, encapsulation of >>>>> OFW-specific code in OFW-specific bits of the tree). It turns out >>>>> those two things are compatible, somewhat to my surprise, and that >>>>> makes the result very clean. I like this approach and would be happy >>>>> to move forward with it. There are five functions of interest: >>>>> >>>>> 1. OFW_BUS_MAP_INTR(). This has the semantics and API it has now: you >>>>> pass an interrupt specifier and parent, you get back an IRQ. No >>>>> changes. This is the core of the normal OFW interrupt API. >>>>> >>>>> 2. OFW_BUS_REGISTER_PIC(device_t pic, phandle_t phandle). This is a >>>>> new function that PIC drivers are supposed to use to register control >>>>> of an interrupt domain. This replaces machine-specific code like >>>>> powerpc_register_pic() to allow the PIC table to be in a bus parent >>>>> rather than in the interrupt core. >>>>> >>>>> 3. PIC_MAP_OFW_INTR(device_t pic, int irq, interrupt specifier). This >>>>> is a new function that PIC drivers that know how to handle >>>>> device-tree >>>>> interrupt descriptors implement (analogous to various existing ones >>>>> that vary by platform). It tells the PIC that the given abstract IRQ >>>>> means the given opaque interrupt specifier. >>>>> >>>>> 4. arm_allocate_irq(int suggested). This allocates a new IRQ number >>>>> not (yet) attached to a PIC, as in r301453. I've added a parameter >>>>> that lets you pass a suggested number to try in case it is >>>>> possible to >>>>> make it match an interrupt pin or something for human-readability. >>>>> >>>>> 5. arm_set_pic_for_irq(int irq, device_t). This tells the MD >>>>> interrupt >>>>> layer to associate a given PIC device_t with an IRQ. That is all the >>>>> information the MD layer ever has about the IRQ mapping. >>>>> >>>>> Functions #1 and #2 are now implemented completely in ofwbus.c: there >>>>> are no callouts anywhere else and the interrupt mapping table is >>>>> maintained entirely internally to ofwbus (in its softc). In order to >>>>> implement ACPI, or some other strategy, you would implement >>>>> analogs to >>>>> functions #1 and #2 that live somewhere in the bus hierarchy that is >>>>> guaranteed to be above all devices that might want that type of >>>>> interrupt (e.g. in acpi0), and some analog to #3 that PIC drivers >>>>> implementing the mapping scheme would provide. >>>>> >>>>> Since the system interrupt code has no knowledge at all of interrupt >>>>> mapping, of any type, in this scheme, adding new mapping types is >>>>> trivial and can be done on a driver-by-driver basis if necessary >>>>> without changing KPI and without any other part of the system even >>>>> being aware. For example, GPIOs can use a completely different >>>>> mechanism if they want and can do setup purely in the GPIO controller >>>>> driver. You could have a method GPIO_GET_INTERRUPT_FOR_PIN() on a >>>>> GPIO >>>>> controller in which the GPIO controller allocates a generic IRQ, >>>>> assigns through some internal table just in the GPIO driver, and >>>>> returns to it to a consumer in some other device driver -- without a >>>>> GPIO mapping type, new bus functions, or modifications to the >>>>> platform >>>>> interrupt code. >>>>> >>>>> The control flow goes like this: >>>>> - Bus driver enumerates children, parses interrupts properties, calls >>>>> OFW_BUS_MAP_INTR() to get IRQs for them (as pre-r301453), adds to >>>>> interrupt list. >>>>> - ofwbus receives the OFW_BUS_MAP_INTR() call, allocates a blank >>>>> disconnected IRQ from the MD interrupt layer, and stores the mapping >>>>> from the new IRQ to the given interrupt specifier and phandle in an >>>>> internal table in ofwbus's softc. >>>>> NB: Nothing else happens here, like post-r301453. Changing >>>>> this does >>>>> not change any semantics of the API pre-r301453, which means it >>>>> remains fully compatible with PCI and PowerPC. Also, like >>>>> post-r301453, there is no involvement of nexus. >>>>> - PICs attach and call OFW_BUS_REGISTER_PIC(). ofwbus receives these >>>>> messages and adds a (device_t, phandle_t) mapping to a second >>>>> internal >>>>> table. Note that the interrupt layer does not need to handle PIC >>>>> registration anymore at all (except for the root PIC). >>>>> - Bus child eventually calls a function that tries to set the >>>>> interrupt up (e.g. bus_setup_intr()). That propagates up the bus >>>>> hierarchy, eventually getting to ofwbus. ofwbus notes the IRQ number, >>>>> looks it up in the table, looks up the appropriate PIC from the PIC >>>>> table, then: >>>>> A) calls arm_set_pic_for_irq(irq, pic_device_t) -- this is the >>>>> interrupt layer's only interaction with the mapping code. All it >>>>> deals >>>>> with is device_ts and abstract IRQ numbers. >>>>> B) calls PIC_MAP_OFW_INTR(pic, irq_number, interrupt-cells, >>>>> interrupt-specifier) to tell the PIC that the interrupt layer's IRQ >>>>> irq_number means the given specifier >>>>> C) finally, passes the call onto nexus, which will do whatever >>>>> would >>>>> normally happen (unmasking the interrupt, setting handlers, etc.) in >>>>> terms only of the abstract IRQ and the device_t assigned by ofwbus. >>>>> >>>>> You would implement ACPI just by doing a s/OFW/ACPI/g >>>>> search-and-replace above -- since the interrupt layer doesn't know >>>>> about OFW or ACPI or anything else, there is no need to touch it. >>>>> This >>>>> seems clean, simple, compartmentalized, preserves the existing API, >>>>> and should work on all of our various hardware. PowerPC can't quite >>>>> work with it yet without some multipass foo, but, since the API is >>>>> preserved, that transition can happen gradually without KPI changes. >>>>> For the same reason that it is API-preserving, I think this code is >>>>> also MFC-able. >>>>> -Nathan >>>> I think that we are slightly diverges in this place: >>>> - please note that PIC API (in kern/pic_if.m) is different from the >>>> one >>>> that PPC uses. >>> Yes, which is fine (this is machine-dependent code anyway). On >>> consideration, the PIC_MAP_OFW_INTR() function should probably be >>> called OFW_BUS_PIC_MAP_INTR() and live in ofw_bus_if.m anyway, then be >>> implemented by PICs. >>> >>>> - we must be able to store configuration data (original interrupt >>>> specifier) in all cases, not only for OFW. That's reason why I have >>>> proposed >>>> to create 'mapping table'. >>> It is stored in all cases, just not in the core interrupt code. I've >>> only mocked this up for OFW here. For ACPI, you would have the >>> equivalent table in acpi.c, along with ACPI_MAP_INTR(), >>> ACPI_REGISTER_PIC(), etc. in acpi_if.m and implemented in >>> dev/acpica/acpi.c. >>> >>> For GPIOs, you would have a mechanism that just traces however you are >>> representing GPIOs anyway. >>> >>>> Anyway, i think that we both talking about +/- same solution, only i >>>> want to move it from OFW specific level implemented at OFW bus >>>> level to >>>> bus/interrupt specifier format independent level implemented in >>>> subr_intr.c. >>> This implements the same API in any case (identical to that >>> pre-r301453), so the implementation doesn't really matter at all in >>> terms of my needs. >> Perfect. >>> That said, having it in the root bus for the mapping domain (ofwbus0, >>> acpi0) etc. seems cleaner to me, with no loss of functionality. The >>> core interrupt code (subr_intr.c or whatever) doesn't have any obvious >>> need to know anything at all about the mapping information so long as >>> it knows the PIC device_t that corresponds to every abstract IRQ so >>> that it can mask it or do other operations. Since, presumably, nothing >>> in an ACPI device tree references an interrupt in the OFW device tree >>> (if you even had both -- and how would you specify that, anyway?), >>> implementing the relevant bits one step up the bus hierarchy doesn't >>> change any behavior. >>> >>> And nothing can possibly be more flexible in terms of the mapping >>> table in subr_intr.c than not having a mapping table: you don't need >>> enums for mapping types, or unions that need to be expanded, breaking >>> KBI, or anything. You can delete all the PIC registration (and MSI) >>> code, all the switches, and all the unions from subr_intr.c and have a >>> totally mapping-mechanism-agnostic KPI. >>> >> Where you see "all the switches, and all the unions" in subr_intr.c? >> subr_intr.c uses nested structures approach, in exactly same way as is >> used in OFW bus. Moreover, subr_intr.c *IS* currently totally >> mapping-mechanism-agnostic KPI, and any form of mapping table must >> follow this rule. > > That was hyperbolic; my apologies. > > The point was that you don't need intr_map_data, or the > intr_map_data_type enum, this way. One of the nice things about that > is that you don't need to add more entries to the enum to add new > one-off mapping types. For example, the PS3 platform on PPC has its > own non-device-tree, non-ACPI bus description and interrupt system. > Needing to make new enums (or anything) like INTR_MAP_DATA_PS3 in > sys/bus.h seems a little silly, though hardly very bad. Hmm, right. Is something like solution for you? > I've attached a version of PowerPC's intr_machdep.c and pic_if.m that > fully implements this distributed-table scheme. The code ends up being > very short and clean (a third the number of lines of code as > kern/subr_intr.c, for example) and the diff to PowerPC, including the > new ofwbus.c code, ends up being net-negative. Yep, I read it very carefully. >> But allow me to make short summary: >> - we must support 3 'main' cases - OFW, ACPI and HINTS (for older arm >> and mips boards) based systems >> - single kernel must support all above cases, but only one can by >> 'active' (kernel must be able to select right one at runtime). >> - we must support 'direct' (interrupt specifier is defined by one of >> above methods) or 'indirect' (where interrupt is associated with other >> function - GPIO pin, but don't have direct description). >> - we must be able to access single physical pin by both methods, >> 'direct' and/or 'indirect'. >> - we must be able to add new interrupt type as simple as possible > > Agreed with all of this. > >> For interrupt controllers: >> - single controller must be able to parse multiple formats. 'direct' or >> 'indirect'. OFW or ACPI. ARM GIC must accept OFW or ACPI arguments (in >> single kernel), GPIO based interrupt controller must accept 'direct' or >> 'indirect' formats. >> >> For interrupt consumers: >> - 'direct' interrupts are easy >> - driver must be able to consume 'indirect' interrupt in 'root >> bus'/'mapping-mechanism' agnostic manner. >> For example, MMC driver must be able to get interrupt from CD gpio >> pin in all possible cases/combinations . >> Are we still connected? > > And this. > >> I don't think that all this is possible without single universal format >> of interrupt mapping specifier. >> And, if we must have universal format then why we needs different >> mapping databases? > > It actually works just fine in this mapping-table-in-the-root-bus > model. If you have an OFW-type of interrupt, it is set up by ofwbus.c. > Since everything that would use an OFW interrupt is a child of ofwbus, > this is totally indistinguishable from a global table from the > perspective of client code. For ACPI interrupts, they are set up by > acpi.c, which is indistinguishable from a global table for the same > reason. For hints -- and single-domain systems generally -- you can > just have the machine-dependent code assume that interrupts it doesn't > explicitly know about belong to the root PIC. This is what you call > the "direct" case. > > For the "indirect" case, there are as usual a few things you could do. > They match the set of things you would do in any implementation: > 1. Set up one or more global registries for "indirect" PICs, with > corresponding mapping methods, either as bus methods on some > high-level bus or on the machine-specific nexus, or just a global > function that you call. > 2. Use the global registry that you already have to have for GPIO > controllers and provide a mapping method on the GPIO controller > (GPIO_GET_INTERRUPT_FOR_PIN() or something) that returns a mapped IRQ. > I still don't think that this can works. Assume that i have driver with 2 interrupts, one is standard (OFW property based), second is GPIO, targeting same interrupt controller. First is allocated by bus_alloc_resource(), second by gpio_alloc_intr_resource(), so each resource is stored in different table. Then bus_setup_intr() is called, on both. So bus_setup_intr() must be able to select right table, right? But how? > One of the nice things about distributing the tables this way is that > you have lots of flexibility with things like these "indirect" > interrupts and are free to do things like #2 at will locally in some > machine-specific set of drivers. For example, in the PS3 code, I don't > need to add a new "PS3" mapping type *anywhere*. The ps3bus root > driver just has a table when it hands out interrupts and talks to > ps3pic internally. > -Nathan >>>> Most of your control flow can be implemented at general level as >>>> is, or >>>> already exist [intr_map_irq(), intr_pic_register()] . >>>> Also, impact for current PPC code is, by me, minimal. >>>> I can sketch my idea in more details, if you found it acceptable. >>> All ideas are fine -- and the solution does not need to apply to all >>> platforms anyway, so long as the OFW_BUS_MAP_INTR() semantics (and, >>> ideally, API) are preserved. I have prepared working patch (it's not full, but it works on Tegra), https://github.com/strejda/tegra/commit/2cf72e248877fb917c4fc618bcb6e46b7c1058a4 can you, please, take look on it? Also, please, take in account: - we have, currently, 20+ interrupt controllers converted to new INTRNG PIC API. - universal format of interrupt resources is generic part of this API. - I'm not ready to commit any PIC API change together with above patch - i hope that this is understandable. also, "we must be able to add new interrupt type as simple as possible" rule is very important for me. Adding new table (with implementation), one bus method and one PIC method for each new type is not *simple*. In any case, can we concentrate to above patch first? I'm ready to finish it in next few hours, then put it to phabricator for real review. Michal From owner-freebsd-arm@freebsd.org Sat Aug 6 16:44:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08954BB01C2; Sat, 6 Aug 2016 16:44:38 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1DEB1DBE; Sat, 6 Aug 2016 16:44:37 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u76GiRfI009180 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 6 Aug 2016 09:44:28 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> <57A09F34.4050400@FreeBSD.org> <57A30B72.7070809@FreeBSD.org> <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> <57A5F480.20309@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <1d63e3aa-1a2f-992f-ae83-656eb185d386@freebsd.org> Date: Sat, 6 Aug 2016 09:44:27 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57A5F480.20309@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaj1vDjAsIVaTSc89rfeKrjKezA8+PlavUyNWZYQ8IhS2paX50XUnK+e7jU+O+73wK23wQ1MK3EbzRJzxTvQQYaNUgnlMGRjvc= X-Sonic-ID: C;ysNCCvVb5hGydK/hcgQksw== M;4JiOCvVb5hGydK/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 16:44:38 -0000 On 08/06/16 07:30, Michal Meloun wrote: > Dne 04.08.2016 v 14:34 Nathan Whitehorn napsal(a): > [snip] >>>>>>> ------------ The following is a large parenthesis >>>>>>> ------------------- >>>>>>> >>>>>>> One other possible route here that would also work well would be to >>>>>>> make ofwbus.c MD (it's a trivial piece of code anyway, so we don't >>>>>>> gain a lot by sharing it) and implement ofw_bus_map_intr() >>>>>>> locally as >>>>>>> an ofwbus bus method. Then you could have the mapping table >>>>>>> stored in >>>>>>> ofwbus's softc -- the API was designed for this initially. You would >>>>>>> need MD extensions for doing PIC registration there (which is fine), >>>>>>> but that segregates all the OFW-specific information into >>>>>>> OFW-specific code and would let the bus methods and the OFW >>>>>>> interrupt >>>>>>> mapping table interact cleanly in the same place. This still >>>>>>> preserves the pre-r301453 API, makes PowerPC work, and maybe >>>>>>> address's skra@'s concern about extensibility and letting core >>>>>>> interrupt code know about FDT (or ACPI). I'd be happy to mock >>>>>>> this up >>>>>>> as well if you think it's a good approach. >>>>>>> >>>>>> [snip] >>>>>>> This has the following features: >>>>>>> - Existing OFW API and semantics unchanged >>>>>>> - As such, PowerPC, PCI, etc. work fine with no changes >>>>>>> - Details encapsulated in MD code, so individual platforms can >>>>>>> implement this however they like >>>>>>> - arm/arm/intr.c (or whatever) only needs a method to allocate a >>>>>>> fresh interrupt, with no state, and anoter to set the device_t >>>>>>> for an >>>>>>> interrupt sometime later. >>>>>>> - The internal table in the platform interrupt code has no knowledge >>>>>>> of any mappings whatsoever except having the appropriate device_t >>>>>>> for >>>>>>> the PIC stored with the interrupt vector. >>>>>>> - Device tree bits handled purely in device tree code >>>>>>> - No action need be taken on any mapping until the interrupt is >>>>>>> actually allocated/set up, like r301453 >>>>>>> - Easy to add more mapping mechanisms (e.g. ACPI) by having similar >>>>>>> enumeration-mechanism-specific code in the root bus for that mapping >>>>>>> mechanism. >>>>>>> >>>>>>> -------------- End parenthesis ------------------------------- >>>>>> Here's an implementation of the parenthesis I wrote on an airplane >>>>>> this afternoon. It should be complete, though has not been tested. >>>>>> The >>>>>> code is short and simple (+70 lines in ofwbus.c). This preserves the >>>>>> pre-r301453 API and semantics relative to drivers, which means >>>>>> PowerPC >>>>>> and PCI work out of the box, while keeping the semantics relative to >>>>>> the interrupt layer of r301453 (PIC methods only called on resource >>>>>> allocation, no allocatable IRQs on unattached PICs, encapsulation of >>>>>> OFW-specific code in OFW-specific bits of the tree). It turns out >>>>>> those two things are compatible, somewhat to my surprise, and that >>>>>> makes the result very clean. I like this approach and would be happy >>>>>> to move forward with it. There are five functions of interest: >>>>>> >>>>>> 1. OFW_BUS_MAP_INTR(). This has the semantics and API it has now: you >>>>>> pass an interrupt specifier and parent, you get back an IRQ. No >>>>>> changes. This is the core of the normal OFW interrupt API. >>>>>> >>>>>> 2. OFW_BUS_REGISTER_PIC(device_t pic, phandle_t phandle). This is a >>>>>> new function that PIC drivers are supposed to use to register control >>>>>> of an interrupt domain. This replaces machine-specific code like >>>>>> powerpc_register_pic() to allow the PIC table to be in a bus parent >>>>>> rather than in the interrupt core. >>>>>> >>>>>> 3. PIC_MAP_OFW_INTR(device_t pic, int irq, interrupt specifier). This >>>>>> is a new function that PIC drivers that know how to handle >>>>>> device-tree >>>>>> interrupt descriptors implement (analogous to various existing ones >>>>>> that vary by platform). It tells the PIC that the given abstract IRQ >>>>>> means the given opaque interrupt specifier. >>>>>> >>>>>> 4. arm_allocate_irq(int suggested). This allocates a new IRQ number >>>>>> not (yet) attached to a PIC, as in r301453. I've added a parameter >>>>>> that lets you pass a suggested number to try in case it is >>>>>> possible to >>>>>> make it match an interrupt pin or something for human-readability. >>>>>> >>>>>> 5. arm_set_pic_for_irq(int irq, device_t). This tells the MD >>>>>> interrupt >>>>>> layer to associate a given PIC device_t with an IRQ. That is all the >>>>>> information the MD layer ever has about the IRQ mapping. >>>>>> >>>>>> Functions #1 and #2 are now implemented completely in ofwbus.c: there >>>>>> are no callouts anywhere else and the interrupt mapping table is >>>>>> maintained entirely internally to ofwbus (in its softc). In order to >>>>>> implement ACPI, or some other strategy, you would implement >>>>>> analogs to >>>>>> functions #1 and #2 that live somewhere in the bus hierarchy that is >>>>>> guaranteed to be above all devices that might want that type of >>>>>> interrupt (e.g. in acpi0), and some analog to #3 that PIC drivers >>>>>> implementing the mapping scheme would provide. >>>>>> >>>>>> Since the system interrupt code has no knowledge at all of interrupt >>>>>> mapping, of any type, in this scheme, adding new mapping types is >>>>>> trivial and can be done on a driver-by-driver basis if necessary >>>>>> without changing KPI and without any other part of the system even >>>>>> being aware. For example, GPIOs can use a completely different >>>>>> mechanism if they want and can do setup purely in the GPIO controller >>>>>> driver. You could have a method GPIO_GET_INTERRUPT_FOR_PIN() on a >>>>>> GPIO >>>>>> controller in which the GPIO controller allocates a generic IRQ, >>>>>> assigns through some internal table just in the GPIO driver, and >>>>>> returns to it to a consumer in some other device driver -- without a >>>>>> GPIO mapping type, new bus functions, or modifications to the >>>>>> platform >>>>>> interrupt code. >>>>>> >>>>>> The control flow goes like this: >>>>>> - Bus driver enumerates children, parses interrupts properties, calls >>>>>> OFW_BUS_MAP_INTR() to get IRQs for them (as pre-r301453), adds to >>>>>> interrupt list. >>>>>> - ofwbus receives the OFW_BUS_MAP_INTR() call, allocates a blank >>>>>> disconnected IRQ from the MD interrupt layer, and stores the mapping >>>>>> from the new IRQ to the given interrupt specifier and phandle in an >>>>>> internal table in ofwbus's softc. >>>>>> NB: Nothing else happens here, like post-r301453. Changing >>>>>> this does >>>>>> not change any semantics of the API pre-r301453, which means it >>>>>> remains fully compatible with PCI and PowerPC. Also, like >>>>>> post-r301453, there is no involvement of nexus. >>>>>> - PICs attach and call OFW_BUS_REGISTER_PIC(). ofwbus receives these >>>>>> messages and adds a (device_t, phandle_t) mapping to a second >>>>>> internal >>>>>> table. Note that the interrupt layer does not need to handle PIC >>>>>> registration anymore at all (except for the root PIC). >>>>>> - Bus child eventually calls a function that tries to set the >>>>>> interrupt up (e.g. bus_setup_intr()). That propagates up the bus >>>>>> hierarchy, eventually getting to ofwbus. ofwbus notes the IRQ number, >>>>>> looks it up in the table, looks up the appropriate PIC from the PIC >>>>>> table, then: >>>>>> A) calls arm_set_pic_for_irq(irq, pic_device_t) -- this is the >>>>>> interrupt layer's only interaction with the mapping code. All it >>>>>> deals >>>>>> with is device_ts and abstract IRQ numbers. >>>>>> B) calls PIC_MAP_OFW_INTR(pic, irq_number, interrupt-cells, >>>>>> interrupt-specifier) to tell the PIC that the interrupt layer's IRQ >>>>>> irq_number means the given specifier >>>>>> C) finally, passes the call onto nexus, which will do whatever >>>>>> would >>>>>> normally happen (unmasking the interrupt, setting handlers, etc.) in >>>>>> terms only of the abstract IRQ and the device_t assigned by ofwbus. >>>>>> >>>>>> You would implement ACPI just by doing a s/OFW/ACPI/g >>>>>> search-and-replace above -- since the interrupt layer doesn't know >>>>>> about OFW or ACPI or anything else, there is no need to touch it. >>>>>> This >>>>>> seems clean, simple, compartmentalized, preserves the existing API, >>>>>> and should work on all of our various hardware. PowerPC can't quite >>>>>> work with it yet without some multipass foo, but, since the API is >>>>>> preserved, that transition can happen gradually without KPI changes. >>>>>> For the same reason that it is API-preserving, I think this code is >>>>>> also MFC-able. >>>>>> -Nathan >>>>> I think that we are slightly diverges in this place: >>>>> - please note that PIC API (in kern/pic_if.m) is different from the >>>>> one >>>>> that PPC uses. >>>> Yes, which is fine (this is machine-dependent code anyway). On >>>> consideration, the PIC_MAP_OFW_INTR() function should probably be >>>> called OFW_BUS_PIC_MAP_INTR() and live in ofw_bus_if.m anyway, then be >>>> implemented by PICs. >>>> >>>>> - we must be able to store configuration data (original interrupt >>>>> specifier) in all cases, not only for OFW. That's reason why I have >>>>> proposed >>>>> to create 'mapping table'. >>>> It is stored in all cases, just not in the core interrupt code. I've >>>> only mocked this up for OFW here. For ACPI, you would have the >>>> equivalent table in acpi.c, along with ACPI_MAP_INTR(), >>>> ACPI_REGISTER_PIC(), etc. in acpi_if.m and implemented in >>>> dev/acpica/acpi.c. >>>> >>>> For GPIOs, you would have a mechanism that just traces however you are >>>> representing GPIOs anyway. >>>> >>>>> Anyway, i think that we both talking about +/- same solution, only i >>>>> want to move it from OFW specific level implemented at OFW bus >>>>> level to >>>>> bus/interrupt specifier format independent level implemented in >>>>> subr_intr.c. >>>> This implements the same API in any case (identical to that >>>> pre-r301453), so the implementation doesn't really matter at all in >>>> terms of my needs. >>> Perfect. >>>> That said, having it in the root bus for the mapping domain (ofwbus0, >>>> acpi0) etc. seems cleaner to me, with no loss of functionality. The >>>> core interrupt code (subr_intr.c or whatever) doesn't have any obvious >>>> need to know anything at all about the mapping information so long as >>>> it knows the PIC device_t that corresponds to every abstract IRQ so >>>> that it can mask it or do other operations. Since, presumably, nothing >>>> in an ACPI device tree references an interrupt in the OFW device tree >>>> (if you even had both -- and how would you specify that, anyway?), >>>> implementing the relevant bits one step up the bus hierarchy doesn't >>>> change any behavior. >>>> >>>> And nothing can possibly be more flexible in terms of the mapping >>>> table in subr_intr.c than not having a mapping table: you don't need >>>> enums for mapping types, or unions that need to be expanded, breaking >>>> KBI, or anything. You can delete all the PIC registration (and MSI) >>>> code, all the switches, and all the unions from subr_intr.c and have a >>>> totally mapping-mechanism-agnostic KPI. >>>> >>> Where you see "all the switches, and all the unions" in subr_intr.c? >>> subr_intr.c uses nested structures approach, in exactly same way as is >>> used in OFW bus. Moreover, subr_intr.c *IS* currently totally >>> mapping-mechanism-agnostic KPI, and any form of mapping table must >>> follow this rule. >> That was hyperbolic; my apologies. >> >> The point was that you don't need intr_map_data, or the >> intr_map_data_type enum, this way. One of the nice things about that >> is that you don't need to add more entries to the enum to add new >> one-off mapping types. For example, the PS3 platform on PPC has its >> own non-device-tree, non-ACPI bus description and interrupt system. >> Needing to make new enums (or anything) like INTR_MAP_DATA_PS3 in >> sys/bus.h seems a little silly, though hardly very bad. > Hmm, right. > Is something like solution for you? Or just the existing machine/intr_whatever_it_is.h. >> I've attached a version of PowerPC's intr_machdep.c and pic_if.m that >> fully implements this distributed-table scheme. The code ends up being >> very short and clean (a third the number of lines of code as >> kern/subr_intr.c, for example) and the diff to PowerPC, including the >> new ofwbus.c code, ends up being net-negative. > Yep, I read it very carefully. >>> But allow me to make short summary: >>> - we must support 3 'main' cases - OFW, ACPI and HINTS (for older arm >>> and mips boards) based systems >>> - single kernel must support all above cases, but only one can by >>> 'active' (kernel must be able to select right one at runtime). >>> - we must support 'direct' (interrupt specifier is defined by one of >>> above methods) or 'indirect' (where interrupt is associated with other >>> function - GPIO pin, but don't have direct description). >>> - we must be able to access single physical pin by both methods, >>> 'direct' and/or 'indirect'. >>> - we must be able to add new interrupt type as simple as possible >> Agreed with all of this. >> >>> For interrupt controllers: >>> - single controller must be able to parse multiple formats. 'direct' or >>> 'indirect'. OFW or ACPI. ARM GIC must accept OFW or ACPI arguments (in >>> single kernel), GPIO based interrupt controller must accept 'direct' or >>> 'indirect' formats. >>> >>> For interrupt consumers: >>> - 'direct' interrupts are easy >>> - driver must be able to consume 'indirect' interrupt in 'root >>> bus'/'mapping-mechanism' agnostic manner. >>> For example, MMC driver must be able to get interrupt from CD gpio >>> pin in all possible cases/combinations . >>> Are we still connected? >> And this. >> >>> I don't think that all this is possible without single universal format >>> of interrupt mapping specifier. >>> And, if we must have universal format then why we needs different >>> mapping databases? >> It actually works just fine in this mapping-table-in-the-root-bus >> model. If you have an OFW-type of interrupt, it is set up by ofwbus.c. >> Since everything that would use an OFW interrupt is a child of ofwbus, >> this is totally indistinguishable from a global table from the >> perspective of client code. For ACPI interrupts, they are set up by >> acpi.c, which is indistinguishable from a global table for the same >> reason. For hints -- and single-domain systems generally -- you can >> just have the machine-dependent code assume that interrupts it doesn't >> explicitly know about belong to the root PIC. This is what you call >> the "direct" case. >> >> For the "indirect" case, there are as usual a few things you could do. >> They match the set of things you would do in any implementation: >> 1. Set up one or more global registries for "indirect" PICs, with >> corresponding mapping methods, either as bus methods on some >> high-level bus or on the machine-specific nexus, or just a global >> function that you call. >> 2. Use the global registry that you already have to have for GPIO >> controllers and provide a mapping method on the GPIO controller >> (GPIO_GET_INTERRUPT_FOR_PIN() or something) that returns a mapped IRQ. >> > I still don't think that this can works. > Assume that i have driver with 2 interrupts, one is standard (OFW > property based), second is GPIO, targeting same interrupt controller. > First is allocated by bus_alloc_resource(), second by > gpio_alloc_intr_resource(), so each resource is stored in different table. > Then bus_setup_intr() is called, on both. So bus_setup_intr() must be > able to select right table, right? But how? The interrupt defined by the GPIO controller from a GPIO property (as opposed to an interrupt property) could be defined, in general, in four ways: 1. You have a bus method on the GPIO controller that returns a pre-mapped IRQ. Something like GPIO_INTERRUPT_FOR_PIN(). The GPIO properties I have seen don't have standard names so this would need to be done by the child. As a result, you don't need it to work before PIC attachment (or GPIO attachment) and can directly call methods on the GPIO controller. This kind of API has the nice feature that the GPIO controller can return errors early if that pin doesn't actually support interrupts, which is not a concern with normal interrupts property. The IRQ would be mapped internally by the controller when you do GPIO_INTERRUPT_FOR_PIN() and so ofwbus.c would pass it through to nexus (you'd need to remove a KASSERT from my code), which would then go to the interrupt code, which would see the device_t assigned earlier and pass through all operations appropriately. 2. Identical to the first paragraph of (1), except the bus method resolves to an interrupt-parent, specifier pair passed to OFW_BUS_MAP_INTR() rather than an internal mapping in the GPIO controller. This proceeds as normal for OF interrupts thereafter. API is the same as (1). 3. Some global helper function that transforms GPIO specifiers into some other domain (OF, ACPI) without talking to the GPIO controller. I think this is fragile and a bad idea in any case, though would also work as well (or as badly) here as in any other scheme. 4. A GPIO interrupt domain with specifier, like you have currently. You'd have to implement this mapping table in nexus (potentially as a thin wrapper for some code in intr.c or intr_gpio.c or whatever) as a global table as now or as in the first patch I sent. ofwbus.c would, like (1) pass through such requests. This is a perfectly good interface. So I don't think you lose anything by putting the table in ofwbus.c. All four cases would have the same API no matter where the mapping table is. The only non-idiomatic case is #4, which would require some shims, but those shims are wholly identical to the shims you would need if you didn't do OF/FDT interrupts this way. The larger point is that, since all four cases would have identical APIs in either case, it doesn't much matter how it is implemented now. If we picked one method and wanted to change later, we lose nothing and the change can be MFC-ed at will since it has no effect on KPI. > >> One of the nice things about distributing the tables this way is that >> you have lots of flexibility with things like these "indirect" >> interrupts and are free to do things like #2 at will locally in some >> machine-specific set of drivers. For example, in the PS3 code, I don't >> need to add a new "PS3" mapping type *anywhere*. The ps3bus root >> driver just has a table when it hands out interrupts and talks to >> ps3pic internally. >> -Nathan >>>>> Most of your control flow can be implemented at general level as >>>>> is, or >>>>> already exist [intr_map_irq(), intr_pic_register()] . >>>>> Also, impact for current PPC code is, by me, minimal. >>>>> I can sketch my idea in more details, if you found it acceptable. >>>> All ideas are fine -- and the solution does not need to apply to all >>>> platforms anyway, so long as the OFW_BUS_MAP_INTR() semantics (and, >>>> ideally, API) are preserved. > I have prepared working patch (it's not full, but it works on Tegra), > https://github.com/strejda/tegra/commit/2cf72e248877fb917c4fc618bcb6e46b7c1058a4 > can you, please, take look on it? Change looks great to me at first pass. Thank you for working on it! > Also, please, take in account: > - we have, currently, 20+ interrupt controllers converted to new INTRNG > PIC API. > - universal format of interrupt resources is generic part of this API. > - I'm not ready to commit any PIC API change together with above patch - > i hope that this is understandable. Yes, of course. Also, as far as I can tell, there's no reason to change the PIC API on ARM/MIPS anyway from the current INTRNG API. I think there are some minor simplifications you could do, but there's no need for them, and you can implement absolutely any of the APIs we have discussed in this thread in terms of the current pic_if.m with no problems. > > also, > "we must be able to add new interrupt type as simple as possible" rule > is very important for me. Adding new table (with implementation), one > bus method and one PIC method for each new type is not *simple*. Fair enough! I don't think we need that for, e.g., GPIOs (see cases 1-2 above), just for bus enumeration schemes (ACPI, OFW are probably the only ones) that usually require a ton of this kind of thing anyway. But, fundamentally, it doesn't matter. There are three important things from my end: 1. That it is possible to, at bus enumeration time, permanently assign an IRQ to an interrupt specifier from OFW/ACPI. 2. That that assignment not depend on having the PIC attached yet. 3. That the implementation details of that mechanism be reasonably abstracted so that they can change later or vary platform to platform. Whether mapping tables are in some central place (subr_intr.c) or in the parent bus, how the PIC API works, whether they are stored in that table in the form of a union or in different tables, doesn't matter for those three at all. And, with a constant API (3) we can even change our minds later without a lot of hassle. > In any case, can we concentrate to above patch first? I'm ready to > finish it in next few hours, then put it to phabricator for real review. Sounds good. As I said, first pass looks perfect to me. I'll look in detail once it hits phabricator. -Nathan > > Michal > From owner-freebsd-arm@freebsd.org Sat Aug 6 16:58:50 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68AABBB0552 for ; Sat, 6 Aug 2016 16:58:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C7EF15EC for ; Sat, 6 Aug 2016 16:58:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id 38so325687074iol.0 for ; Sat, 06 Aug 2016 09:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eGdiIVVZoY7D8RF1q9koNMFhBK16ze1HkKAN9Jb9Ids=; b=V0xo72+Kk8pa6zzvnvabxqUozxITJxxkVnx+3lnbZqTEigCuCrTOmFUIfMhWkyOulp klAl3v3NcQZBexfQJz0mjJ3BBX1cwFcHGaIHASdHLVMHr4XWM8G7E1gcZBOA/LWfaoL/ 1/s2bcn8UOZvMjMKvUm+6lPXts47wtINXD1WGKhwKbO/6h+umoRJE79dr8gkKo93Se+M 93RmdK5CTuPqnD/0vew1jTXT38MEFzDq0b+is6JggXqMpe8yUMvUxLwerW10RAMygfil MnB58NXfU3NJ0njKDLh/zWA07kbjJtHiY0rLHNTaF2ONhrREWAnGQRFfnsDWzBsDid6K fSJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eGdiIVVZoY7D8RF1q9koNMFhBK16ze1HkKAN9Jb9Ids=; b=EFOE6WBiT++c9PfY1LZiDv0vMirflY7A5nrzKJuzbUVR1zTCZF88XCq1hNWZKz8zbU bUH0/XPWfnr5S5g/xr7AcPeoPPeOOFzi7aDlYfgbl5Zoydu2bLT2pZg751FktRWUYQKB P5/0eynjwpcL6s4EOTqwq1xbjQD2BL5uKpknpjwppwVFJAt/A/QPX3dW2LX7OYOJNJiG ibdOIEzLd+YOsreRtI86t9mRCHI8+PRxwJ1rd9T5FZPkqt+duV7zM4PODr5mhpWAWlur wgd5s8ryMUgkx541dQhDGC1+sF8tZr9deINh8EBP9AdIb2J2hsqVNw0brlu5Wi6zZt3t eyTw== X-Gm-Message-State: AEkooutuk3BXSrPZprmzGgjFcYJkIxtigTopn+CLRBEWt4lnQEE5xvylSLfPwtHkQS24VH8pH4/IYzBV2PWJDA== X-Received: by 10.107.9.39 with SMTP id j39mr84327957ioi.73.1470502729575; Sat, 06 Aug 2016 09:58:49 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.105 with HTTP; Sat, 6 Aug 2016 09:58:48 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: <1d63e3aa-1a2f-992f-ae83-656eb185d386@freebsd.org> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> <57A09F34.4050400@FreeBSD.org> <57A30B72.7070809@FreeBSD.org> <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> <57A5F480.20309@FreeBSD.org> <1d63e3aa-1a2f-992f-ae83-656eb185d386@freebsd.org> From: Warner Losh Date: Sat, 6 Aug 2016 10:58:48 -0600 X-Google-Sender-Auth: _0BEYsZVKtprYz0QGNWpalXtUEk Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 16:58:50 -0000 On Sat, Aug 6, 2016 at 10:44 AM, Nathan Whitehorn wrote: > Fair enough! I don't think we need that for, e.g., GPIOs (see cases 1-2 > above), just for bus enumeration schemes (ACPI, OFW are probably the only > ones) that usually require a ton of this kind of thing anyway. But, > fundamentally, it doesn't matter. There are three important things from my > end: > 1. That it is possible to, at bus enumeration time, permanently assign an > IRQ to an interrupt specifier from OFW/ACPI. > 2. That that assignment not depend on having the PIC attached yet. > 3. That the implementation details of that mechanism be reasonably > abstracted so that they can change later or vary platform to platform. > > Whether mapping tables are in some central place (subr_intr.c) or in the > parent bus, how the PIC API works, whether they are stored in that table in > the form of a union or in different tables, doesn't matter for those three > at all. And, with a constant API (3) we can even change our minds later > without a lot of hassle. First, I hate mapping tables at the nexus, unless they are created dynamically at run time. There's too much variation between boards, SoCs, etc to have that code live in the nexus otherwise. They simply don't scale. This board has interrupts 1-16 wired this way, but that board didn't do that and has an external PIC. This SoC based on Cortext A uses the GPIC, while that one based on the same Cortext A chose to use Atmel's PIC. Perhaps I'm misunderstanding something here as to what is meant by a table though. Next, In your list there's another dependency that's implicit but maybe not called out. You can have PICs that cascade into other PICs, or GPIO controllers that need to enable external PIC-like things before they can route interrupts from things that are downstream (interrupt wise) from them. Maybe I'm just hung up on the phrase "the PIC" and it really means "whatever complex thing or things handles getting the interrupt routed to the CPU." I don't see this design so much on basic eval boards, but do see it in more complex boards that control complicated things. Generally, though, I like the direction things are going. Warner From owner-freebsd-arm@freebsd.org Sat Aug 6 19:51:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B417BB15F9; Sat, 6 Aug 2016 19:51:52 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3022E1E52; Sat, 6 Aug 2016 19:51:51 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u76JpmSS029471 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 6 Aug 2016 12:51:49 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Warner Losh References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> <57A09F34.4050400@FreeBSD.org> <57A30B72.7070809@FreeBSD.org> <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> <57A5F480.20309@FreeBSD.org> <1d63e3aa-1a2f-992f-ae83-656eb185d386@freebsd.org> Cc: Michal Meloun , "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <2e638a0a-0d99-1aa7-4912-1015c8e2e947@freebsd.org> Date: Sat, 6 Aug 2016 12:51:48 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYiBw9w+Tgg90SzBC0zIR0jsgnJmBRZw2UjnNvjoQTh/ZrmBTY+xZx8J7p6LHudlKRSLuC8Sx1P4ymrcy4zijtl7D6465MoAnc= X-Sonic-ID: C;2CBQNg9c5hGs+K/hcgQksw== M;jsGjNg9c5hGs+K/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 19:51:52 -0000 On 08/06/16 09:58, Warner Losh wrote: > On Sat, Aug 6, 2016 at 10:44 AM, Nathan Whitehorn > wrote: > >> Fair enough! I don't think we need that for, e.g., GPIOs (see cases 1-2 >> above), just for bus enumeration schemes (ACPI, OFW are probably the only >> ones) that usually require a ton of this kind of thing anyway. But, >> fundamentally, it doesn't matter. There are three important things from my >> end: >> 1. That it is possible to, at bus enumeration time, permanently assign an >> IRQ to an interrupt specifier from OFW/ACPI. >> 2. That that assignment not depend on having the PIC attached yet. >> 3. That the implementation details of that mechanism be reasonably >> abstracted so that they can change later or vary platform to platform. >> >> Whether mapping tables are in some central place (subr_intr.c) or in the >> parent bus, how the PIC API works, whether they are stored in that table in >> the form of a union or in different tables, doesn't matter for those three >> at all. And, with a constant API (3) we can even change our minds later >> without a lot of hassle. > First, I hate mapping tables at the nexus, unless they are created > dynamically at run time. There's too much variation between boards, > SoCs, etc to have that code live in the nexus otherwise. They simply > don't scale. This board has interrupts 1-16 wired this way, but that > board didn't do that and has an external PIC. This SoC based on > Cortext A uses the GPIC, while that one based on the > same Cortext A chose to use Atmel's PIC. Perhaps I'm > misunderstanding something here as to what is meant by a table > though. The table in question is just a mapping of abstract IRQ numbers to the corresponding interrupt specifier and parent. For example, 5: <&gicX, 7 2> Where 5 is the (potentially arbitrary) assigned number for the system corresponding to whatever <7 2> means on gic0. The table is built on the fly so that OFW bus nodes can specify interrupts as something <&gicX, 7 2> and get back scalars that work with rman and the PCI APIs and all the other places that want definitions of interrupts as scalars. It naturally handles all of your examples. The discussion here is whether to: a) keep an OFW/FDT-specific table like this in ofwbus.c (and analogs for ACPI, etc. in their respective places) b) keep a table that maps numbers to some union of OFW/ACPI/whatever data in nexus or intr.c or some global place It doesn't matter much from a functionality perspective (or an API perspective) either way. The question is more about which is easier to maintain and extend long-term. Since the API doesn't change either way, we're free to decide incorrectly and revisit it at will later with little consequence. > Next, In your list there's another dependency that's implicit > but maybe not called out. You can have PICs that cascade into > other PICs, or GPIO controllers that need to enable external > PIC-like things before they can route interrupts from things > that are downstream (interrupt wise) from them. Maybe I'm > just hung up on the phrase "the PIC" and it really means > "whatever complex thing or things handles getting the > interrupt routed to the CPU." I don't see this design so much > on basic eval boards, but do see it in more complex boards > that control complicated things. Yes. We've supported this forever on PPC (where it is very common) and it works here too. The implementation is really simple. First, here's an explanation of the general interrupt mapping system, for context: Let's suppose you have some interrupt hierarchy like this: CPU <- pic0 <- some device PIC0 has a bunch of interrupt pins. As you enumerate the system, the code encounters interrupt specifiers like <&pic0, 3 1>, <&pic0, 4, 1>, <&pic1, 3, 2>. Through OFW_BUS_MAP_INTR(), the bus enumeration code turns these into some arbitrary scalar IRQs assigned by OFW_BUS_MAP_INTR(). The mapping from the (interrupt parent, specifier) tuple to that assigned scalar IRQ is stored somewhere (see above) for later. When the bus devices that use those IRQs attach, they call bus_activate_resource() and bus_setup_intr(). At this point, some code close to the root of the hierarchy (again, see above for exactly where) looks up the corresponding vector specifier in the table, looks up the registered PIC corresponding to the interrupt parent key, and tells the driver attached to the interrupt parent to think of the scalar IRQ as meaning whatever string of numbers it saw earlier. It also tells the machine-dependent interrupt layer that the given scalar IRQ is handled by the device_t for the PIC so that it can ask the PIC to mask/unmask/bind/etc. the interrupt. When PICs attach, they register themselves with whatever bus layer is doing this mapping to say that a given interrupt parent key (the phandle for OFW/FDT) corresponds to the device_t for the PIC. The PIC attached directly to the CPU's interrupt pin[s] (pic0 here) also registers itself somehow with the MD interrupt system. On PPC, there is a global device_t called "root_pic" that the driver sets. When "some device" signals an interrupt, pic0 (the hardware) signals the CPU. The CPU signals the kernel. The MD interrupt layer notices and calls the driver for pic0 (the root PIC). That code inspects whatever registers on PIC0 give it the interrupt line and then signals the MD interrupt layer (let's say by calling a function called arm_dispatch_irq(int irq)) with the corresponding scalar IRQ. That then invokes the corresponding filters and/or ithreads. So how does this change with cascaded PICs? Very little. Let's suppose you have some interrupt hierarchy like this: CPU <- pic0 <- pic1 <- some device PIC0 has a bunch of interrupt pins, one of which is connected to pic1, which provides a bunch more interrupt pins. Both pic0 and pic1 register themselves with the bus layer by the appropriate handles and get their mask/unmask/bind functions called by the interrupt layer during interrupt setup for interrupts they handle. PIC0 registers itself as the root during attachment because it notices that it does not have any interrupts in its resource list. Child PICs, on the other hand, have interrupt properties in the FDT corresponding to the pin on pic0 that is attached to pic1. These get assigned as normal through newbus and the child PIC (pic1) calls bus_setup_intr and registers a filter handler. When "some device" signals an interrupt, pic1 drives a line on pic0, which drives a line on the CPU. The driver for PIC0 calls arm_dispatch_irq() with the IRQ corresponding to pic1, which calls pic1's interrupt handler. Since filter handlers run in primary interrupt context, pic1's interrupt handler can look exactly like what pic0 does when signalled by the interrupt layer: it runs through its registers, finds any lines with active interrupts, then calls arm_dispatch_irq() with the appropriate corresponding scalar IRQ. The nice thing here is that cascaded PICs require zero special handling by the system. You can just treat them as normal interrupts, with no special methods required in the bus layer, the interrupt system, or the PIC driver. -Nathan > > Generally, though, I like the direction things are going. > > Warner >