Hi Tom,
On 15 November 2015 at 18:58, Tom Rini <tr...@konsulko.com> wrote:
> On Sun, Nov 15, 2015 at 06:34:51PM -0700, Simon Glass wrote:
>> Hi,
>>
>> On 13 November 2015 at 03:41, Bin Meng <bmeng...@gmail.com> wrote:
>> > Hi,
>> >
>> > On Wed, Nov 11, 2015 at 10:04 PM, Fabio Estevam <feste...@gmail.com> wrote:
>> >> On Wed, Nov 11, 2015 at 12:56 AM, Simon Glass <s...@chromium.org> wrote:
>> >>> Hi Fabio,
>> >>>
>> >>> On 10 November 2015 at 16:51, Fabio Estevam <feste...@gmail.com> wrote:
>> >>>>
>> >>>> Hi Simon,
>> >>>>
>> >>>> On Tue, Nov 10, 2015 at 10:09 PM, Simon Glass <s...@chromium.org> wrote:
>> >>>>
>> >>>> > This patch breaks chromebook_link - I think because it adds a new
>> >>>> > operation which is not supported by all flash chips. Those that are
>> >>>> > not supported (i.e that don't have the 'flash_is_locked' method)
>> >>>> > should still work.
>> >>>>
>> >>>> What is the symptom you are seeing? Which SPI NOR flash does this board
>> >>>> have?
>> >>>
>> >>> It crashes reading the environment:
>> >>>
>> >>> U-Boot 2015.10-00544-gcad0499 (Nov 10 2015 - 17:06:00 -0700)
>> >>>
>> >>> CPU: Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
>> >>> DRAM: 2.7 GiB
>> >>> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total
>> >>> 8 MiB
>> >>> *** Warning - bad CRC, using default environment
>> >>>
>> >>> Video: 1280x1024x16
>> >>> Model: Google Link
>> >>> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total
>> >>> 8 MiB
>> >>> Invalid Opcode (Undefined Opcode)
>> >>
>> >> I am wondering if this invalid opcode is caused by 6c2f758cee266f7648.
>> >>
>> >> Could you please try this?
>> >>
>> >
>> > No, this does not resolve this issue.
>> >
>> >> --- a/arch/x86/include/asm/bitops.h
>> >> +++ b/arch/x86/include/asm/bitops.h
>> >> @@ -364,7 +364,7 @@ static __inline__ int ffs(int x)
>> >> __asm__("bsfl %1,%0\n\t"
>> >> "jnz 1f\n\t"
>> >> "movl $-1,%0\n"
>> >> - "1:" : "=r" (r) : "rm" (x));
>> >> + "1:" : "=r" (r) : "g" (x));
>> >>
>> >> return r+1;
>> >> }
>> >
>> > It turns out it is a NULL pointer exception! Fixing this NULL pointer
>> > makes the crash disappear, but 'saveenv' does not actually work on the
>> > SST flash. Something is broken again, gosh!
>>
>> Bin thank you for fixing this.
>>
>> We still have a big problem with this patch though - it adds features
>> to the pre-driver-model SPI flash implementation and not the driver
>> model implementation! If I somehow have the wrong end of the stick
>> please let me know.
>>
>> If we accept this sort of patch we will never be done with driver
>> model conversions, as we make it impossible for boards to move
>> forward.
>>
>> Fabio can you please rework this to remove the pre-driver-model
>> support, and add your new functions to struct dm_spi_flash_ops
>> instead, then convert the affected boards to driver model?
>
> Hang on, didn't we have this discussion on one of the earlier threads
> about this? Part of the problem here is that everything else required
> to do this on DM isn't quite there and Fabio has agreed to (under pain
> of feature removal later) do the conversion when possible but to not
> otherwise block getting this feature (and thus some platform(s))
> integrated already.
OK that sounds good, thanks.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
