Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
fre 2013-06-07 klockan 09:02 +0100 skrev luke.leighton: ok. so. we come back to the question again: what shall i propose to them that they consider doing, and what benefit would it be to them to do so? Just tell them that the kernel is moving to a different configuration syntax called Device Tree, but apart from updating kernel drivers to the new way of configuring things it only have minor impact on their envionment. It is still possible to use the fex file for all board configuration details, only requires a small tool for translating fex to device tree. The change only impacts kernel, and a small change to their SDK build scripts to also build the device tree from the fex. It is no big deal really in structural terms. There is far bigger structural changes in the kernel which coincides with this and will require some developer time to adjust for. Had they upstreamed their changes earlier then... Regards Henrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370600817.9983.7.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 13:19 +0100 skrev luke.leighton: mass-volume tablet, mass-volume IPTV box. android OS, nothing else. Which still includes a number of possible configurations with different i2c, spi, usb etc devices connected on the board. Because Allwinner is not using mainline methods for configuration their customers are stuck in only selecting between a very limited set of Allwinner compatible auxillary chips (g-sensors, led controls, wifi modules, gps modules etc) in their designs. By using DT their customers are free to choose any device supported mainline. Regards Henrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370544282.31564.5.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 13:22 +0100 skrev luke.leighton: idea: hook into devicetree gpio functions to allow script-fex gpio functions to gain access in a separate module? that sort of thing. No. Drop FEX from the kernel, use DT. There is no reason why the kernel shold care about the FEX format. Translate from FEX to DT where needed in the firmware image build process to allow Allwinner to keep the FEX as hardware description to the ODMs. Regards Henrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370544712.31564.11.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton: And Then Some, stephen. there are two versions of u-boot being used: one is the community-assembled [GPL-compliant] one, and the other includes a [as-of-a-few-days-ago-but-no-longer, yay!] formerly-GPL-violating one from allwinner. the community-based one *doesn't* have fex integration (i don't think, but henrik will know for sure), but the allwinner one definitely does. Correct. and then there's the boot0 and boot1 loaders, these *do* have fex integration: they're absolutely tiny and they're designed to fit into the 1st level cache. the job of these bootloaders is to set up the DDR3 RAM timings (so that you can access DRAM!!) and to then decide whether to load from NAND, SD/MMC etc. and many other things. no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM (not cache), but boot1 is on pair with u-boot in size and runs from DRAM. boot0 do NOT read the script.bin at all. It can't, there isn't space fore it. There is tools in the build process that reads the script.bin and adds some information to a header of boot0, but it's irrelevant to the device tree question. Exactly the same can be done from a device tree, or from a fex, it does not matter. even most of boot1 is not using script.bin. The important parameters are all recorded in a heaeder of boot1 when the image is composed using the Allwinner pack tools. Currently based on those tools reading script.bin to prepare the boot1 part of the image. these boot0 and boot1 loaders are themselves configureable so that you can specify, through script.fex, what GPIO is to be the reset key and so on. that's a much simplified story btw. No. That info is in the boot0 and boot1 file headers, not script.bin. so the point is: if anyone wishes me to propose to allwinner that they convert over to devicetree, or any other proposal which involves significant low-level changes to their working practices that could potentially have a massive knock-on effect onto their multi-million-dollar clients, it had better be a damn good story. Calm down. It isn't really a significant difference to them outside of the kernel. They do not need to change any of their configuraiton methods, only a small toolchain change in how the resultig images are built to have a corresponding device tree built. But it is a fair bit of one-time changes kernel side. And some scratching to figure out how to use/improve/ignore the stuff being mainlined. Regards Henrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370469574.18839.33.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ons 2013-06-05 klockan 22:15 +0100 skrev Luke Kenneth Casson Leighton: what we do not want to happen is that they see upstream patches being submitted, they merge them into their internal tree (which to date has had zero upstream changes: they're currently only just getting round to doing 3.4 as we speak), and they *completely* ignore *absolutely everything* that's being done by the community, duplicating yet another set of device drivers (named drivers/*/sun8i_* and so on). Well, that will obviously happen one or two more rounds, a bit depending on which kernel releases Android will use. But I hope the Allwinner kernel team will rethink when they hit more current kernels. this proposal is a start: however what you have to bear in mind is that you now have to convince a very busy company that it is in their best interests to disrupt their schedule, to drop their existing working practices, to tell all their customers please stop using the existing tools and please use these ones instead. Why? you also need to convince the creators of the proprietary firmware-flashing tools livesuite and phoenix to *also* convert their tools over to the new proposed idea. Why? can you provide such a supporting argument which would convince allwinner to accept the modifications to their working practices that you propose? It does not really need to be such big modifications to their working practices. Their configuration working practices is all built around the fex file, and the new practices can be 0. Assuming kernel drivers gets ported over to using device tree. 1. Do configuration as you have always done in the .fex 2. Modify the build script to build a device tree from the fex + template, in addition to script.bin. 3. Tell u-boot to load the device tree for the kernel. That's it really. licesuit do not modify script.bin. script.bin is compiled from the .fex at image creation time. A couple more lines in the build script (and a suitable translation tool) and there is also a device tree built and installed and you get a nice and smoot transition. Device tree on ARM's goal is to achieve a single kernel across vendors, not just a single kernel for a single vendor. you'll be aware that i've mentioned a number of times and have discussed at some length why this is a goal that is completely impossible to achieve [*1]. sadly. Here I disagree. It is possible. Not across all vendors but a significant share. Regards enrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370468873.18839.22.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ons 2013-06-05 klockan 16:54 -0600 skrev Stephen Warren: 1) Put all the parameters in the U-Boot configuration header. This is normal. Yes, we do so today for U-Boot SPL. But this won't fit very well with the Allwinner ODM workflow where one binary image works on a wide range of board configurations probed while flashing the image to the board, but on the other hand there is no real need for them to use u-boot as the primary boot loader, just keep using boot0 + boot1 + u-boot chain as they have always done. 2) Read some data structure at run-time. This data structure could in theory be some SoC-specific blob format (e.g. the packed version of information that some tool extracts from FEX/DT), a whole FEX blob, or device tree. This is likely to happen for the sunxi U-Boot SPL due to the sheer amount of boards involved, and is done to some extents for other boards as well. In the SPL there generally isn't room for full DT support. Main u-boot HW configuration could be done runtime via DT alone but we are not quite there yet, nothing major missing however other than getting it done. Regards Henrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370474115.20454.26.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
no john - they've only added it to the multiplexed sections of the
drivers which they themselves have written. such as
drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
arch/arm/mach-sun{N}i and so on.
And a number of SPI device drivers, USB device drivers, vendor provided
device drivers, ..
the script.fex system deals with the pinmux issue in a very neat way that:
a) has very little impact on the rest of the kernel tree [citation
needed! i'm saying that: could someone please confirm if it's true]
Not really the case. Actually the opposite. DT have this as well, and
integrated in device probing. Allwinner need to hack every driver used
to add their gpio requests to have pinmuxing triggered.
It is just layered a bit differently when using DT.
Regards
Henrik
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370475609.20454.44.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 00:52 +0100 skrev luke.leighton: How is the Allwinner kernel going to load the driver for the pca9532? The mainline pca9532 driver does not understand fex so it can't read the necessary initialization data. jon: you're immediately outside of the target market for which allwinner designed and deployed script.fex. You missed the point. Mainlne Kernel drivers do take advantege of DT to ease their bindings and configuration, much further than the fex can express. The exact same thing is experienced in designing a tablet. You add a pheriperal device, and it needs to be configured somehow. DT does this and it integrated in the kernel framework. fex also attemtps in doing part of this, but lacks integration and requires much more driver patching to fly. And I don't see how you can say that pca9532 is off the grid in the target market. It would fit nicely as a key backlight / edge colour controller in a tablet to give the tablet a personal touch. fex is only supported on the small number of peripheral chips Allwinner has blessed. Use any chip outside of that set and it isn't going to boot. eeexactly. i did say target market. Yes you repeat that over an over. But what does it mean? I think what you really mean is something else more in the line of ODMs not allowed to step outside a very narrow range of possible designs or using less than a handful approved providers, typical lockin conditions. I don't know what you really mean here, only that it's not target market. Regards Henrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370477756.20454.65.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton: Not really the case. Actually the opposite. DT have this as well, and integrated in device probing. Allwinner need to hack every driver used to add their gpio requests to have pinmuxing triggered. augh. ok. solutions. what are the solutions here? What I said before. Go with DT for the kernel. There is no need for two configuration mechanisms doing the same thing. Disguise it in fex form (and translator) if too hard for people with a DOS editior to configure. Regards Henrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370477958.20454.68.camel@localhost
Re: [Arm-netbook] ARM port(s) BoF at DebConf
tis 2012-07-24 klockan 00:02 +0100 skrev Luke Kenneth Casson Leighton: rright. many thanks to the person on arm-netbooks who found that the netgear ReadyNAS boxes can take standard DDR3 SO-DIMMs. apparently there are lots of people who have been upgrading them from the pathetic 256mb they come with to at least 1gb, with some degree of success: http://www.readynas.com/forum/viewtopic.php?f=110t=49254 That thread is for DUO v1 only (LEON SPARC based). I have not seen any claims that DUO v2 can be upgraded before the post on this mailinglist. Only numerous claims and complaints about it not being upgradeable, and wrote it off as not interesting when it came ot due to being restricted to 256MB. Regards Henrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1343254731.5203.28.ca...@hlaptop.hno.se
