vishnup has quit [Read error: Connection reset by peer]
naobsd has joined #linux-sunxi
afaerber has joined #linux-sunxi
yessikattal has joined #linux-sunxi
yessikattal has quit [Ping timeout: 265 seconds]
Akagi201 has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
khuey is now known as khuey|away
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 272 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Akagi201 has quit []
gianMOD has quit [Remote host closed the connection]
mrnuke has quit [Remote host closed the connection]
mrnuke has joined #linux-sunxi
Andy-D has quit [Ping timeout: 245 seconds]
flyhorse has joined #linux-sunxi
flyhorse_PvTFu has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
flyhorse_YNFXA has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 272 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 256 seconds]
<a1d3s>
Kasreyn, bananien doesnt need an installer , it is a full working OS
<a1d3s>
Kasreyn, you only need to dd it on sd and then boot your pi. then you can ssh to it
kaspter has joined #linux-sunxi
<plaes>
hrm.. can someone tell that "Lawrence Y" to go through "New Device Howto"
<plaes>
my mailer is crashing when trying to reply this mail
gianMOD has joined #linux-sunxi
<plaes>
there's currently no device in the wiki with "gsl3675" touchscreen controller
<plaes>
and he is trying to fish help for that.. :S
iamfrankenstein has joined #linux-sunxi
<plaes>
oh.. I can reply via web interface
gianMOD has quit [Ping timeout: 264 seconds]
JohnDoe_71Rus has joined #linux-sunxi
ganbold__ has quit [Ping timeout: 255 seconds]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
romain__1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 246 seconds]
cubeast has joined #linux-sunxi
kaspter has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
Net147 has joined #linux-sunxi
gianMOD has joined #linux-sunxi
reinforce has joined #linux-sunxi
gianMOD has quit [Ping timeout: 255 seconds]
<Net147>
I noticed something strange reading EDID from HDMI monitor using i2cdump with sunxi 3.4 kernel. "i2cdump -y -r 0-127 3 0x50 b" returns the correct data, but "i2cdump -y -r 0-127 3 0x50 c" returns data with first byte missing (data is shifted left by one byte). doesn't happen on other platforms.
flyhorse has joined #linux-sunxi
flyhorse_YNFXA has quit [Read error: Connection reset by peer]
a1d3s has quit [Remote host closed the connection]
lemonzest has joined #linux-sunxi
physis has quit [Read error: Connection reset by peer]
physis has joined #linux-sunxi
Net147 has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
diego_r has joined #linux-sunxi
gianMOD has quit [Ping timeout: 265 seconds]
kaspter1 has joined #linux-sunxi
sehraf has joined #linux-sunxi
kaspter has quit [Ping timeout: 246 seconds]
ricardocrudo has joined #linux-sunxi
kaspter has joined #linux-sunxi
kaspter1 has quit [Ping timeout: 246 seconds]
kaspter has quit [Remote host closed the connection]
_massi has joined #linux-sunxi
kaspter has joined #linux-sunxi
flyhorse_lfmqk has joined #linux-sunxi
prz has joined #linux-sunxi
flyhorse has quit [Ping timeout: 246 seconds]
hansg has joined #linux-sunxi
kaspter has quit [Ping timeout: 246 seconds]
iamfrankenstein1 has joined #linux-sunxi
FR^2 has joined #linux-sunxi
kaspter has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 256 seconds]
iamfrankenstein has joined #linux-sunxi
iamfrankenstein1 has quit [Ping timeout: 245 seconds]
gianMOD has joined #linux-sunxi
wickwire_ has joined #linux-sunxi
wickwire__ has quit [Ping timeout: 258 seconds]
awe00 has joined #linux-sunxi
gianMOD has quit [Ping timeout: 258 seconds]
kaspter has quit [Remote host closed the connection]
a1d3s has joined #linux-sunxi
romain__1 has quit [Ping timeout: 252 seconds]
romain___ has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<mripard>
RSpliet: hansg: hey, we were just wondering with bbrezillon, but does the NAND SPL stuff support storing the environment in the NAND as well /
<mripard>
or is it just hardcoded, and can't be changed?
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 276 seconds]
<dothebart>
libv: did you see that the merii package contains the complete uboot source for the a80?
<libv>
i am at a customer, so i cannot do anything about it right now
<dothebart>
since copyright etc. is still intact etc., I guess thats enough to obey the GPL...
<libv>
but send an email to me, with our ml in cc, provide the baidu link, and explain that the source is there, so that i do not forget
<dothebart>
ok.
<libv>
(or so that turl or mnemoc or whoever can put it on our dl server as well, when they have the time)
<dothebart>
I hope the ml works better then the wiki signup? ;-)
<dothebart>
ah, google group?
<jackdaniel>
mripard: spl nand doesn't have write support at all - we may put env somewhere on nand, but it will be readonly
<libv>
it does, yes, googlegroups has at least one redeeming feature :p
<libv>
(apart from: it's just there)
<jackdaniel>
mripard: so yes, it is hardcoded
<mripard>
jackdaniel: ok
<mripard>
so you still need to have an MMC around for the environment
<mripard>
(if you want to change it I mean)
ijc has quit [Ping timeout: 240 seconds]
ijc has joined #linux-sunxi
<jackdaniel>
I'm now working on single spl for mmc and nand
<jackdaniel>
but plan is to use yassins driver for normal u-boot
<jackdaniel>
while minimal read driver for spl
<dothebart>
libv: but its also contained in that github source dump
<libv>
dothebart: still makes sense to put it on our dl server
<libv>
it might have some source code differences
naobsd has quit [Quit: naobsd]
<dothebart>
i'm looking forward to fullfeatured uboots ;-)
<hansg>
mripard, atm it is SPL only, storing the environment happens from u-boot proper not the SPL.
<dothebart>
some years back I've spent some days meld'ing back libical sources from the various forks that existed
<mripard>
hansg: I thought that the SPL was using some of the environment (like the u-boot, kernel, dtb, load addresses, etc.)
<mripard>
but ok then :)
<dothebart>
not exactly fun, but meld makes that a lot easier.
<hansg>
mripard, a big question with this is where to store the environment, on some nands the erase block size is 2M so either we need to create bigger boot partitions (they are currently 2M) or have separate env partititions
<hansg>
mripard, no the SPL does not use the environment, it loads u-boot proper from a hardcoded offset
Kegeruneku is now known as Martoni
<mripard>
hansg: the usual way is in a separate partition, isn't
<mripard>
+it +
<mripard>
grmbl.
Martoni is now known as Kegeruneku
<mripard>
isn't it?
<hansg>
mripard, I do not know, I guess it may be, the question then becomes which ecc / randomize settings to use for this partition
<hansg>
The syndrome ones used by the BROM, or the regular ones which we will use for the main data partition.
<hansg>
Also we will need 2 partitions then, since 1 may have a bad block. And we need to teach u-boot to try both ...
<jackdaniel>
hansg: we may use boot0-rescue partition
<jackdaniel>
which is syndrome as well
<hansg>
jackdaniel, no, we actually need to write a second copy of u-boot there, and the u-boot SPL code needs to be fixed to try to load u-boot from both the main and the rescue boot partitions
<bbrezillon>
hansg: hm, if you implement a proper mtd driver, I'm pretty sure the MTD layer (in u-boot) already deals with bad blocks (skip them if any)
<hansg>
jackdaniel, try to envision what will happen if the main boot partition is on a bad block of the nand
<jackdaniel>
hansg: right
<hansg>
bbrezillon, AFAICT UBI(fs) actually deals with that, all the mtd code does is track badblocks
<jackdaniel>
but there is plenty free space even after writing u-boot on both syndrome partitions
<jackdaniel>
after u-boot I mean
<jackdaniel>
still on syndrome
<mripard>
hansg: most of the boards I've seen so far have two environment partitions
<hansg>
jackdaniel, nope, the erase size on the hynix nand on the A13 OlinuxIno board is 2Mbyte, and the partition is 2Mbyte. So in order to save env there we would need to erase the entire partition which will kill the spl + u-boot
<hansg>
mripard, ack that makes sense
<jackdaniel>
mhm
iamfrankenstein has quit [Quit: iamfrankenstein]
<mripard>
hansg: a main one and a fallback just in case
<hansg>
right, just like with the boot partitions
<hansg>
I believe that having env saving support is icing on the cake, but we should reserve the env partitions in the dts right away
hansg is now known as hansg_lunch
<mripard>
well, I'd expect this partition table to be changed from one board to another, and even from one user to another
<mripard>
I'm not sure the DT is the right place for that
<mripard>
iirc, u-boot has an mtdparts command and environment variable to deal with that
<mripard>
and pass it to the kernel through the command line
kaspter has joined #linux-sunxi
hansg_lunch is now known as hansg
kaspter has quit [Remote host closed the connection]
<hansg>
mripard, I think we are talking about different partitions here, AFAIK the mtdpart command deals with UBI volumes, I'm talking about the lowlevel dividing of the nand into different sections which each use a different ecc and randomization algorithm
kaspter has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
prz has quit [Ping timeout: 264 seconds]
kaspter has joined #linux-sunxi
<a1d3s>
after getting sound working , im hanging around again with my touch screen http://pastebin.com/uYpxJmFt these are my dt changes, i got these device /dev/input/event3:EP0790M09 , but cant calibrate it with xinput_calibrator , it is listed but touch didnt anything
<plaes>
cool, you did get sound?
<a1d3s>
plaes yes with hans wip kernel
<plaes>
ncie work :)
<plaes>
*nice
<plaes>
maybe you could add some debug printfs to the touch driver
<plaes>
to see how far it actually works
<a1d3s>
how?
<plaes>
by editing the driver source
<a1d3s>
;) ok and what i have to add in edt_ft5x06 ?
<plaes>
grep for example dev_info calls
hno has quit [Ping timeout: 252 seconds]
<plaes>
dev_info(&tsdata->client->dev, "Hello 1\n"); for example
<a1d3s>
i found wake_pin do i need to define the reset_pin in dt?
hno has joined #linux-sunxi
<plaes>
I have no idea
hno has quit [Changing host]
hno has joined #linux-sunxi
prz has joined #linux-sunxi
wigyori_ has joined #linux-sunxi
ricardocrudo_ has joined #linux-sunxi
ninolein has joined #linux-sunxi
diego71_ has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
<andriejk>
I mean - writing to nand works, and I can read from it, but wiki claims SLC is only supported
<mripard>
andriejk: it pretty much works, except that you can encounter corruptions
Black_Horseman has quit [Ping timeout: 252 seconds]
<andriejk>
if I want to put only u-boot, readonly rescue system, kernel, devicetree and ramdisk, and verify it's not corrupted, then I will be fine?
bbrezillon has quit [Quit: WeeChat 0.4.2]
bbrezillon has joined #linux-sunxi
<hansg>
mripard, ok that indeed seems to be the same sort of partitioning, but that will not work for nand partitions as we need to specify things like ecc-algorithm, ecc-strength, ecc-blocksize, random-seed, etc.
<hansg>
Also I see no advantage in having this info coded in u-boot config rather in the dts files. We are actually trying to remove board config from u-boot and make u-boot use dts files so as to avoid duplicating information between the 2.
<hansg>
Note that this scheme was part of by bbrezillon's original patch-set already, and IMHO doing things this way makes sense
<bbrezillon>
hansg: sorry, I haven't followed the whole discussion, but are you trying to retrieve u-boot env partitions from a DT ?
<hansg>
bbrezillon, we're discussing how best to store env for u-boot on nand, the idea is to 2 extra partitions similar to the boot0 and boot0-rescue partitions for env / env-rescue
<bbrezillon>
yes, that makes sense
<hansg>
The question is where to store the partition info, mripard is suggesting to store it inside u-boot rather then dts and then pass it through the kernel using the mtdparts= kernel cmdline, but I believe it would be better to store this in dts, esp. since we need ecc and random settings
<bbrezillon>
but AFAIR, when you're defining NAND as your u-boot env storage facility, you have to define the NAND offsets at which your env and redundant-env will be stored
<bbrezillon>
hansg: so you're planning to embed a DT inside your u-boot image ?
<bbrezillon>
(or concatanated to your u-boot image)
<hansg>
bbrezillon, we are already doing that in the latest upstream u-boot and using it to see which nic and usb controllers to enable if any, and we want to use it for more stuff rather then duplicating the same info in both u-boot board_defconfig files and the kernel dts
<bbrezillon>
if that's the case, then you might be able to extract those information
<hansg>
With a concatenated dtb as we are already using it should be possible to get the env partition offsets from the dts. As for the SPL finding u-boot itself that can use the same algorithm as the BROM uses, as we need to be BROM compatible for the boot0 partition anyways
<hansg>
ack
<bbrezillon>
if you want to make it compatible for all sunxi boards, the only thing you'll have to enforce is the env and env-redund partition names
<bbrezillon>
hey, this means you managed to make the DT parser fit into the SPL max size (24K IIRC)
<hansg>
Ack, we can specify those in the dt-binding doc for the nand controller
<hansg>
bbrezillon, no we are only using the dtb post SPL
<bbrezillon>
hansg: right, u-boot env is only setup after jumping to u-boot
<hansg>
ack
gianMOD has joined #linux-sunxi
<bbrezillon>
hansg: you're talking about the u-boot sunxi dt-binding doc, right ?
<bbrezillon>
because I'm not sure this should be generalized for all platforms
<hansg>
bbrezillon, I was talking about: Documentation/devicetree/bindings/mtd/sunxi-nand.txt
<bbrezillon>
hansg: then, definitely not :-)
<hansg>
But if there is a file for defining specific sunxi u-boot interactions in dts then that might be a more suitable place, is there such a file ?
naobsd has joined #linux-sunxi
<bbrezillon>
this binding doc describes the NAND controller bindings, not how u-boot should describe its env partitions
<hansg>
Note even if this goes into another file, we should probably add a note to Documentation/devicetree/bindings/mtd/sunxi-nand.txt pointing to that other file
<hansg>
<bbrezillon> this binding doc describes the NAND controller bindings, not how u-boot should describe its env partitions -> I hear you, I'm fine with writing this down elsewhere
<hansg>
bbrezillon, while we are talking I would like to try and get the rest of the sunxi nand patches (and preparation mtd patches) merged upstream. Are you ok with me posting a new version upstream to try and get some movement in this ?
<bbrezillon>
hansg: how about describing that in the SoC family doc Documentation/devicetree/bindings/arm/sunxi.txt
<bbrezillon>
even, if I'm not sure this should land in the kernel doc (this is really u-boot specific)
<bbrezillon>
hansg: regarding the submission of my patches, you can try to repost then, but I doubt it will be accepted in its current state
<hansg>
bbrezillon, that works for me
<hansg>
that works for me -> Using Documentation/devicetree/bindings/arm/sunxi.txt
<hansg>
About posting your patches upstream, do you have a link to the review of your latest posting of the patches ?
<hansg>
Also should I post them in small increments (e.g first just the nand partition support) or all at once ?
<bbrezillon>
and I think you should post them in small increments
<mripard>
hansg: let's put it another way: would you like to modify/recompile/reflash a DT just because you want to change the partition layout of your MMC card or your hard disk?
<mripard>
I know I don't :)
<mripard>
especially if you have alternative solutions
<mripard>
that u-boot support quite well already
<hansg>
The mtdpart= stuff stems from the time when jffs2 was the filesystem of choice. Now a days the filesystem of choice for flash is ubifs which sits on top of ubi which has volumes.
<hansg>
So what we get is 5 fixed partitons: boot, boot-rescue, env, env-rescue and data, data then is using ubi + ubifs and can be partitioned at the ubi level
<hansg>
What is described in devicetree is the 5 fixed partitions
<hansg>
Also "that u-boot support quite well already", no it does not, not for nand which needs per partition ecc and randomizer settings
cubeast has quit [Quit: Leaving]
<jackdaniel>
hansg: is it ok to try to initialize mmc in board.c directly? In order to know if mmc is present / contains valid eGON.BT0 header I have to initialize it in spl_boot_device, before actual decision is performed where to boot from
<hansg>
jackdaniel, yes, note that there already exists code to see if the board is booting from mmc0 (this is used on machines which have both mmc0 as sdcard slot and mmc2 as emmc), see the board_mmc_init() function in board/sunxi/board.c
<jackdaniel>
and the other thing - ENV_IS_IN_* is configured at compile-time, so if we need single binary for both mmc and nand, we have to decide, which do we want
<bbrezillon>
hansg: here your guessing what the user wants to do with its NAND, if ones wants to boot from another media he won't need the boot, boot-rescue and u-boot env parts
<mripard>
hansg: mtdparts is still the way to define nand partitions
<bbrezillon>
I think we should keep things as much configurable as possible
<bbrezillon>
and let the end-user decide what he wants
<mripard>
hansg: comparing that to UBI is like comparing the partition table of a disk to LVM
<mripard>
both work, you can define new partitions using them
<hansg>
mripard, it is more like comparing the need for an mbr vs the need for partitions
<mripard>
but it's not really the same thing, nor is it used for the same stuff.
<mripard>
mtdparts is your partition table
<mripard>
you can declare a single partition in it if you want if you don't like partitions
<mripard>
but still
<hansg>
This is all nice, but mtdparts simply will not work since it does not allow specifying extra data per partition
<jackdaniel>
hansg: so to make it in proper order, I have to check if signature is present on mmc0, if not, check if there is extra slot and if it contains signature, and if not, pick nand as boot device
<bbrezillon>
hansg: I guess jackdaniel pointed another aspect in favor of compile-time decision => ENV_IS_IN_XXX is selected at compile-time, so defining NAND_ENV_OFFSET (I don't recall the exact name) at compile time makes sense
<hansg>
As for bbrezillon what if the user want so boot from something else argument, that is highly unlikely and a very specialized case -> tell the user to use devicetree overlays
<hansg>
jackdaniel, almost right, whether there is an emmc connected to portc or a nand is compile time info, so no need to do a runtime check for that. If there is no bootable card in mmc0 we need to load from either nand or mmc2 depending on the compile time config
<mripard>
hansg: even the DT doesn't allow to specify extra data per partitions.
<mripard>
all attempts to do so have been rejected
<jackdaniel>
ok
<mripard>
and yeah, we could use the overlays. or we could use mtdparts, which already works, is documented, and so on.
<mripard>
(which I very much doubt the overlay do.)
leowt has joined #linux-sunxi
<hansg>
jackdaniel, as for ENV_IS_IN_xxx good point, we need to look into that, but lets worry about that later since atm we do not support env on nand at all
<jackdaniel>
yes, but if we have single image, then if we'll leave env_is_in_mmc, then nand boot will fail due to mmc init
<jackdaniel>
if we leave it commented, then no env on mmc either
<jackdaniel>
for booting from mmc
<hansg>
jackdaniel, AFAIK it will not fail, if there is no mmc it will simply fall back to the default env
<jackdaniel>
ok, so I'll just remove ifdef and check what happens
<hansg>
mripard, if we cannot store things like use "ecc=hw_syndrome" vs "ecc=hw" on a per part basis then using the nand simply will not work, so people will just need to accept storing extra per partition info in dts
<hansg>
We cannot make the entire nand use the weak ecc and randomize settings of the boot partitions as that rather badly impacts reliability
<hansg>
One way around this I can see is to have 2 sets of settings, one which applies to "boot" partitions and one for the rest of the partitions, but then we need to specify a way for the nand code to know when a partition is a boot partition
<bbrezillon>
hansg: well, I thought about doing that, but I'm not sure this is the best solution
<bbrezillon>
the MTD layer will still expose erroneous information about ECC strength
kaspter has joined #linux-sunxi
<hansg>
bbrezillon, expose to whom ?
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 246 seconds]
<bbrezillon>
hansg: to user space
<hansg>
bbrezillon, I see, that seems mostly a cosmetical issue though
<hansg>
bbrezillon, and if we report the actual needed ecc-strength / size of the chip there rather then the special boot area settings one can argue that what we are reporting is simply right
<mripard>
bbrezillon: iirc, there was also some suggestion of simply to make a userspace tool to flash the SPL at the right format for BROM, and completely circumventing the different ECC scheme for the SPL, right?
<hansg>
why did you not extend drivers/mtd/mtdpart.c to allow attaching extra info there, and instead created a new nandpart framework ?
<hansg>
Note going afk for a break back in 30 minutes or si
domidumont has quit [Read error: Connection reset by peer]
<bbrezillon>
hansg: I tried this approach too, but there's currently no way we can attach driver specific data to an MTD partition
<bbrezillon>
maybe we should address that and use the standard mtdpart code
<bbrezillon>
here is an example of why the sunxi NAND series can't make it to mainline in its current state
wigyori_ is now known as wigyori
<bbrezillon>
mripard: that's a solution, but we don't have any tool capable of generating appropriate appropriate ECC bytes for the HW ECC engine
sehraf has quit [Read error: Connection reset by peer]
<bbrezillon>
which means, we would have to first dump an SPL image (flashed from u-boot or a modified kernel) using MTD raw accessors
khuey|away is now known as khuey
Gerwin_J has joined #linux-sunxi
afaerber has joined #linux-sunxi
<bbrezillon>
and I'm not even mentionning that such an image might contain bitflips that should be corrected before even considering flashing it with raw accessors
gianMOD has joined #linux-sunxi
simosx has joined #linux-sunxi
<jackdaniel>
ok, single binary for both mmc and nand works, now the cleaning part :)
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
vishnup has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
vishnup has quit [Ping timeout: 265 seconds]
vishnup has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
kaspter has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
kaspter has joined #linux-sunxi
khuey is now known as khuey|away
kaspter has quit [Remote host closed the connection]
<hansg>
<bbrezillon> hansg: I tried this approach too, but there's currently no way we can attach driver specific data to an MTD partition
<hansg>
<bbrezillon> maybe we should address that and use the standard mtdpart code
<hansg>
Yes allowing for extra info to be attached to partitions generated by the standard mtdpart code sounds like the right thing todo, I'll look into that this weekend
<hansg>
<mripard> bbrezillon: iirc, there was also some suggestion of simply to make a userspace tool to flash the SPL at the right format for BROM, and completely circumventing the different ECC scheme for the SPL, right?
<hansg>
Right, because the most important thing with devicetree is for it to accurately describe the hardware, and having a special userspace tool to directly bitbang hardware so as to avoid devicetree actually accurately describing the hardware is a good idea (not)
<hansg>
Anyways lets take this one step at a time, I'll start with cleaning op bbrezillon 's partition + per partition ecc patches and submit those upstream
<hansg>
bbrezillon, mripard thanks for the input. Time for me to call it a day.
<hansg>
<jackdaniel> ok, single binary for both mmc and nand works, now the cleaning part :)
<hansg>
Sounds good, thank you for working on this.
<hansg>
jackdaniel, note usually not on irc since it tends to be a huge time sync / distraction (as useful as discussions like these are). If you've any more questions and I'm not on irc feel free to drop me a mail.
hansg has quit [Quit: Leaving]
vishnup has quit [Read error: Connection reset by peer]
romain___ has quit [Ping timeout: 272 seconds]
kaspter has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 264 seconds]
iamfrankenstein has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
prz has quit [Ping timeout: 264 seconds]
flyhorse has joined #linux-sunxi
leowt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
simosx has quit [Quit: Leaving]
flyhorse_lfmqk has quit [Read error: Connection reset by peer]
gianMOD has quit [Remote host closed the connection]
Gerwin_J has quit [Ping timeout: 264 seconds]
Gerwin_J has joined #linux-sunxi
leowt has joined #linux-sunxi
gianMOD has joined #linux-sunxi
Gerwin_J_ has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 264 seconds]
Gerwin_J_ is now known as Gerwin_J
khuey|away is now known as khuey
bonbons has joined #linux-sunxi
diego_r has quit [Ping timeout: 272 seconds]
reinforce has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
reinforce has quit [Ping timeout: 276 seconds]
a1d3s has quit [Remote host closed the connection]
Gerwin_J has quit [Ping timeout: 264 seconds]
afaerber has quit [Quit: Verlassend]
bobryan has quit [Ping timeout: 272 seconds]
Gerwin_J has joined #linux-sunxi
alexvf has quit [Ping timeout: 246 seconds]
reinforce has joined #linux-sunxi
afaerber has joined #linux-sunxi
bobryan has joined #linux-sunxi
_massi has quit [Quit: Leaving]
flyhorse_GnsBL has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
awe00 has quit [Ping timeout: 256 seconds]
alexvf has joined #linux-sunxi
leviathancn has joined #linux-sunxi
domidumont has joined #linux-sunxi
FR^2 has quit [Remote host closed the connection]
ricardocrudo_ has quit [Ping timeout: 265 seconds]
Netlynx has joined #linux-sunxi
gianMOD has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 264 seconds]
Gerwin_J has joined #linux-sunxi
khuey has quit [Ping timeout: 256 seconds]
naobsd has quit [Quit: naobsd]
khuey has joined #linux-sunxi
gianMOD has quit []
awe00 has joined #linux-sunxi
leviathancn has quit [Ping timeout: 252 seconds]
leowt has quit [Ping timeout: 265 seconds]
paulk-collins has quit [Quit: Quitte]
andriejk has quit [Ping timeout: 246 seconds]
flyhorse_GnsBL has quit [Read error: Connection reset by peer]
flyhorse has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
flyhorse has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
khuey has quit [Remote host closed the connection]
khuey has joined #linux-sunxi
Netlynx has quit [Remote host closed the connection]
domidumont has quit [Ping timeout: 246 seconds]
<Turl>
libv: what do I need to upload to dl?
<libv>
this has no proper link sadly
<libv>
just the usual baidu spam
physis has quit [Remote host closed the connection]
<RSpliet>
hansg: I was about to look at how to adapt mtdpart for partitioning in U-Boot, since bbrezillons approach doesn't work there (with the fixed array of mtd_nand devices)
<RSpliet>
well, about to... next week, when I get back to work :-)
<RSpliet>
if you... oh never mind
physis has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
leviathancn has quit [Ping timeout: 252 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
leowt has quit [Ping timeout: 246 seconds]
leowt has joined #linux-sunxi
arossdotme has quit [Ping timeout: 255 seconds]
leowt has quit [Ping timeout: 246 seconds]
bonbons has quit [Quit: Leaving]
arossdotme has joined #linux-sunxi
ricardocrudo has quit [Quit: Leaving]
sunxi_fan has quit [Ping timeout: 240 seconds]
ricardocrudo has joined #linux-sunxi
sunxi_fan has joined #linux-sunxi
ricardocrudo has quit [Client Quit]
ricardocrudo has joined #linux-sunxi
ricardocrudo has quit [Client Quit]
ricardocrudo has joined #linux-sunxi
montjoie has quit [Ping timeout: 265 seconds]
lemonzest has quit [Quit: Leaving]
ricardocrudo has quit [Remote host closed the connection]
<markvandenborre>
this is exciting
<markvandenborre>
H3 boards are getting really close to 22€ including shipping
<markvandenborre>
at which point there's no VAT, import tax or customs clearance fee to be paid anymore
<markvandenborre>
on import in the Europan Union
awe00 has quit [Ping timeout: 276 seconds]
montjoie has joined #linux-sunxi
flyhorse_ICRUD has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]