[Lenny400] Patches for linux-stable

H. Nikolaus Schaller hns at goldelico.com
Sun Sep 3 17:25:03 CEST 2017


Hi Paul,

> Am 03.09.2017 um 11:42 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Sunday 3. September 2017 11.17.28 H. Nikolaus Schaller wrote:
>> 
>>> Am 02.09.2017 um 22:59 schrieb Paul Boddie <paul at boddie.org.uk>:
>>> 
>>> Currently, I'm trying to figure some things out. For instance, the
>>> platform.c file contains device structures, as does the board file, but
>>> as you noted before, we should be able to get the device tree to create
>>> these structures for us, shouldn't we?
>> 
>> Yes, a quick glance did show that we can replace most of them. At lest
>> those for setting up peripheral devices.
> 
> I may see if they can be eliminated entirely, because there is the potential 
> for incorrect parameters lurking in these definitions, as well as some kind of 
> possible redundancy: I can imagine structures being created twice.
> 
>>> Another thing that seems like it might be a problem is deploying the
>>> device tree definition. I imagine that the U-Boot on the Minibook
>>> doesn't understand .dtb payloads.
>> 
>> Most likely not. And if it does, it needs a special boot-script that loads
>> the .dtb file to some address and tells the bootm command to pass it to the
>> kernel. And the script must know the file name to load.
>> 
>> This is a too hot potato for me... I't prefer not to open another
>> construction site and keep U-Boot completely untouched.
> 
> So would I.
> 
>>> If not, which "append" option should we use? If it does,
>>> however, where do we put the .dtb file?
>> 
>> There is CONFIG_ARM_APPENDED_DTB and with =y it is as easy as
>> 
>> cat zImage mipsbook_400.dtb >zImage-with-dtb
>> mkimage -A arm -O linux -T kernel -C none -a "$LOADADDRESS" -e
>> "$ENTRYPOINT" -n "$VERSION" -d zImage-with-dtb uImage
>> 
>> This makes an uImage that can be loaded like a non-DT based kernel.
>> (see for example https://www.osadl.org/Single-View.111+M5c9f8010d87.0.html)
>> 
>> But it appears that this mechanism works for ARM only :(
> 
> I did see some options which sound as if they should be related to this:
> 
> CONFIG_MIPS_NO_APPENDED_DTB
> CONFIG_MIPS_ELF_APPENDED_DTB
> CONFIG_MIPS_RAW_APPENDED_DTB

Ah, fine! I did fgrep the .config after compiling for ARM. Therefore I didn't
see the disabled CONFIG_MIPS options.

Looks as if we need CONFIG_MIPS_RAW_APPENDED_DRB=y

http://elixir.free-electrons.com/linux/v4.13-rc7/source/arch/mips/Kconfig#L2915

The only thing which makes me wonder is that the description is not for
zImage or uImage but for vmlinux.bin. We may have to make a zImage/uImage
out of that manually afterwards.

> 
>> So we will have to port this ARM feature to MIPS:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?
>> id=e2a6a3aafa986
> 
> It should have been done already. Indeed, a quick search provides things like 
> these:
> 
> https://github.com/lede-project/source/pull/582
> 
> But linux-stable already has these configuration settings.
> 
>> It is not complex, but Assembler and requires a deep understanding on how
>> the startup setup works. Fortunately the same head.S exists for MIPS and is
>> very short:
>> 
>> http://elixir.free-electrons.com/linux/v4.13-rc7/source/arch/mips/boot/comp
>> ressed/head.S
> 
> There is code to support it in arch/mips/kernel/head.S instead. But maybe we 
> then need to deploy an uncompressed uImage (or whatever the result is called) 
> or just modify this other file.
> 
>> Imho this means we probably just have to calculate an address and overwrite
>> a2/s2 (depending on which register KERNEL_ENTRY expects the DTB base
>> address to be).
> 
> Yes, it doesn't look difficult.
> 
>> Anyways, looks like another area of trouble and difficult debugging... But
>> if solved once it will be forever. So it is just a challenge :)
>> 
>> So how are DT based JZ4740/80 devices doing that? Do they have a modern
>> U-Boot?
> 
> They should have, certainly the JZ4780. It's possible that the original U-Boot 
> used by the Ben NanoNote (JZ4740-related) doesn't support device tree, but I 
> don't particularly remember what I was doing when testing newer kernels. Maybe 
> I should ask some people who might know.

Ok. This is a much better situation than I had thought so I am sure it can be solved
quite easily.

BR,
Nikolaus


More information about the Lenny400 mailing list