Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices
Le lundi 16 mars 2015 à 09:12 +0100, Hans de Goede a écrit : Hi, On 15-03-15 22:38, Paul Kocialkowski wrote: As far as I know, there is currently no mechanism in place to give each device a unique serial number, that would be shown in e.g. /proc/cpuinfo. This can seem not very useful, but it would be nice to have that for USB gadget drivers that make use of it (e.g. ADB on Android, fastboot, etc). This would allow having multiple sunxi devices connected at the same time. Normally, the serial number has to be figured out by the bootloader and passed to the kernel through ATAGs. In U-Boot, it is defined using get_board_serial, that is not yet implemented on sunxi. I'm interested in figuring out the best way to do this. As far as I can see, Allwinner SoCs have some e-fuses, known as SID (Security ID): http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a mainline Linux driver. Those should have device-specific values, except when they are set to 0. Do you have any better idea to do this, or is there some reference that I am missing? AFAIK the only way to do a serial number on sunxi devices is using the SID, note that Oliver's driver will only work on A10, A13 and A20, with the A31, A23 and others the SID is burned into the pmic rather then the SoC itself, but it should be easy to implement get_board_serial() in u-boot as we already have a sunxi_get_sid() helper to do that in a SoC independent way (this is currently used to set the ethernet MAC address). Note that sunxi_get_sid() can fail, so you need to error check it, and currently it will happily return an all 0 SID, you should probably make it return an error in that case, as that check really belongs inside sunxi_get_sid(). Why exactly is it a problem if the SID is 0 here? I don't see a big difference between providing a zero serial and not providing any serial at all (in any case, Linux will keep it at 0 when none is provided). U-Boot doesn't check the return code of setup_serial_tag either and isn't designed to not include the tag if it somewhat failed to grab the serial number. Hence my point is, let's not bother whether it's zero or not: it will just improve the situation on the vast majority of devices that have (at least) the first 4 32bit words of the SID populated and leave others with a zero serial, as it was until now. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part
Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices
On 16/03/15 09:51, Hans de Goede wrote: 2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not populated from the factory, I see little added value and I think I may end up nacking any patches for this, but first lets hear your arguments :) The eeproms are physically present on all boards as far as I can tell, however on every olinuxino I have, they are blank from the factory (i.e. content of every byte is 0xFF). If Olimex have defined a format for the contents of the eeprom, I've not been able to find it. So while I have no objection to using the eeprom for something like this, can we at least try to come up with something that: 1) Is optional. 2) Is disabled by default. 3) Allows for configurable format 4) Allows for configurable i2c bus and address (i.e. so you can add an eeprom to a cb2) That way we don't stomp all over existing users while allowing people who want the feature to easily enable it. It would obviously also be good if when the feature is disabled, or we detect that the eeprom contains invalid data, then we fall back to using the current SID based method for generating the MAC. There's one obvious question for me with any scheme like this. Olliver might want a 10 character serial number, I might want 12, someone else wants 15. How do we handle that? Would have been easier if Olimex put a unique serial number in the eeprom, but as it's already too late for that we shouldn't put ourselves in a corner that results in everyone using the same set of serial numbers. Is there any chance of using something in DT to define the format? -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices
Le lundi 16 mars 2015 à 14:45 +0100, Hans de Goede a écrit : Hi, On 16-03-15 13:31, Olliver Schinagl wrote: Hey, On 16-03-15 10:52, Hans de Goede wrote: Hi, Oops, missed a bit to reply to, see below: On 16-03-15 10:04, Olliver Schinagl wrote: Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example). I would say all of it, serial numbers often also contain a fixed bit with model info, for /proc/cpuinfo that is fine. but isn't the serial in /proc/cpuinfo limited to a certain number of bits? Could be, whomever writes patches for this needs to look into that, and if necessary truncate the SID somehow. As far as I can see, the SID has (at least) 4 32bit words. It seems that there is more on e.g. A20 but those are not always populated, so I think it's safer to go with those 4 words and somewhat use them to come up with a serial. The Linux kernel serial ATAG (shown in cpuinfo) is only 2 32bit words, so we will have to get rid of half of the (usable) SID. The first half seems prefixed depending on the SoC platform, which reduces the possible number of different combinations (but that's probably not really a problem) and as Hans mentioned, it isn't unusual to have a common part depending on the model. I suggest going with it. What do you think about it? -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part
[linux-sunxi] Funding opportunities for developing through Outreachy
Hi All, Apart from the Google Summer of Code program which focuses on university students, there is another program called Outreachy that provides internships to women, the LGBTQ community or those that are underprivileged. Here is their project website, https://www.gnome.org/outreachy/ which has more details on eligibility criteria. A new round of internships starts on 25th May, 2015 with stipend details similar to those of GSoC. One of the participating organizations is the Linux kernel which could support applications relating to linux-sunxi. There is a deadline for applications: Tuesday, 24th March 2015. As with GSoC, it requires to find a mentor. Therefore, a prospective applicant needs to contact the list to discuss, establish a project and find a mentor. Feel free to forward. Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hi, On 16-03-15 13:31, Olliver Schinagl wrote: Hey, On 16-03-15 10:52, Hans de Goede wrote: Hi, Oops, missed a bit to reply to, see below: On 16-03-15 10:04, Olliver Schinagl wrote: Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example). I would say all of it, serial numbers often also contain a fixed bit with model info, for /proc/cpuinfo that is fine. but isn't the serial in /proc/cpuinfo limited to a certain number of bits? Could be, whomever writes patches for this needs to look into that, and if necessary truncate the SID somehow. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Directions for video engine support (CedarX)
Hi All, I recently I had a conversation with Manuel about what can be done for better support for the video engine (CedarX) that is found in the A-series of SoCs from Allwinner. The way I understood all these was that there are short-term and long-term goals for better support with the video engine. The long-term goal would be to support CedarX in Video4Linux2 (V4L2), as it is already described in http://linux-sunxi.org/VE_Planning It makes sense to have CedarX supported in V4L2 (Linux kernel) as it is part of the mainlining process of the Allwinner SoCs. There are some open questions that need discussion (such as feasibility, what resources are needed, etc). In addition, it is important to describe the benefits from having CedarX support in V4L2 and especially when we should expect to have the first benefits when starting work on this. I would like to let Manuel to take over here, explain and expand on what his thoughts are. The short-term goals would be to use better what is available now, include libvdpau (anything needs fixing?) and the media-codec framework found on github (can it be used with gstreamer as Quink asked?). Please reply constructively, Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hey, On 16-03-15 10:52, Hans de Goede wrote: Hi, Oops, missed a bit to reply to, see below: On 16-03-15 10:04, Olliver Schinagl wrote: Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example). I would say all of it, serial numbers often also contain a fixed bit with model info, for /proc/cpuinfo that is fine. but isn't the serial in /proc/cpuinfo limited to a certain number of bits? I investigated if we could simply 'dump' the sid into the cpuinfo structure in the 3.4 days, but there was not bits available to print everything. If memory serves me well that is. Olliver Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: What open source community is this?
On Sun, Mar 15, 2015 at 11:03 PM, Manuel Braga mul.br...@gmail.com wrote: On Sun, 15 Mar 2015 23:51:03 +0800 Quink wantl...@gmail.com wrote: Sorry Simos, I just want to invite some students in local community to join sunxi and take part in GSOC. And everyone are welcome to join sunxi. And the GSOC idea is not bad, please do invite students. That email has nothing to do with the CedarX. It's so sad that there are so many misunderstand. If we have more I agree, let's resolve this misunderstanding. Simos for whatever reason, still didn't make public what he wrote to me in our private exchange. And this is making me suspicious. Manuel, this is bad form. The initial email in this thread, your non-apology reply and this insinuation on suspicious. We had a private email conversation where I asked to educate me on what can be done for the video engine, then I took my time because mid-week and you start this thread because you misread an e-mail. My impression is that even if everything go perfect in this process, something will come up and you will go rogue. Please prove me wrong. Simos Maybe you Quink, could help here. By telling, who are you?, and your connection to allwinner?, if any. What is you want to do? And, what kind of help are expected from linux-sunxi? tolerant attitudes, technical discussing should not become a flashpoint, and we can be more Your technical question that was made in your last email is unanswered because was part of an email that started with a flashpoint. Let's keep the technical discussing, separated from flashpoints. open too. Yes, let's all be open. -- Manuel Braga -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hi, On 16-03-15 11:16, Olliver Schinagl wrote: Hey Hans, snip We will be using Lime2's which all have them, all lime's have them. Obviously there will be a check, to check if there is a valid eeprom with valid data, but for our product it will be required. Since we will be flashing a generic image (all devices equal) and thus need to have the 'uniqueness' of a device in the eeprom I see, yes using olinuxino's embedded in factory devices is a valid reason, so I will be happy to take patches for reading the MAC from the eeprom, we will need to do some tests to make sure that we only do this on valid eeproms though, I think it would be good to add a checksum + all 00 test, or a crc check, note a checksum is fine by me, but if there is ready to use crc code somewhere in u-boot that works for me too. Yeah, absolutly. We probably want have a little very quick brainstorm as to how and what we want to store. In our case, I think we probably want the eeprom it its full form stored at the beginning of the eeprom, some checksum/crc, followed by a few reserved bytes maybe. After that a serial number. My first thought was to store the serial number in the eeprom and create a mac from that, but now, that sounds like a bad idea. Optionally, it could be possible to store the mac-prefix and serial number seperatly, and the LSB is used for the second half of the mac? I don't know yet, just throwing up some idea's. The biggest problem right now is to get the 2nd and 3rd i2c adapters working, as the current marvell driver only supports single I2C devices. But I hope to send patches for that in a few weeks/couple of months. Ok, note if you work on this please just convert the driver to the driver model, rather then using the old multiple i2c adapter stuff. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] Input: sun4i-ts - allow to adjust some settings via device-tree properties.
Hi, On 12-03-15 16:45, Jens Thiele wrote: This commit introduces two new optional device-tree properties: tp-sensitive-adjust: adjust sensitivity of pen down detection filter-type: select median and averaging filter The previous fixed defaults, didn't work well for the Olimex A13-LCD10TS (I have). Signed-off-by: Jens Thiele ka...@karme.de Thanks for working on this, this patch looks good to me: Reviewed-by: Hans de Goede hdego...@redhat.com Regards, Hans --- .../devicetree/bindings/input/touchscreen/sun4i.txt | 19 +-- drivers/input/touchscreen/sun4i-ts.c| 17 + 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt index 42d..c93edfa 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt @@ -8,8 +8,20 @@ Required properties: - #thermal-sensor-cells: shall be 0 Optional properties: - - allwinner,ts-attached: boolean indicating that an actual touchscreen is - attached to the controller + - allwinner,ts-attached: boolean indicating that an actual touchscreen + is attached to the controller + - allwinner,tp-sensitive-adjust : integer (4 bits) + adjust sensitivity of pen down detection + between 0 (least sensitive) and 15 + (defaults to 15) + - allwinner,filter-type: integer (2 bits) + select median and averaging filter + samples used for median / averaging filter + 0: 4/2 + 1: 5/3 + 2: 8/4 + 3: 16/8 + (defaults to 1) Example: @@ -19,4 +31,7 @@ Example: interrupts = 29; allwinner,ts-attached; #thermal-sensor-cells = 0; + /* sensitive/noisy touch panel */ + allwinner,tp-sensitive-adjust = 0; + allwinner,filter-type = 3; }; diff --git a/drivers/input/touchscreen/sun4i-ts.c b/drivers/input/touchscreen/sun4i-ts.c index b93a28b..d1cf847 100644 --- a/drivers/input/touchscreen/sun4i-ts.c +++ b/drivers/input/touchscreen/sun4i-ts.c @@ -30,6 +30,10 @@ * These kinds of heuristics are just asking for trouble (and don't belong * in the kernel). So this driver offers straight forward, reliable single * touch functionality only. + * + * s.a. A20 User Manual 1.15 TP (Documentation/arm/sunxi/README) + * (looks like the description in the A20 User Manual v1.3 is better + * than the one in the A10 User Manual v.1.5) */ #include linux/err.h @@ -246,6 +250,9 @@ static int sun4i_ts_probe(struct platform_device *pdev) int error; u32 reg; bool ts_attached; + /* optional device-tree properties, use old fixed values as default */ + u32 tp_sensitive_adjust = 15; + u32 filter_type = 1; ts = devm_kzalloc(dev, sizeof(struct sun4i_ts_data), GFP_KERNEL); if (!ts) @@ -313,14 +320,16 @@ static int sun4i_ts_probe(struct platform_device *pdev) ts-base + TP_CTRL0); /* -* sensitive_adjust = 15 : max, which is not all that sensitive, +* tp_sensitive_adjust is an optional property * tp_mode = 0 : only x and y coordinates, as we don't use dual touch */ - writel(TP_SENSITIVE_ADJUST(15) | TP_MODE_SELECT(0), + of_property_read_u32(np, allwinner,tp-sensitive-adjust, tp_sensitive_adjust); + writel(TP_SENSITIVE_ADJUST(tp_sensitive_adjust) | TP_MODE_SELECT(0), ts-base + TP_CTRL2); - /* Enable median filter, type 1 : 5/3 */ - writel(FILTER_EN(1) | FILTER_TYPE(1), ts-base + TP_CTRL3); + /* Enable median and averaging filter, optional property for filter type */ + of_property_read_u32(np, allwinner,filter-type, filter_type); + writel(FILTER_EN(1) | FILTER_TYPE(filter_type), ts-base + TP_CTRL3); /* Enable temperature measurement, period 1953 (2 seconds) */ writel(TEMP_ENABLE(1) | TEMP_PERIOD(1953), ts-base + TP_TPR); -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Some info on Google Summer of Code (GSoC) 2015 and linux-sunxi
Hi All, Here are some details for those that may be interested in taking part in Google Summer of Code (GSoC) 2015 or one in a subsequent year. Here is the page for GSoC 2015, https://www.google-melange.com/gsoc/homepage/google/gsoc2015 Here is the page with the timeline (deadlines), https://www.google-melange.com/gsoc/events/google/gsoc2015 GSoC is a project by Google that runs every year since about ten years ago, and provides financial support for work on open-source projects. It requires different open-source projects to apply as organizations so that they can then accept students to work for them (the open-source projects) over a period of three months during the summer. The students get US$5500 and the mentor from the organization gets US$500. A prospective student needs to be a university student (tertiary education in general). There is no limitation as to what cource they are studying. They need to show proof that they are University students in around May. Last year, Emilio applied for GSoC through the organization Linux Foundation and had Maxime as his mentor, http://linux-sunxi.narkive.com/VYmpmy4Q/improve-allwinner-socs-support-on-mainline-linux Sadly, this year the Linux Foundation was not accepted as an organization, http://www.linuxfoundation.org/collaborate/workgroups/gsoc/google-summer-code-2015 In addition, Linaro, which also took part in GSoC 2014, was not accepted this year. This makes it a bit more difficult to find a suitable host organization for linux-sunxi. The list of the 2015 organizations is at https://www.google-melange.com/gsoc/org/list/public/google/gsoc2015 One option could be X.Org Foundation for graphics-related tasks. X.Org was accepted for 2015. Their list of project ideas is at http://www.x.org/wiki/SummerOfCodeIdeas/ They mention relevant projects such as accelerated video decoding for some NVidia SoCs (Maxwell Accelerated Video Decoding), so it might be viable to add something even for CedarX. For this to work, it requires: 1. one or more students to volunteer to undertake such relevant projects. 2. a mentor to volunteer to oversee the work. 3. communication with the X.Org Foundation to accept the project in their allocation of funded projects The hard deadline for students to apply is Friday, 27th March 2015. Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hi, On 16-03-15 10:56, Olliver Schinagl wrote: Hey Hans, On 16-03-15 10:51, Hans de Goede wrote: Hi, On 16-03-15 10:04, Olliver Schinagl wrote: Hey all, On 16-03-15 09:12, Hans de Goede wrote: Hi, On 15-03-15 22:38, Paul Kocialkowski wrote: As far as I know, there is currently no mechanism in place to give each device a unique serial number, that would be shown in e.g. /proc/cpuinfo. This can seem not very useful, but it would be nice to have that for USB gadget drivers that make use of it (e.g. ADB on Android, fastboot, etc). This would allow having multiple sunxi devices connected at the same time. Normally, the serial number has to be figured out by the bootloader and passed to the kernel through ATAGs. In U-Boot, it is defined using get_board_serial, that is not yet implemented on sunxi. I'm interested in figuring out the best way to do this. As far as I can see, Allwinner SoCs have some e-fuses, known as SID (Security ID): http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a mainline Linux driver. Those should have device-specific values, except when they are set to 0. Do you have any better idea to do this, or is there some reference that I am missing? AFAIK the only way to do a serial number on sunxi devices is using the SID, note that Oliver's driver will only work on A10, A13 and A20, with the A31, A23 and others the SID is burned into the pmic rather then the SoC I vaguely recall that the A31 had a SID aswell according to its datasheet Yes it has a SID entry in its memory map, that is probably a copy and paste error though, the real SID is stored in the axp221, not in the A31 itself, reading from the addresses in the memory map always returns 0 on all A31-s. Ah, okay, I never tested it on those as i don't have hardware. I do have an A33 based device, so i'll probe /dev/mem to see if we have a SID there. I guess some a23 device owners can probe their sid's aswell then. I'll go over the datasheets for a23 and a33 to confirm on those, and will look at the a31/a31s/a80's also. itself, but it should be easy to implement get_board_serial() in u-boot as we already have a sunxi_get_sid() helper to do that in a SoC independent way (this is currently used to set the ethernet MAC address). I'l slowly (in a few weeks time) working on a patch to get the mac from the EEPROM for the olinuxino's, though i think we need to upgrade the i2c driver a bit (multiple adapter support). Hmm, not sure if that is really useful, 2 questions: 1) Is there anything wrong with the current SID based approach on the olinuxino-s, AFAIK all olinuxino's have non pre-production SOCs and so have proper SID-s and thus a proper MAC set. That's still an illegal, e.g. it is a mac address based on the 'internal development'. We have a mac prefix and want to base our mac partially on our serial numbers (and it has to be _guaranteed_ unique etc). So we will be storing our serial numbers in the eerpom anyway and be basing the mac on that anyhow. Right, it is not an assigned MAC, that is true. 2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not populated from the factory, I see little added value and I think I may end up nacking any patches for this, but first lets hear your arguments :) We will be using Lime2's which all have them, all lime's have them. Obviously there will be a check, to check if there is a valid eeprom with valid data, but for our product it will be required. Since we will be flashing a generic image (all devices equal) and thus need to have the 'uniqueness' of a device in the eeprom I see, yes using olinuxino's embedded in factory devices is a valid reason, so I will be happy to take patches for reading the MAC from the eeprom, we will need to do some tests to make sure that we only do this on valid eeproms though, I think it would be good to add a checksum + all 00 test, or a crc check, note a checksum is fine by me, but if there is ready to use crc code somewhere in u-boot that works for me too. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hi, On 16-03-15 10:04, Olliver Schinagl wrote: Hey all, On 16-03-15 09:12, Hans de Goede wrote: Hi, On 15-03-15 22:38, Paul Kocialkowski wrote: As far as I know, there is currently no mechanism in place to give each device a unique serial number, that would be shown in e.g. /proc/cpuinfo. This can seem not very useful, but it would be nice to have that for USB gadget drivers that make use of it (e.g. ADB on Android, fastboot, etc). This would allow having multiple sunxi devices connected at the same time. Normally, the serial number has to be figured out by the bootloader and passed to the kernel through ATAGs. In U-Boot, it is defined using get_board_serial, that is not yet implemented on sunxi. I'm interested in figuring out the best way to do this. As far as I can see, Allwinner SoCs have some e-fuses, known as SID (Security ID): http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a mainline Linux driver. Those should have device-specific values, except when they are set to 0. Do you have any better idea to do this, or is there some reference that I am missing? AFAIK the only way to do a serial number on sunxi devices is using the SID, note that Oliver's driver will only work on A10, A13 and A20, with the A31, A23 and others the SID is burned into the pmic rather then the SoC I vaguely recall that the A31 had a SID aswell according to its datasheet Yes it has a SID entry in its memory map, that is probably a copy and paste error though, the real SID is stored in the axp221, not in the A31 itself, reading from the addresses in the memory map always returns 0 on all A31-s. I'll go over the datasheets for a23 and a33 to confirm on those, and will look at the a31/a31s/a80's also. itself, but it should be easy to implement get_board_serial() in u-boot as we already have a sunxi_get_sid() helper to do that in a SoC independent way (this is currently used to set the ethernet MAC address). I'l slowly (in a few weeks time) working on a patch to get the mac from the EEPROM for the olinuxino's, though i think we need to upgrade the i2c driver a bit (multiple adapter support). Hmm, not sure if that is really useful, 2 questions: 1) Is there anything wrong with the current SID based approach on the olinuxino-s, AFAIK all olinuxino's have non pre-production SOCs and so have proper SID-s and thus a proper MAC set. 2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not populated from the factory, I see little added value and I think I may end up nacking any patches for this, but first lets hear your arguments :) Note that sunxi_get_sid() can fail, so you need to error check it, and currently it will happily return an all 0 SID, you should probably make it return an error in that case, as that check really belongs inside sunxi_get_sid(). The big problem with the sunxi-sid, is that it can be often blank :S very annoying. Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example). Often? In my experience it is empty on cubieboard2 and some early mele A1000 models, and that is it. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hi, Oops, missed a bit to reply to, see below: On 16-03-15 10:04, Olliver Schinagl wrote: Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example). I would say all of it, serial numbers often also contain a fixed bit with model info, for /proc/cpuinfo that is fine. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hey, On 16-03-15 11:21, Hans de Goede wrote: Hi, On 16-03-15 11:16, Olliver Schinagl wrote: Hey Hans, snip We will be using Lime2's which all have them, all lime's have them. Obviously there will be a check, to check if there is a valid eeprom with valid data, but for our product it will be required. Since we will be flashing a generic image (all devices equal) and thus need to have the 'uniqueness' of a device in the eeprom I see, yes using olinuxino's embedded in factory devices is a valid reason, so I will be happy to take patches for reading the MAC from the eeprom, we will need to do some tests to make sure that we only do this on valid eeproms though, I think it would be good to add a checksum + all 00 test, or a crc check, note a checksum is fine by me, but if there is ready to use crc code somewhere in u-boot that works for me too. Yeah, absolutly. We probably want have a little very quick brainstorm as to how and what we want to store. In our case, I think we probably want the eeprom it its full form stored at the beginning of the eeprom, some checksum/crc, followed by a few reserved bytes maybe. After that a serial number. My first thought was to store the serial number in the eeprom and create a mac from that, but now, that sounds like a bad idea. Optionally, it could be possible to store the mac-prefix and serial number seperatly, and the LSB is used for the second half of the mac? I don't know yet, just throwing up some idea's. The biggest problem right now is to get the 2nd and 3rd i2c adapters working, as the current marvell driver only supports single I2C devices. But I hope to send patches for that in a few weeks/couple of months. Ok, note if you work on this please just convert the driver to the driver model, rather then using the old multiple i2c adapter stuff. Noted ;) Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Some info on Google Summer of Code (GSoC) 2015 and linux-sunxi
On Mon, Mar 16, 2015 at 02:59:07PM +0200, Simos Xenitellis wrote: Hi All, Here are some details for those that may be interested in taking part in Google Summer of Code (GSoC) 2015 or one in a subsequent year. Here is the page for GSoC 2015, https://www.google-melange.com/gsoc/homepage/google/gsoc2015 Here is the page with the timeline (deadlines), https://www.google-melange.com/gsoc/events/google/gsoc2015 GSoC is a project by Google that runs every year since about ten years ago, and provides financial support for work on open-source projects. It requires different open-source projects to apply as organizations so that they can then accept students to work for them (the open-source projects) over a period of three months during the summer. The students get US$5500 and the mentor from the organization gets US$500. A prospective student needs to be a university student (tertiary education in general). There is no limitation as to what cource they are studying. They need to show proof that they are University students in around May. Last year, Emilio applied for GSoC through the organization Linux Foundation and had Maxime as his mentor, http://linux-sunxi.narkive.com/VYmpmy4Q/improve-allwinner-socs-support-on-mainline-linux Sadly, this year the Linux Foundation was not accepted as an organization, http://www.linuxfoundation.org/collaborate/workgroups/gsoc/google-summer-code-2015 In addition, Linaro, which also took part in GSoC 2014, was not accepted this year. This makes it a bit more difficult to find a suitable host organization for linux-sunxi. The list of the 2015 organizations is at https://www.google-melange.com/gsoc/org/list/public/google/gsoc2015 One option could be X.Org Foundation for graphics-related tasks. X.Org was accepted for 2015. Their list of project ideas is at http://www.x.org/wiki/SummerOfCodeIdeas/ They mention relevant projects such as accelerated video decoding for some NVidia SoCs (Maxwell Accelerated Video Decoding), so it might be viable to add something even for CedarX. For this to work, it requires: 1. one or more students to volunteer to undertake such relevant projects. 2. a mentor to volunteer to oversee the work. 3. communication with the X.Org Foundation to accept the project in their allocation of funded projects The hard deadline for students to apply is Friday, 27th March 2015. Simos Yet another instance of you trying to play santa with other peoples work? Have you even talked to the Xorg board members who are working on this? Let me ping my friend mupuf and find out. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hey Hans, On 16-03-15 10:51, Hans de Goede wrote: Hi, On 16-03-15 10:04, Olliver Schinagl wrote: Hey all, On 16-03-15 09:12, Hans de Goede wrote: Hi, On 15-03-15 22:38, Paul Kocialkowski wrote: As far as I know, there is currently no mechanism in place to give each device a unique serial number, that would be shown in e.g. /proc/cpuinfo. This can seem not very useful, but it would be nice to have that for USB gadget drivers that make use of it (e.g. ADB on Android, fastboot, etc). This would allow having multiple sunxi devices connected at the same time. Normally, the serial number has to be figured out by the bootloader and passed to the kernel through ATAGs. In U-Boot, it is defined using get_board_serial, that is not yet implemented on sunxi. I'm interested in figuring out the best way to do this. As far as I can see, Allwinner SoCs have some e-fuses, known as SID (Security ID): http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a mainline Linux driver. Those should have device-specific values, except when they are set to 0. Do you have any better idea to do this, or is there some reference that I am missing? AFAIK the only way to do a serial number on sunxi devices is using the SID, note that Oliver's driver will only work on A10, A13 and A20, with the A31, A23 and others the SID is burned into the pmic rather then the SoC I vaguely recall that the A31 had a SID aswell according to its datasheet Yes it has a SID entry in its memory map, that is probably a copy and paste error though, the real SID is stored in the axp221, not in the A31 itself, reading from the addresses in the memory map always returns 0 on all A31-s. Ah, okay, I never tested it on those as i don't have hardware. I do have an A33 based device, so i'll probe /dev/mem to see if we have a SID there. I guess some a23 device owners can probe their sid's aswell then. I'll go over the datasheets for a23 and a33 to confirm on those, and will look at the a31/a31s/a80's also. itself, but it should be easy to implement get_board_serial() in u-boot as we already have a sunxi_get_sid() helper to do that in a SoC independent way (this is currently used to set the ethernet MAC address). I'l slowly (in a few weeks time) working on a patch to get the mac from the EEPROM for the olinuxino's, though i think we need to upgrade the i2c driver a bit (multiple adapter support). Hmm, not sure if that is really useful, 2 questions: 1) Is there anything wrong with the current SID based approach on the olinuxino-s, AFAIK all olinuxino's have non pre-production SOCs and so have proper SID-s and thus a proper MAC set. That's still an illegal, e.g. it is a mac address based on the 'internal development'. We have a mac prefix and want to base our mac partially on our serial numbers (and it has to be _guaranteed_ unique etc). So we will be storing our serial numbers in the eerpom anyway and be basing the mac on that anyhow. 2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not populated from the factory, I see little added value and I think I may end up nacking any patches for this, but first lets hear your arguments :) We will be using Lime2's which all have them, all lime's have them. Obviously there will be a check, to check if there is a valid eeprom with valid data, but for our product it will be required. Since we will be flashing a generic image (all devices equal) and thus need to have the 'uniqueness' of a device in the eeprom Note that sunxi_get_sid() can fail, so you need to error check it, and currently it will happily return an all 0 SID, you should probably make it return an error in that case, as that check really belongs inside sunxi_get_sid(). The big problem with the sunxi-sid, is that it can be often blank :S very annoying. Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example). Often? In my experience it is empty on cubieboard2 and some early mele A1000 models, and that is it. I should have said 'sometimes' :) My bad. It is not yet guaranteed to be unique unfortunately. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Open source CedarX driver
On Sun, Mar 08, 2015 at 02:34:54AM +0200, Simos Xenitellis wrote: On Sun, Mar 8, 2015 at 12:32 AM, Henrik Nordström hen...@henriknordstrom.net wrote: fre 2015-03-06 klockan 18:28 +0800 skrev Quink: cedarx2.0 is a refactoring of cedarx1.0. The job is finished about just three month ago and not used by most vendors yet. Some work is still needed to port cedarx2.0 to linux. The directory of cedarx2.0 in Android SDK is frameworks/av/media/liballwinner. The directory of cedarx1.0 in Android SDK is frameworks/av/media/CedarX-Projects. Most part of cedarx2.0 is open source. It's not the same situation compared with cedarx1.0. Maybe it is not a big step and not enough, it is a right direction. The latest cedarx code released by Allwinner is still non-GPL in the important parts, and no indications that this will change any time soon. Yes they have released much of the glue layers with GPL license, but the actual video encoding/decoding parts is till in a binary library which is incompatible with the GPL license terms. As an interim solution for the repo at https://github.com/allwinner-zh/media-codec (with the aim to keep the glue code as LGPL while the .so libraries as closed-source), would it make sense to split the repository into two parts? That is, have a https://github.com/allwinner-zh/media-codec-lib repository that will contain the two .so closed-source libraries. Then, the https://github.com/allwinner-zh/media-codec repository will include the media-codec-lib as a 'git submodule'. Simos Even if people ignore the terms of the LGPL, like you clearly do, there are still LGPLed symbols present in that binary. I suggest that you start by reading up on the GPL and LGPL licenses. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: What open source community is this?
On Mon, 16 Mar 2015 10:24:59 +0800 Quink wantl...@gmail.com wrote: I'm an employee of allwinner, and I joined this mailing list before joined the company. I speak for myself here. I have a Cubieboard2 (I bought it to do real-time vibration control as a graduate students.) runing Linux and want to playback video on that, and I saw some people have the same idea too. I want to find a workable solution, that's all. Thanks for explaining, to have this information given to me in private created a burden into me, because of not be able to tell others. So, if we can get all of the source code from allwinner, and work out the complete open source solution, that is the best. If we can't, I want to find out just a workable solution. The graphic card AMD radeon 545v didn't work well with open source driver until Linux kernel 3.13. Before that, I have to use my laptop too, with AMD private driver. It seems that no one takes the cedar binaries as a solution, no matter whether it has been cleaned of not. Speaking for myself, binaries blobs are not my business. Is not the reason why i joined sunxi, and as so, i have not desire to waste time with binaries blobs. If Cedrus is the only workable solution, I will try to figure out how to contribute to this project. On Mon, Mar 16, 2015 at 5:03 AM, Manuel Braga mul.br...@gmail.com wrote: On Sun, 15 Mar 2015 23:51:03 +0800 Quink wantl...@gmail.com wrote: Sorry Simos, I just want to invite some students in local community to join sunxi and take part in GSOC. And everyone are welcome to join sunxi. And the GSOC idea is not bad, please do invite students. That email has nothing to do with the CedarX. It's so sad that there are so many misunderstand. If we have more I agree, let's resolve this misunderstanding. Simos for whatever reason, still didn't make public what he wrote to me in our private exchange. And this is making me suspicious. Maybe you Quink, could help here. By telling, who are you?, and your connection to allwinner?, if any. What is you want to do? And, what kind of help are expected from linux-sunxi? tolerant attitudes, technical discussing should not become a flashpoint, and we can be more Your technical question that was made in your last email is unanswered because was part of an email that started with a flashpoint. Let's keep the technical discussing, separated from flashpoints. open too. Yes, let's all be open. -- Manuel Braga -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Manuel Braga -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Directions for video engine support (CedarX)
The way I understood all these was that there are short-term and long-term goals for better support with the video engine. As an end user, I think that having mainline support (not just for the kernel, but the rest of the stack as well) for something like Kodi (nee XBMC) would be great. Ever since the first Android TV sticks came out, I have hoped to use one of those beasts as a media-center. But so far I haven't been able to do that: when using GNU/Linux the video playback sucks for lack of VPU support, and when using Android I'm faced with the problem that there's no DVD player software available in Android (there are lots of players which advertise support for playing DVDs, but they actually don't support playing from an optical drive). Stefan -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: What open source community is this?
Am 15.03.2015, 17:16 Uhr, schrieb Luc Verhaegen l...@skynet.be: On Sun, Mar 15, 2015 at 06:12:10PM +0200, Simos Xenitellis wrote: On Sun, Mar 15, 2015 at 5:56 PM, Luc Verhaegen l...@skynet.be wrote: On Sun, Mar 15, 2015 at 11:51:03PM +0800, Quink wrote: ... Luc Verhaegen. Luc, please, start your own thread. What you are doing is hijacking. Simos I will continue the original thread later on, Mr. Pot. Luc Verhaegen. With all due respect for your contributions, may I suggest that you stop blaming people and ranting? I further suggest that your anger about various violations of the GPL by Allwiner is strictly limited to the appropriate thread Allwinner GPL violations: definitive proof. Thank you! I.Irgendeiner -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Directions for video engine support (CedarX)
I'm interested in this as well. When I've tried manually mounting in Android they still fail. It looks like the data coming off is still in a format the software can't take. Does someone have step by step instructions for Android? Sent from my Fire On March 16, 2015, at 8:48 AM, Quink wantl...@gmail.com wrote: You can mount the optical drive manually. On Mon, Mar 16, 2015 at 11:35 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: The way I understood all these was that there are short-term and long-term goals for better support with the video engine. As an end user, I think that having mainline support (not just for the kernel, but the rest of the stack as well) for something like Kodi (nee XBMC) would be great. Ever since the first Android TV sticks came out, I have hoped to use one of those beasts as a media-center. But so far I haven't been able to do that: when using GNU/Linux the video playback sucks for lack of VPU support, and when using Android I'm faced with the problem that there's no DVD player software available in Android (there are lots of players which advertise support for playing DVDs, but they actually don't support playing from an optical drive). Stefan -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: What open source community is this?
On Mon, Mar 16, 2015 at 04:56:10PM +0100, Irgendeiner wrote: Am 15.03.2015, 17:16 Uhr, schrieb Luc Verhaegen l...@skynet.be: On Sun, Mar 15, 2015 at 06:12:10PM +0200, Simos Xenitellis wrote: On Sun, Mar 15, 2015 at 5:56 PM, Luc Verhaegen l...@skynet.be wrote: On Sun, Mar 15, 2015 at 11:51:03PM +0800, Quink wrote: ... Luc Verhaegen. Luc, please, start your own thread. What you are doing is hijacking. Simos I will continue the original thread later on, Mr. Pot. Luc Verhaegen. With all due respect for your contributions, may I suggest that you stop blaming people and ranting? I further suggest that your anger about various violations of the GPL by Allwiner is strictly limited to the appropriate thread Allwinner GPL violations: definitive proof. Thank you! I.Irgendeiner If you at all wish to be taken serious, try using your real name. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Open source CedarX driver
On 03/16/15 14:52, Luc Verhaegen wrote: Even if people ignore the terms of the LGPL, like you clearly do, there are still LGPLed symbols present in that binary. I suggest that you start by reading up on the GPL and LGPL licenses. Luc Verhaegen. i think he already has: https://github.com/simos/keyboardlayouteditor/blob/master/COPYING -- simon Simon Kenyon e: simoncken...@gmail.com m: +353 86 240 0005 l: http://ie.linkedin.com/pub/simon-kenyon/0/6b2/744/ s: simonckenyon t: @simonckenyon g: google.com/+SimonKenyon -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Directions for video engine support (CedarX)
You can mount the optical drive manually. On Mon, Mar 16, 2015 at 11:35 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: The way I understood all these was that there are short-term and long-term goals for better support with the video engine. As an end user, I think that having mainline support (not just for the kernel, but the rest of the stack as well) for something like Kodi (nee XBMC) would be great. Ever since the first Android TV sticks came out, I have hoped to use one of those beasts as a media-center. But so far I haven't been able to do that: when using GNU/Linux the video playback sucks for lack of VPU support, and when using Android I'm faced with the problem that there's no DVD player software available in Android (there are lots of players which advertise support for playing DVDs, but they actually don't support playing from an optical drive). Stefan -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Open source CedarX driver
On Mon, Mar 16, 2015 at 03:16:47PM +, Simon Kenyon wrote: On 03/16/15 14:52, Luc Verhaegen wrote: Even if people ignore the terms of the LGPL, like you clearly do, there are still LGPLed symbols present in that binary. I suggest that you start by reading up on the GPL and LGPL licenses. Luc Verhaegen. i think he already has: https://github.com/simos/keyboardlayouteditor/blob/master/COPYING His statements suggest that he just pro-forma copied that. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Formal request for source code for LGPL licensed software.
On Fri, Mar 13, 2015 at 12:13:42PM +0800, ke...@allwinnertech.com wrote: Hi, Luc, Thanks for your suggestion. We have update the Cedarx. What we have done is as follows: 1. Update the License text, the media-codec is fully following LGPL; But it is not, it depends on a strange binary still. 2. Splite the binary to submodule media-codec-lib; BTW, the binary is just video engine driver implement in user mode, All code is wrote by Allwinner, based on Allwinner's video engine hardware, no third part used; Wrong. Even the latest binary has code that originated from FFMpeg/libavcodec. It seems that Allwinner has absolutely no control or insight in what code came from where with Cedar. 3. Fix some issue of the code; Oh? Which? With these actions, is there any license issue yet? Yes. First off, LGPLed symbols and code remains. I have manually decompiled the disassembly of one of the functions, and for this function there is absolutely no doubt that the code originated from FFMpeg/libavcodec, and that code was always LGPLed. I will not disclose which symbols and code these are at this point, as that will only trigger Allwinner to rename/restructure this code, and then Allwinner will subsequently (falsely) claim to adhere to the licenses. It is however rocksolid proof that will survive even the harshest legal scrutiny. Secondly, removing or hiding LGPLed code does not change the fact that the LGPL license once applied to the full source tree (and still does). It also does not change the fact that hundreds of thousands of devices out there are shipping with LGPL licensed cedar binaries. Allwinner is still legally bound to release their whole source code for each and every version Allwinner distributed to any party, when requested by that party. Please help to give a check, if any suggestion, please let me know. We will try to fix it ASAP. Thanks! None of the current actions; namely splitting out of the binary into another repository, removing vp6 support and attached code, absolves Allwinner in any way. At best, it shows that Allwinner does not understand or does not want to understand the terms of the (L)GPL. It is now also extensively proven that Allwinner has no control over the contents of the Cedar binaries. Allwinners Cedar binaries are tainted in many many different ways and this wholly illegal software cannot be distributed and should never have been distributed. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Directions for video engine support (CedarX)
On Mon, Mar 16, 2015 at 5:35 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: The way I understood all these was that there are short-term and long-term goals for better support with the video engine. As an end user, I think that having mainline support (not just for the kernel, but the rest of the stack as well) for something like Kodi (nee XBMC) would be great. Ever since the first Android TV sticks came out, I have hoped to use one of those beasts as a media-center. But so far I haven't been able to do that: when using GNU/Linux the video playback sucks for lack of VPU support, and when using Android I'm faced with the problem that there's no DVD player software available in Android (there are lots of players which advertise support for playing DVDs, but they actually don't support playing from an optical drive). In Android, the Android image would need to implement the MediaCodec (as in http://developer.android.com/reference/android/media/MediaCodec.html) class for CedarX in order to provide support for hardware decoding/encoding to the apps. It's MediaCodec in Anrdoid 4.1 or newer. It was Stagefright in previous versions of Android. In terms of Kodi for Android, if MediaCodec is configured properly for the Allwinner SoC, then Kodi should work out of the box. It should be possible to retrofit the libvdecodec.so/libvencoder.so libraries (found on https://github.com/allwinner-zh) into an existing Android image in order to get MediaCodec working properly for Kodi. Quink, do you have any instructions for that? Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Directions for video engine support (CedarX)
2015-03-16 20:22 GMT+03:00 Simos Xenitellis simos.li...@googlemail.com: It should be possible to retrofit the libvdecodec.so/libvencoder.so libraries (found on https://github.com/allwinner-zh) into an existing Android image Those *.so are armhf linux native. Android is armel linux with bionic. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Directions for video engine support (CedarX)
I'm interested in this as well. When I've tried manually mounting in Android they still fail. It looks like the data coming off is still in a format the software can't take. Does someone have step by step instructions for Android? Additionally to mounting, I think it is necessary to perform some extra steps to unlock the data (not sure if it's got to do with the DVD regions or the DVDCSS part), unless the DVD is not copy protected. GNU/Linux players know how to do that, but for some reason Android players don't (even though AFAIK they should be able to just use the same code as on GNU/Linux, since it's a kernel-level API). Stefan -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices
Le lundi 16 mars 2015 à 17:50 -0400, Stefan Monnier a écrit : if necessary truncate the SID somehow. Or hash it, For some reason, I kinda like the idea of having the serial match something directly readable in the hardware instead of something that just looks about random. Furthermore, having a common part of the serial among devices using the same Allwinner SoC gives it some kind of identity. My two cents, -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
if necessary truncate the SID somehow. Or hash it, Stefan -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v6] crypto: Add Allwinner Security System crypto accelerator
Hello This is the driver for the Security System included in Allwinner SoC A20. The Security System (SS for short) is a hardware cryptographic accelerator that support AES/MD5/SHA1/DES/3DES/PRNG algorithms. It could be found on others Allwinner SoC: - A10s, A33 and A31 diagram speak about it with precisions (AES/DES/3DES/Md5/SHA1/PRNG) - A10 and A13 manual give the same datasheet for SS than A20 - A23 speak about a security system but without precisions - A80 datasheet speak about a security system with more functions (SHA224/SHA256/RSA/CRC) but without precisions But I do not have access on any of those hardware, tests are welcome. This driver currently supports: - MD5 and SHA1 hash algorithms - AES block cipher in CBC mode with 128/196/256bits keys. - DES and 3DES block cipher in CBC mode The driver exposes all those algorithms through the kernel cryptographic API. The driver support only CPU driven (aka poll mode) transfer mode, since the DMA engine of the A20 does not have a mainline driver yet. Changes since v5: - Hash functions now keep partial hash states in sunxi_ss structures - Use of spinlock instead of mutex - Remove the static sunxi_ss structures by using container of - Add export/import functions - replace lots of writel by writesl - replace lots of readl by readsl Changes since v4: - Rework all mutex path - Use ahash_request_ctx() in hash functions - Major rework of hash functions for solving mutex problems - Split sunxi_req_ctx in two since ciphers now use struct sunxi_tfm_ctx - Hash functions now test FIFO space register Changes since v3: - Remove all algorithms options from Kconfig, so now only one module is used - Add the sunxi_ss_cipher function to unify mode calculation - Remove the sunxi_cipher_exit empty function - Add some missing mutex_unlock() - Drop PRNG support, I wait for more comment on its results before re-enabling it. Changes since v2: - Fix Makefile and Kconfig for static kernel. Changes since v1: - annotate ss-base as __iomem - regroup all mutex in the ss_ctx structure - splited driver in 7 modules (core md5 sha1 aes des 3des prng) in sunxi-ss directory - use dev_exit_p() for .remove - added missing CRYPTO_BLKCIPHER dep in Kconfig - use ahash instead of shash - use ablkcipher instead of blkcipher - use crypto_rng_ctx instead of crypto_tfm_ctx - set seed as an u32 - drop useless comment decoration - drop useless debug - ss_ctx is now a static pointer and whole structure being allocated - fix the platform_get_resource/devm_ioremap_resource pattern - invert getting die id and configuring clock - set clock value as a const unsigned long - add MODULE_ALIAS - use define names more consistency (SS_xxx) - fix PRNG errors - respell SS to Security System in DT documentation -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v6 3/4] MAINTAINERS: Add myself as maintainer of Allwinner Security System
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0e1abe8..ebca296 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10923,6 +10923,12 @@ L: linux...@kvack.org S: Maintained F: mm/zswap.c +ALLWINNER SECURITY SYSTEM +M: Corentin Labbe clabbe.montj...@gmail.com +L: linux-cry...@vger.kernel.org +S: Maintained +F: drivers/crypto/sunxi-ss/ + THE REST M: Linus Torvalds torva...@linux-foundation.org L: linux-ker...@vger.kernel.org -- 2.0.5 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v6 1/4] ARM: sun7i: dt: Add Security System to A20 SoC DTS
The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.
This patch enable the Security System on the Allwinner A20 SoC Device-tree.
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3a8530b..8995bec 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -680,6 +680,14 @@
status = disabled;
};
+ crypto: crypto-engine@01c15000 {
+ compatible = allwinner,sun7i-a20-crypto;
+ reg = 0x01c15000 0x1000;
+ interrupts = 0 86 4;
+ clocks = ahb_gates 5, ss_clk;
+ clock-names = ahb, mod;
+ };
+
spi2: spi@01c17000 {
compatible = allwinner,sun4i-a10-spi;
reg = 0x01c17000 0x1000;
--
2.0.5
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v6 4/4] crypto: Add Allwinner Security System crypto accelerator
Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support:
- MD5 and SHA1 hash algorithms
- AES block cipher in CBC mode with 128/196/256bits keys.
- DES and 3DES block cipher in CBC mode
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
drivers/crypto/Kconfig| 17 ++
drivers/crypto/Makefile | 1 +
drivers/crypto/sunxi-ss/Makefile | 2 +
drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 408 +
drivers/crypto/sunxi-ss/sunxi-ss-core.c | 339 +
drivers/crypto/sunxi-ss/sunxi-ss-hash.c | 475 ++
drivers/crypto/sunxi-ss/sunxi-ss.h| 200 +
7 files changed, 1442 insertions(+)
create mode 100644 drivers/crypto/sunxi-ss/Makefile
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-core.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2fb0fdf..9ba9759 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -436,4 +436,21 @@ config CRYPTO_DEV_QCE
hardware. To compile this driver as a module, choose M here. The
module will be called qcrypto.
+config CRYPTO_DEV_SUNXI_SS
+ tristate Support for Allwinner Security System cryptographic
accelerator
+ depends on ARCH_SUNXI
+ select CRYPTO_MD5
+ select CRYPTO_SHA1
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+ help
+ Some Allwinner SoC have a crypto accelerator named
+ Security System. Select this if you want to use it.
+ The Security System handle AES/DES/3DES ciphers in CBC mode
+ and SHA1 and MD5 hash algorithms.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sunxi-ss.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 3924f93..856545c 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss/
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
new file mode 100644
index 000..8bb287d
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o
+sunxi-ss-y += sunxi-ss-core.o sunxi-ss-hash.o sunxi-ss-cipher.o
diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
new file mode 100644
index 000..3ed0ad0
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
@@ -0,0 +1,408 @@
+/*
+ * sunxi-ss-cipher.c - hardware cryptographic accelerator for Allwinner A20 SoC
+ *
+ * Copyright (C) 2013-2015 Corentin LABBE clabbe.montj...@gmail.com
+ *
+ * This file add support for AES cipher with 128,192,256 bits
+ * keysize in CBC mode.
+ * Add support also for DES and 3DES in CBC mode.
+ *
+ * You could find the datasheet in Documentation/arm/sunxi/README
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include sunxi-ss.h
+
+static int sunxi_ss_cipher(struct ablkcipher_request *areq, u32 mode)
+{
+ struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
+ struct sunxi_tfm_ctx *op = crypto_ablkcipher_ctx(tfm);
+ const char *cipher_type;
+ struct sunxi_ss_ctx *ss = op-ss;
+
+ if (areq-nbytes == 0)
+ return 0;
+
+ if (areq-info == NULL) {
+ dev_err(ss-dev, ERROR: Empty IV\n);
+ return -EINVAL;
+ }
+
+ if (areq-src == NULL || areq-dst == NULL) {
+ dev_err(ss-dev, ERROR: Some SGs are NULL\n);
+ return -EINVAL;
+ }
+
+ cipher_type = crypto_tfm_alg_name(crypto_ablkcipher_tfm(tfm));
+
+ if (strcmp(cbc(aes), cipher_type) == 0) {
+ mode |= SS_OP_AES | SS_CBC | SS_ENABLED | op-keymode;
+ return sunxi_ss_aes_poll(areq, mode);
+ }
+
+ if (strcmp(cbc(des), cipher_type) == 0) {
+ mode |= SS_OP_DES | SS_CBC | SS_ENABLED | op-keymode;
+ return sunxi_ss_des_poll(areq, mode);
+ }
+
+ if (strcmp(cbc(des3_ede), cipher_type) == 0) {
+ mode |= SS_OP_3DES | SS_CBC | SS_ENABLED | op-keymode;
+ return sunxi_ss_des_poll(areq, mode);
+ }
+
+ dev_err(ss-dev, ERROR: Cipher %s not handled\n, cipher_type);
+ return
[linux-sunxi] [PATCH v6 2/4] ARM: sunxi: dt: Add DT bindings documentation for SUNXI Security System
This patch adds documentation for Device-Tree bindings for the Security System cryptographic accelerator driver. Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com --- Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 + 1 file changed, 9 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/sunxi-ss.txt diff --git a/Documentation/devicetree/bindings/crypto/sunxi-ss.txt b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt new file mode 100644 index 000..a566803 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt @@ -0,0 +1,9 @@ +* Allwinner Security System found on A20 SoC + +Required properties: +- compatible : Should be allwinner,sun7i-a20-crypto. +- reg: Should contain the Security System register location and length. +- interrupts: Should contain the IRQ line for the Security System. +- clocks : A phandle to the functional clock node of the Security System module +- clock-names : Name of the functional clock, should be ahb and mod. + -- 2.0.5 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v6 3/4] MAINTAINERS: Add myself as maintainer of Allwinner Security System
On Mon, 2015-03-16 at 20:01 +0100, LABBE Corentin wrote: [] diff --git a/MAINTAINERS b/MAINTAINERS [] @@ -10923,6 +10923,12 @@ L: linux...@kvack.org S: Maintained F: mm/zswap.c +ALLWINNER SECURITY SYSTEM +M: Corentin Labbe clabbe.montj...@gmail.com +L: linux-cry...@vger.kernel.org +S: Maintained +F: drivers/crypto/sunxi-ss/ Use alphabetic ordering for new sections please. Please place this section between: ALI1563 I2C DRIVER and ALPHA PORT -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hey Hans, On 16-03-15 11:13, Hans de Goede wrote: Hi, On 16-03-15 10:56, Olliver Schinagl wrote: Hey Hans, On 16-03-15 10:51, Hans de Goede wrote: Hi, On 16-03-15 10:04, Olliver Schinagl wrote: Hey all, On 16-03-15 09:12, Hans de Goede wrote: Hi, On 15-03-15 22:38, Paul Kocialkowski wrote: As far as I know, there is currently no mechanism in place to give each device a unique serial number, that would be shown in e.g. /proc/cpuinfo. This can seem not very useful, but it would be nice to have that for USB gadget drivers that make use of it (e.g. ADB on Android, fastboot, etc). This would allow having multiple sunxi devices connected at the same time. Normally, the serial number has to be figured out by the bootloader and passed to the kernel through ATAGs. In U-Boot, it is defined using get_board_serial, that is not yet implemented on sunxi. I'm interested in figuring out the best way to do this. As far as I can see, Allwinner SoCs have some e-fuses, known as SID (Security ID): http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a mainline Linux driver. Those should have device-specific values, except when they are set to 0. Do you have any better idea to do this, or is there some reference that I am missing? AFAIK the only way to do a serial number on sunxi devices is using the SID, note that Oliver's driver will only work on A10, A13 and A20, with the A31, A23 and others the SID is burned into the pmic rather then the SoC I vaguely recall that the A31 had a SID aswell according to its datasheet Yes it has a SID entry in its memory map, that is probably a copy and paste error though, the real SID is stored in the axp221, not in the A31 itself, reading from the addresses in the memory map always returns 0 on all A31-s. Ah, okay, I never tested it on those as i don't have hardware. I do have an A33 based device, so i'll probe /dev/mem to see if we have a SID there. I guess some a23 device owners can probe their sid's aswell then. I'll go over the datasheets for a23 and a33 to confirm on those, and will look at the a31/a31s/a80's also. itself, but it should be easy to implement get_board_serial() in u-boot as we already have a sunxi_get_sid() helper to do that in a SoC independent way (this is currently used to set the ethernet MAC address). I'l slowly (in a few weeks time) working on a patch to get the mac from the EEPROM for the olinuxino's, though i think we need to upgrade the i2c driver a bit (multiple adapter support). Hmm, not sure if that is really useful, 2 questions: 1) Is there anything wrong with the current SID based approach on the olinuxino-s, AFAIK all olinuxino's have non pre-production SOCs and so have proper SID-s and thus a proper MAC set. That's still an illegal, e.g. it is a mac address based on the 'internal development'. We have a mac prefix and want to base our mac partially on our serial numbers (and it has to be _guaranteed_ unique etc). So we will be storing our serial numbers in the eerpom anyway and be basing the mac on that anyhow. Right, it is not an assigned MAC, that is true. 2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not populated from the factory, I see little added value and I think I may end up nacking any patches for this, but first lets hear your arguments :) We will be using Lime2's which all have them, all lime's have them. Obviously there will be a check, to check if there is a valid eeprom with valid data, but for our product it will be required. Since we will be flashing a generic image (all devices equal) and thus need to have the 'uniqueness' of a device in the eeprom I see, yes using olinuxino's embedded in factory devices is a valid reason, so I will be happy to take patches for reading the MAC from the eeprom, we will need to do some tests to make sure that we only do this on valid eeproms though, I think it would be good to add a checksum + all 00 test, or a crc check, note a checksum is fine by me, but if there is ready to use crc code somewhere in u-boot that works for me too. Yeah, absolutly. We probably want have a little very quick brainstorm as to how and what we want to store. In our case, I think we probably want the eeprom it its full form stored at the beginning of the eeprom, some checksum/crc, followed by a few reserved bytes maybe. After that a serial number. My first thought was to store the serial number in the eeprom and create a mac from that, but now, that sounds like a bad idea. Optionally, it could be possible to store the mac-prefix and serial number seperatly, and the LSB is used for the second half of the mac? I don't know yet, just throwing up some idea's. The biggest problem right now is to get the 2nd and 3rd i2c adapters working, as the current marvell driver only supports single I2C devices. But I hope to send patches for that in a few weeks/couple of months. Olliver Regards, Hans -- You received
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Am Sonntag, 15. März 2015 22:39:05 UTC+1 schrieb con...@paulk.fr: Do you have any better idea to do this, or is there some reference that I am missing? Currently the MAC address in U-Boot is generated that way, see: http://lists.denx.de/pipermail/u-boot/2014-June/181879.html -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hi, On 15-03-15 22:38, Paul Kocialkowski wrote: As far as I know, there is currently no mechanism in place to give each device a unique serial number, that would be shown in e.g. /proc/cpuinfo. This can seem not very useful, but it would be nice to have that for USB gadget drivers that make use of it (e.g. ADB on Android, fastboot, etc). This would allow having multiple sunxi devices connected at the same time. Normally, the serial number has to be figured out by the bootloader and passed to the kernel through ATAGs. In U-Boot, it is defined using get_board_serial, that is not yet implemented on sunxi. I'm interested in figuring out the best way to do this. As far as I can see, Allwinner SoCs have some e-fuses, known as SID (Security ID): http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a mainline Linux driver. Those should have device-specific values, except when they are set to 0. Do you have any better idea to do this, or is there some reference that I am missing? AFAIK the only way to do a serial number on sunxi devices is using the SID, note that Oliver's driver will only work on A10, A13 and A20, with the A31, A23 and others the SID is burned into the pmic rather then the SoC itself, but it should be easy to implement get_board_serial() in u-boot as we already have a sunxi_get_sid() helper to do that in a SoC independent way (this is currently used to set the ethernet MAC address). Note that sunxi_get_sid() can fail, so you need to error check it, and currently it will happily return an all 0 SID, you should probably make it return an error in that case, as that check really belongs inside sunxi_get_sid(). Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hey all, On 16-03-15 09:12, Hans de Goede wrote: Hi, On 15-03-15 22:38, Paul Kocialkowski wrote: As far as I know, there is currently no mechanism in place to give each device a unique serial number, that would be shown in e.g. /proc/cpuinfo. This can seem not very useful, but it would be nice to have that for USB gadget drivers that make use of it (e.g. ADB on Android, fastboot, etc). This would allow having multiple sunxi devices connected at the same time. Normally, the serial number has to be figured out by the bootloader and passed to the kernel through ATAGs. In U-Boot, it is defined using get_board_serial, that is not yet implemented on sunxi. I'm interested in figuring out the best way to do this. As far as I can see, Allwinner SoCs have some e-fuses, known as SID (Security ID): http://linux-sunxi.org/SID_Register_Guide for which Oliver has written a mainline Linux driver. Those should have device-specific values, except when they are set to 0. Do you have any better idea to do this, or is there some reference that I am missing? AFAIK the only way to do a serial number on sunxi devices is using the SID, note that Oliver's driver will only work on A10, A13 and A20, with the A31, A23 and others the SID is burned into the pmic rather then the SoC I vaguely recall that the A31 had a SID aswell according to its datasheet, I'll go over the datasheets for a23 and a33 to confirm on those, and will look at the a31/a31s/a80's also. itself, but it should be easy to implement get_board_serial() in u-boot as we already have a sunxi_get_sid() helper to do that in a SoC independent way (this is currently used to set the ethernet MAC address). I'l slowly (in a few weeks time) working on a patch to get the mac from the EEPROM for the olinuxino's, though i think we need to upgrade the i2c driver a bit (multiple adapter support). Note that sunxi_get_sid() can fail, so you need to error check it, and currently it will happily return an all 0 SID, you should probably make it return an error in that case, as that check really belongs inside sunxi_get_sid(). The big problem with the sunxi-sid, is that it can be often blank :S very annoying. Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example). Olliver Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
