ons 2014-01-29 klockan 11:11 -0600 skrev Rob Herring:
> Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
> pin is an option? If so, don't you need some fixed time delay
> properties like max erase time?
>
> rb-gpios could be added to the generic nand binding as well.
The
ons 2014-01-29 klockan 11:11 -0600 skrev Rob Herring:
Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
pin is an option? If so, don't you need some fixed time delay
properties like max erase time?
rb-gpios could be added to the generic nand binding as well.
The
tis 2014-01-21 klockan 19:13 +0100 skrev Henrik Nordström:
> > Are you sure ?
> > This thread says that only the first 1024 bytes of data (+ 96 bytes of
> > ECC) of each page are used:
>
> yes I am sure. There was no page access commands between the sectors,
> only l
lör 2014-01-18 klockan 05:46 -0800 skrev Boris BREZILLON:
> Do you know which mode are used (X ECC strength / 512 or 1024 bytes ?)
> and
> when they are are selected (does it depend on the connected NAND
> chip ?) ?
It seems to blindly try some modes until something usable is found.
Varying
lör 2014-01-18 klockan 05:46 -0800 skrev Boris BREZILLON:
Do you know which mode are used (X ECC strength / 512 or 1024 bytes ?)
and
when they are are selected (does it depend on the connected NAND
chip ?) ?
It seems to blindly try some modes until something usable is found.
Varying both
tis 2014-01-21 klockan 19:13 +0100 skrev Henrik Nordström:
Are you sure ?
This thread says that only the first 1024 bytes of data (+ 96 bytes of
ECC) of each page are used:
yes I am sure. There was no page access commands between the sectors,
only linear read of data,ecc,data,ecc.
Hmm
mån 2014-01-13 klockan 10:02 +0100 skrev boris brezillon:
> The most complicated part is the boot0 partition.
Not really. It's only a little different (sequential ECC, static
randomizer seed on every page).
> Tell me if I'm wrong, but here's what I understood from your work (and
> yuq's work
mån 2014-01-13 klockan 10:02 +0100 skrev boris brezillon:
The most complicated part is the boot0 partition.
Not really. It's only a little different (sequential ECC, static
randomizer seed on every page).
Tell me if I'm wrong, but here's what I understood from your work (and
yuq's work
fre 2013-09-13 klockan 00:23 +0800 skrev cinifr:
> Yes, My bootloader dont set it, and I have to set it at dtsi fot
> boot, I found is be set in dtsi file for ohters
> cups.
The patch from Ian is now in sunxi u-boot.
Regards
Henrik
--
To unsubscribe from this list: send the line
fre 2013-09-13 klockan 00:23 +0800 skrev cinifr:
Yes, My bootloader dont set it, and I have to set it at dtsi fot
boot, I found clock-frequency is be set in dtsi file for ohters
cups.
The patch from Ian is now in sunxi u-boot.
Regards
Henrik
--
To unsubscribe from this list: send the
The earlier change to use strlcpy uncovered a bug in the options
argument length calculation causing last character to be truncated.
This makes the actual console to be configured with incorrect
baudrate when specifying the console using console=uart,... syntax.
Bug symptom seen in kernel log
The earlier change to use strlcpy uncovered a bug in the options
argument length calculation causing last character to be truncated.
This makes the actual console to be configured with incorrect
baudrate when specifying the console using console=uart,... syntax.
Bug symptom seen in kernel log
>From 8b278828cb439b3b9b723a1de28ae10ce3e0cc44 Mon Sep 17 00:00:00 2001
From: Henrik Nordstrom
Date: Thu, 4 Jul 2013 03:24:41 +0200
Subject: [PATCH] tty/8250_early: Don't truncate last character of options
the 3,9 change to use strlcpy to save options uncovered a bug in the
options argument
From 8b278828cb439b3b9b723a1de28ae10ce3e0cc44 Mon Sep 17 00:00:00 2001
From: Henrik Nordstrom hen...@henriknordstrom.net
Date: Thu, 4 Jul 2013 03:24:41 +0200
Subject: [PATCH] tty/8250_early: Don't truncate last character of options
the 3,9 change to use strlcpy to save options uncovered a bug in
mån 2013-04-29 klockan 10:12 +0300 skrev Stefan Kristiansson:
> A signal delivered through do_notify_resume() would cause the
> irqs_disabled() check in _local_bh_enable_ip() to be triggered.
>
> Enable interrupts before calling do_notify_resume().
>
> Signed-off-by: Stefan Kristiansson
mån 2013-04-29 klockan 10:12 +0300 skrev Stefan Kristiansson:
A signal delivered through do_notify_resume() would cause the
irqs_disabled() check in _local_bh_enable_ip() to be triggered.
Enable interrupts before calling do_notify_resume().
Signed-off-by: Stefan Kristiansson
mån 2013-06-17 klockan 15:58 -0700 skrev Greg KH:
> Really? I don't mind it but is this something that is ok to add to the
> pool? Will it be different on different machines with this device? Or
> will it always be the same on all systems with this device?
The data is unique per CPU, so it's
mån 2013-06-17 klockan 15:58 -0700 skrev Greg KH:
Really? I don't mind it but is this something that is ok to add to the
pool? Will it be different on different machines with this device? Or
will it always be the same on all systems with this device?
The data is unique per CPU, so it's
fre 2013-06-07 klockan 09:02 +0100 skrev luke.leighton:
> ok. so. we come back to the question again: what shall i propose to
> them that they consider doing, and what benefit would it be to them to
> do so?
Just tell them that the kernel is moving to a different configuration
syntax called
fre 2013-06-07 klockan 09:02 +0100 skrev luke.leighton:
ok. so. we come back to the question again: what shall i propose to
them that they consider doing, and what benefit would it be to them to
do so?
Just tell them that the kernel is moving to a different configuration
syntax called
tor 2013-06-06 klockan 13:22 +0100 skrev luke.leighton:
> idea: hook into devicetree gpio functions to allow script-fex gpio
functions to gain access in a separate module? that sort of thing.
No. Drop FEX from the kernel, use DT. There is no reason why the kernel
shold care about the FEX
tor 2013-06-06 klockan 13:19 +0100 skrev luke.leighton:
> mass-volume tablet, mass-volume IPTV box. android OS, nothing else.
Which still includes a number of possible configurations with different
i2c, spi, usb etc devices connected on the board. Because Allwinner is
not using mainline
tor 2013-06-06 klockan 13:19 +0100 skrev luke.leighton:
mass-volume tablet, mass-volume IPTV box. android OS, nothing else.
Which still includes a number of possible configurations with different
i2c, spi, usb etc devices connected on the board. Because Allwinner is
not using mainline methods
tor 2013-06-06 klockan 13:22 +0100 skrev luke.leighton:
idea: hook into devicetree gpio functions to allow script-fex gpio
functions to gain access in a separate module? that sort of thing.
No. Drop FEX from the kernel, use DT. There is no reason why the kernel
shold care about the FEX
ons 2013-06-05 klockan 23:20 +0100 skrev luke.leighton:
> ok: great. so we have something that i can potentially propose to
> them. now: what reason can i give that they should accept this?
> what's the biggest incentive for them, here, to make these changes?
> what would they gain?
Mainly a
tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton:
> > Not really the case. Actually the opposite. DT have this as well, and
> > integrated in device probing. Allwinner need to hack every driver used
> > to add their gpio requests to have pinmuxing triggered.
>
> augh. ok. solutions.
tor 2013-06-06 klockan 00:52 +0100 skrev luke.leighton:
> > How is the Allwinner kernel going to load the driver for the pca9532?
> > The mainline pca9532 driver does not understand fex so it can't read
> > the necessary initialization data.
>
> jon: you're immediately outside of the target
tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
> no john - they've only added it to the multiplexed sections of the
> drivers which they themselves have written. such as
> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> arch/arm/mach-sun{N}i and so on.
And a number of
ons 2013-06-05 klockan 16:54 -0600 skrev Stephen Warren:
> 1) Put all the parameters in the U-Boot configuration header. This is
> normal.
Yes, we do so today for U-Boot SPL. But this won't fit very well with
the Allwinner ODM workflow where one binary image works on a wide range
of board
ons 2013-06-05 klockan 22:15 +0100 skrev Luke Kenneth Casson Leighton:
> what we do not want to happen is that they see upstream patches being
> submitted, they merge them into their internal tree (which to date has
> had zero upstream changes: they're currently only just getting round
> to doing
ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton:
> And Then Some, stephen. there are two versions of u-boot being used:
> one is the community-assembled [GPL-compliant] one, and the other
> includes a [as-of-a-few-days-ago-but-no-longer, yay!]
> formerly-GPL-violating one
ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton:
And Then Some, stephen. there are two versions of u-boot being used:
one is the community-assembled [GPL-compliant] one, and the other
includes a [as-of-a-few-days-ago-but-no-longer, yay!]
formerly-GPL-violating one from
ons 2013-06-05 klockan 22:15 +0100 skrev Luke Kenneth Casson Leighton:
what we do not want to happen is that they see upstream patches being
submitted, they merge them into their internal tree (which to date has
had zero upstream changes: they're currently only just getting round
to doing 3.4
ons 2013-06-05 klockan 16:54 -0600 skrev Stephen Warren:
1) Put all the parameters in the U-Boot configuration header. This is
normal.
Yes, we do so today for U-Boot SPL. But this won't fit very well with
the Allwinner ODM workflow where one binary image works on a wide range
of board
tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
no john - they've only added it to the multiplexed sections of the
drivers which they themselves have written. such as
drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
arch/arm/mach-sun{N}i and so on.
And a number of SPI
tor 2013-06-06 klockan 00:52 +0100 skrev luke.leighton:
How is the Allwinner kernel going to load the driver for the pca9532?
The mainline pca9532 driver does not understand fex so it can't read
the necessary initialization data.
jon: you're immediately outside of the target market for
tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton:
Not really the case. Actually the opposite. DT have this as well, and
integrated in device probing. Allwinner need to hack every driver used
to add their gpio requests to have pinmuxing triggered.
augh. ok. solutions. what are
ons 2013-06-05 klockan 23:20 +0100 skrev luke.leighton:
ok: great. so we have something that i can potentially propose to
them. now: what reason can i give that they should accept this?
what's the biggest incentive for them, here, to make these changes?
what would they gain?
Mainly a
38 matches
Mail list logo
