On Sat, 17 Jan 2015 04:35:55 +0100
Michal Suchanek <hramr...@gmail.com> wrote:
> On 17 January 2015 at 04:10, Siarhei Siamashka
> <siarhei.siamas...@gmail.com> wrote:
> > On Wed, 14 Jan 2015 12:20:12 +0100
> > Michal Suchanek <hramr...@gmail.com> wrote:
> >
> >> On 14 January 2015 at 11:42, Lars Doelle <lars.doe...@on-line.de> wrote:
> >> > Hi everyone,
> >> >
> >> > tuning device configuration for [[Inet K970]], I did not yet find
> >> > switches in the mainline kernel for the following features:
> >> >
> >> > 1) sunxi-keyboard
> >>
> >> There is a mainline driver and I did not try it so far. The main
> >> blocker is that I did not find instruction for fel booting mainline
> >> u-boot and kernel. I can upload the u-boot but it searches for some
> >> syslinux configuration which is not found. Probably patching the
> >> default environment when SPL_FEL is selected would do the trick but
> >> did not get to it.
> >
> > That's why I asked you earlier whether you want to be provided with
> > such instructions ;-)
> >
> > I'm currently using the following u-boot patch for FEL booting u-boot,
> > kernel and initramfs (with serial console on MicroSD breakout):
> >
> > diff --git a/include/configs/sunxi-common.h
> > b/include/configs/sunxi-common.h index f7e87a2..e958bd0 100644
> > --- a/include/configs/sunxi-common.h
> > +++ b/include/configs/sunxi-common.h
> > @@ -330,6 +330,11 @@
> > CONSOLE_STDIN_SETTINGS \
> > CONSOLE_STDOUT_SETTINGS
> >
> > +#if defined(CONFIG_UART0_PORT_F)
> > +#undef BOOTENV
> > +#define BOOTENV "bootcmd=source ${scriptaddr}\0"
> > +#endif
> > +
>
> Yes, I expected that some bit like this is missing because the script
> is uploaded over FEL and then ignored by u-boot.
>
> The condition should be CONFIG_SPL_FEL because you want this any time
> FEL is used regardless of used uart.
Well, not really. One might want to just upload u-boot using FEL, but
boot the rest of the system from USB or SATA hard drive via "some
syslinux configuration".
> Maybe it's mostly safe to use
> always because on non-fel boot the area will not have valid u-boot
> image.
>
> > #define CONFIG_EXTRA_ENV_SETTINGS \
> > CONSOLE_ENV_SETTINGS \
> > MEM_LAYOUT_ENV_SETTINGS \
> >
> >
> > The 'boot.scr' file needs to be uploaded to the right location in RAM
> > ('scriptaddr', which is currently 0x43100000) using the 'fel' tool too.
>
> Why is this different from the 0x41000000 address used by the old
> u-boot and sunxi-tools usb-boot?
No matter why this happened, we can just hope that the address space
layout is not going to be changed often from now on. Either way,
the 'sunxi-common.h' header file serves as the address space layout
documentation. That's the first place to check when troubleshooting.
> The kernel address also differs on mainline so maybe it's time to just
> make a separate mainline script.
Maybe.
> > And the DTB file needs to be patched to move UART0 pins to the SD card
> > slot. This DTB patching can be done automatically in u-boot on the
> > device (if u-boot is enhanced to implement this functionality), or on
> > your PC before uploading it to RAM using the 'fel' tool.
>
> When you are using CONFIG_UART0_PORT_F. Would be nice to have the
> automagic DT patching in u-boot since the patching support exists but
> that's more cosmetic issue than anything.
It's not so cosmetic if you still want to have serial console log from
the kernel for debugging things. Yes, this is very much fixable.
Easily fixable even. But since nobody other than me seems to be
interested, it's not very high on my priority list.
> The memory script part is way more important.
It's entirely pointless to discuss this here. This very clearly belongs
to the u-boot mailing list. If there is more than one person who wants
this feature, then there is a higher chance for it to be accepted.
Also take a look at how Hans and Ian work nicely together. It is very
easy to push code of almost any quality into open source software as
long as you have another person readily acking your patches. And
this works great, until you get a heartbleed bug or some other similar
shit discovered :-)
--
Best regards,
Siarhei Siamashka
--
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.
