linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot

[Hans de Goede]

Hi All,

There are 3 topics which I would like to cover in this mail:

1) Switching over to upstream u-boot for the linux-sunxi project
2) How to build upstream u-boot for use with linux-sunxi sunxi-3.4 kernels
3) Adding more boards to upstream u-boot


1. Switching over to upstream u-boot for the linux-sunxi project
================================================================

Upstream u-boot has had sunxi support for a while now, and has slowly been
gaining a lot of features over the linux-sunxi/u-boot-sunxi version at:
https://github.com/linux-sunxi/u-boot-sunxi/

Some of the new features supported upstream are booting from usb, booting from
sata (ahci) and full sun6i (A31) support including SPL support. Also upstream
u-boot supports using hdmi out + an usb keyboard as u-boot console, so that
one does not need to solder a serial console to things like hdmi tv-dongles.

Upstream u-boot also has full sun8i (A23) support in the pipeline including
SPL support.

One of the things which has stopped people from switching to upstream u-boot
so far is that upstream u-boot did not work with the linux-sunxi sunxi-3.4
kernels, but current upstream u-boot git master:
http://git.denx.de/?p=u-boot.git;a=summary

Now also has support for booting older kernels, so it is time that we
stop maintaining linux-sunxi/u-boot-sunxi and start focussing all our
efforts on upstream u-boot.


2. How to build upstream u-boot for use with linux-sunxi sunxi-3.4 kernels
==========================================================================

Here are some example instructions on how to build upstream u-boot for
the Cubietruck:

git clone git://git.denx.de/u-boot.git
cd u-boot
make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig
# If you want to use an upstream kernel the next steps can be skipped (*)
make -j4 CROSS_COMPILE=arm-linux-gnu- menuconfig
# select "ARM architecture" -> "Enable workarounds for booting old kernels"
# exit & save
make -j4 CROSS_COMPILE=arm-linux-gnu- spl/menuconfig
# select "ARM architecture" -> "Enable workarounds for booting old kernels"
# exit & save
# skip to here if you're using an upstream kernel
make -j4 CROSS_COMPILE=arm-linux-gnu-

And now you will have a u-boot-sunxi-with-spl.bin to dd to your sdcard as
usual.

If you look in the upstream configs directory you will already find
defconfig files for a lot of popular boards there, replace
Cubietruck_defconfig with the one for your board to build u-boot for your
board.

See below for instructions on how to add a new board if your board is
missing.

*) These steps can be skipped too when using sun4i (A10) or sun5i (A10s / A13)
with a current linux-sunxi/stage/sunxi-3.4 kernel.


3. Adding more boards to upstream u-boot
========================================

If you own a board which is already supported in linux-sunxi/u-boot-sunxi,
and is not yet upstream, please add support for it, there are 3 simple steps
to add a new board to upstream u-boot, see below. If you've any trouble with
this, but are willing to be listed as a contact person for this board let me
know and I'll create a patch adding the board for you to test.

1) Add the dram_foo.c file for your board from
linux-sunxi/u-boot-sunxi/board/sunxi to upstream u-boot/board/sunxi and add a
line for it to u-boot/board/sunxi/Makefile, see existing lines there for how
this should look.

2) Create a configs/foo_defconfig file for your board, take a look at
configs/Cubietruck_defconfig for an example, typically all the options
found in linux-sunxi/u-boot-sunxi/boards.cfg for the board go in the
CONFIG_SYS_EXTRA_OPTIONS field, except for the boardname define, which
gets replaced with a line like this:

+S:CONFIG_TARGET_CUBIETRUCK=y

3) Add an entry for the board to board/sunxi/MAINTAINERS, with yourself as
contact person for the board. For upstream u-boot we want to have a contact
person for each supported board, so that users have someone to mail who owns
the actual board in case of questions. This is also why we've not simply
copied all the boards from linux-sunxi/u-boot-sunxi to upstream u-boot.

Regards,

Hans

[Emilio López]

Hi Hans,

El 20/12/14 a las 15:27, Hans de Goede escibió:

> Hi All,
>
> There are 3 topics which I would like to cover in this mail:
>
> 1) Switching over to upstream u-boot for the linux-sunxi project

(...)

> Here are some example instructions on how to build upstream u-boot for
> the Cubietruck:
>
> git clone git://git.denx.de/u-boot.git
> cd u-boot
> make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig
> # If you want to use an upstream kernel the next steps can be skipped (*)
> make -j4 CROSS_COMPILE=arm-linux-gnu- menuconfig
> # select "ARM architecture" -> "Enable workarounds for booting old
> kernels"
> # exit & save
> make -j4 CROSS_COMPILE=arm-linux-gnu- spl/menuconfig
> # select "ARM architecture" -> "Enable workarounds for booting old
> kernels"
> # exit & save
> # skip to here if you're using an upstream kernel
> make -j4 CROSS_COMPILE=arm-linux-gnu-
>
> And now you will have a u-boot-sunxi-with-spl.bin to dd to your sdcard as
> usual.

(...)

So I thought it'd be a good idea to move over to mainline uboot, but it
doesn't seem to be working at all on Cubietruck. When applying power to
the board, all I get is

U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

...ad infinitum.

The hardware itself is fine, the NAND bootloader runs OK and I used the
board with an old uboot-sunxi some days back. Any ideas on what may be
going on?

Cheers!

Emilio

[Siarhei Siamashka]

Thanks for reporting this.

First of all, please ensure that there is no obvious misconfiguration.
For example, whether you have really configured u-boot for Cubietruck.

If everything is configured correctly, then it would help a lot to
identify which of the await_bits_set() or await_bits_clear() calls
is failing in 'arch/arm/cpu/armv7/sunxi/dram_sun4i.c' by adding
some extra debugging prints.

--
Best regards,
Siarhei Siamashka

[Emilio López]

Hi,

El 21/12/14 a las 17:28, Siarhei Siamashka escibió:

Sorry for the noise, I messed up and was using the Cubieboard config
instead of the Cubietruck one >.<

Seems to work fine other than this warning:

Error: dwmac.1c50000 address ab:cd:ef:ab:cd:ef illegal value

Cheers!

Emilio

[Michal Suchanek]

On 20 December 2014 at 19:27, Hans de Goede <hdeg...@redhat.com> wrote:
> Hi All,
>
> There are 3 topics which I would like to cover in this mail:
>
> 1) Switching over to upstream u-boot for the linux-sunxi project
> 2) How to build upstream u-boot for use with linux-sunxi sunxi-3.4 kernels
> 3) Adding more boards to upstream u-boot
>
>
> 1. Switching over to upstream u-boot for the linux-sunxi project
> ================================================================
>
> Upstream u-boot has had sunxi support for a while now, and has slowly been
> gaining a lot of features over the linux-sunxi/u-boot-sunxi version at:
> https://github.com/linux-sunxi/u-boot-sunxi/
>
> Some of the new features supported upstream are booting from usb, booting
> from
> sata (ahci) and full sun6i (A31) support including SPL support. Also
> upstream
> u-boot supports using hdmi out + an usb keyboard as u-boot console, so that
> one does not need to solder a serial console to things like hdmi tv-dongles.
>
> Upstream u-boot also has full sun8i (A23) support in the pipeline including
> SPL support.

Since we have sun8i memory support is there corresponding meminfo
which can dump the timing?

Thanks

Michal

[Hans de Goede]

Hi,

No, just like with previous boards all boards seem to use the same timing
(tpr) values so I've simply hardcoded them. The only 2 things which can be
configured in the sun8i dram code or the dram-clk and the zq value, both
of which (so far) have been filled in in the fex files, so there is no reason
to read it back, moreover reading it back is impossible in the case of the zq
value, as that does not end up 1:1 in a register.

Regards,

Hans

[Hans de Goede]

Hi,

On 21-12-14 21:40, Emilio López wrote:

<snip>

> Sorry for the noise, I messed up and was using the Cubieboard config instead of the Cubietruck one >.<
>
> Seems to work fine other than this warning:
>
> Error: dwmac.1c50000 address ab:cd:ef:ab:cd:ef illegal value

Weird, try doing:

setenv ethaddr
saveenv

It seems you've a bogus ethaddr setting in your environment, or maybe
in uEnv.txt ?

Or alternatively, nuke your environment so that you get the default
one using:

sudo dd if=/dev/zero of=/dev/sdc bs=1024 seek=544 count=256

Replacing sdc with the block device for your sdcard reader,
e.g. mmcblk0. Using the default env will get you closer to how most
people will be using upstream u-boot, so running with the default env
is preferred.

Regards,

Hans

[Ian Campbell]

On Mon, 2014-12-22 at 14:53 +0100, Hans de Goede wrote:
> Or alternatively, nuke your environment so that you get the default
> one using:
>
> sudo dd if=/dev/zero of=/dev/sdc bs=1024 seek=544 count=256

You can do this with the env command from the u-boot cmdline too. I
forget the parameters, but they are in "help env".

Ian.

[Siarhei Siamashka]

On Mon, 22 Dec 2014 14:50:09 +0100

It still makes a lot of sense having a tool, which recovers as much of
the 'dram_para' struct as possible. At least this can provide a way to
verify the correctness of the sun8i dram code in u-boot, if compared
with the same results obtained on a system with the allwinner boot0
bootloader. And also compared with the settings from FEX.

Hans, do you remember your recent screw-up with the axp152 regulators?
http://lists.denx.de/pipermail/u-boot/2014-October/191528.html
You noticed the problem only several months after introducing this
regression. This could be discovered because you were playing with the
sunxi-3.4 kernel, and thankfully it was able to report the voltage,
originally set by the bootloader. Had you thought about a way to test
your axp152 tweaks at the time when you had initially implemented them,
this regression could have been avoided altogether.

Exactly the same applies here. The sun8i dram code contains some weird
dram parameters scrambling before they are written to the registers
among other things. How can we be sure that you have really correctly
transplanted all of the boot0 logic into your C code without any typo
or missing anything in the process? Especially considering that you are
not disclosing any details about the way you have done this, or the
exact boot0 binary that was used to borrow this logic from.

Reading back from the hardware registers via /dev/mem and comparing
this data with the expected values could definitely help. And no, it's
not something that some other person could maybe do in some distant
future. This is a necessary action to ensure the sun8i dram code
quality, which is better to be done right now.

[Jens Thiele]

Hans de Goede <hdeg...@redhat.com> writes:

> 2) How to build upstream u-boot for use with linux-sunxi sunxi-3.4 kernels

[...]

just wanted to report: success
and thank you!
will switch to upstream u-boot

works for me using:

A20-OLinuXino-MICRO + A13-LCD10TS (A20-OLinuXino_MICRO_defconfig)
and
slightly modified (older) sunxi-3.4 kernel (vmlinuz-3.4.75+)

had some trouble getting my own modifications to work at first (maybe
uEnv.txt isn't used at all?) but after all succeeded on the u-boot
command line using:

setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait loglevel=8
load mmc 0 0x43000000 script.bin
load mmc 0 0x48000000 vmlinuz-3.4.75+
bootz 0x48000000

greetings,
jens

[Hans de Goede]

Hi,

On 23-12-14 10:59, Jens Thiele wrote:
> Hans de Goede <hdeg...@redhat.com> writes:
>
>> 2) How to build upstream u-boot for use with linux-sunxi sunxi-3.4 kernels
>
> [...]
>
> just wanted to report: success
> and thank you!
> will switch to upstream u-boot
>
> works for me using:
>
> A20-OLinuXino-MICRO + A13-LCD10TS (A20-OLinuXino_MICRO_defconfig)
> and
> slightly modified (older) sunxi-3.4 kernel (vmlinuz-3.4.75+)
>
> had some trouble getting my own modifications to work at first (maybe
> uEnv.txt isn't used at all?)

Correct, the default environment of upstream u-boot does not read uEnv.txt,
but usually old setups come with a boot.scr which does read uEnv.txt and it
should honor your boot.scr, this works for e.g. the Fedora allwinner remix
images.

> but after all succeeded on the u-boot
> command line using:
>
> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait loglevel=8
> load mmc 0 0x43000000 script.bin
> load mmc 0 0x48000000 vmlinuz-3.4.75+
> bootz 0x48000000

Good.

I see that you've a 10" olimex lcd module to go with your A20-OLinuXino-MICRO,

I've written lcd support for u-boot (currently under review before going upstream),
and I've tested it with the 7" olimex lcd module, it would be nice to also include
an example defconfig for the 10" lcd module for users.

I've created and attached a defconfig for 20-OLinuXino-MICRO + A13-LCD10TS, can you
give this a try with my personal git tree, sunxi-wip branch:

https://github.com/jwrdegoede/u-boot-sunxi/tree/sunxi-wip

Just drop the attached file under the configs dir, and follow the normal
build instructions using A20-OLinuXino_MICRO-lcd10_defconfig in the config
step.

This should give you u-boot boot messages on the lcd screen, and allow you
to interact with u-boot without needing a serial console, if you've a usb keyboard
plugged in. Note u-boot currently lacks usb-1 support, so you need to plug in the
keyboard via a usb-2 hub. Also u-boot will default to hdmi output if you've
something plugged in to the hdmi port, so to test the lcd unplug anything
you may have in plugged into the hdmi port.

Note that when used with a 3.19 kernel + this patch:
https://github.com/jwrdegoede/linux-sunxi/commit/d1b7faa5c69ef1ad52b739aa88cd803e08955360
This will also give you video out support while using an upstream kernel.

Please let me know how this goes, if it works I'll add this defconfig to upstream
u-boot, so that people who want to use the 10" lcd module with a olinuxino board
will have an example defconfig to work from.

Regards,

Hans

[Julian Calaby]

Hi Hans,

Stupid question: for a tablet, shouldn't the LCD parameters go in the
device tree? or are we currently in the chicken vs egg situation where
we don't have full kernel video out support, so no device tree, but
u-boot now has LCD support?

Thanks,

--
Julian Calaby

Email: julian...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[Hans de Goede]

Hi,

Right, the chicken-and-egg thing, in the long run I want to see the LCD
parameters be moved to devicetree, this will also allow doing things like
using dt overlays for add-on modules like the olimex lcd panels.

But we need kernel lcd support with stable dt bindings before we can use this
in u-boot as I don't want u-boot to have a different dt (binding) from the
kernel.

Note I could have also putten the lcd-timing info in the environment, for the
olimex case that makes some sense, but I've deliberately not done so as the
Kconfig stuff can simply be dropped when we get dt support for this, where as
with env settings I feel we would need to maintain some form of backward
compatibility.

Regards,

Hans

[Jens Thiele]

Hans de Goede <hdeg...@redhat.com> writes:

[...]

> Correct, the default environment of upstream u-boot does not read uEnv.txt,
> but usually old setups come with a boot.scr which does read uEnv.txt and it
> should honor your boot.scr, this works for e.g. the Fedora allwinner remix
> images.

i see, thanks.
(didn't have a boot.scr myself)

> I see that you've a 10" olimex lcd module to go with your A20-OLinuXino-MICRO,
>
> I've written lcd support for u-boot (currently under review before going upstream),
> and I've tested it with the 7" olimex lcd module, it would be nice to also include
> an example defconfig for the 10" lcd module for users.
>
> I've created and attached a defconfig for 20-OLinuXino-MICRO + A13-LCD10TS, can you
> give this a try with my personal git tree, sunxi-wip branch:
>
> https://github.com/jwrdegoede/u-boot-sunxi/tree/sunxi-wip

get an error at the moment (native compile on debian/jessie/armhf):

LD u-boot
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(bpabi.o)
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_divdi3.o)
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_udivdi3.o)
Makefile:1065: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1

greetings,
jens

[Hans de Goede]

Hi,

Weird, you did build upstream u-boot from source for your previous tests. right?

and then it did work, right ?

Regards,

Hans

[Chen-Yu Tsai]

It seems some recent changes in upstream broke building with hard float
toolchains. Best use soft float.

It's probably these commits:

bf1af3d ARM: merge commonly-defined PLATFORM_RELFLAGS
3102274 ARM: refactor compiler options in config.mk

ChenYu

[Jens Thiele]

Chen-Yu Tsai <we...@csie.org> writes:

> On Mon, Dec 29, 2014 at 12:11 AM, Hans de Goede <hdeg...@redhat.com> wrote:
>>
>> Weird, you did build upstream u-boot from source for your previous tests.
>> right?
>>
>> and then it did work, right ?

yes

> It seems some recent changes in upstream broke building with hard float
> toolchains. Best use soft float.
>
> It's probably these commits:
>
> bf1af3d ARM: merge commonly-defined PLATFORM_RELFLAGS
> 3102274 ARM: refactor compiler options in config.mk

only had little time
=> just rebuilt using debian/jessie/armel toolchain and the result is:
A20-OLinuXino-MICRO + A13-LCD10TS + USB keyboard works with u-boot \o/
thanks!

kernel test will follow as time permits

jens

[Hans de Goede]

Hi,

Thanks for the testing, that is good to hear.

Regards,

Hans

[B.R. Oake]

On 28/12/14 15:51, Jens Thiele wrote:> get an error at the moment (native compile on debian/jessie/armhf):

> LD u-boot
> ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not

> ...

On 28/12/14 16:15, Chen-Yu Tsai wrote:
> It seems some recent changes in upstream broke building with hard float
> toolchains. Best use soft float.

I also encountered this error when trying to build mainline u-boot on
Debian Jessie armhf. I got it to build by adding -mfloat-abi=hard to
KBUILD_CFLAGS in the main Makefile, and the resulting u-boot seems to
work fine, but I don't know if there are any downsides to this approach.

Best wishes,
B.R. Oake.

[Michal Suchanek]

Hello,

Is this being fixed?

Depending on particular toolchain default ABI just because somebody
decided to frob compiler options is kind of stupid.

Thanks

Michal

[Jens Thiele]

Hans de Goede <hdeg...@redhat.com> writes:

[...]

> Note that when used with a 3.19 kernel + this patch:
> https://github.com/jwrdegoede/linux-sunxi/commit/d1b7faa5c69ef1ad52b739aa88cd803e08955360
> This will also give you video out support while using an upstream kernel.

just tested - and it works :-)

what's missing:
- touchscreen doesn't work (not sure why)
- dpms / switch lcd off (seems like this is expected with simplefb)

greetings,
jens

[Hans de Goede]

Hi,

On 10-01-15 21:38, Jens Thiele wrote:
> Hans de Goede <hdeg...@redhat.com> writes:
>
> [...]
>
>> Note that when used with a 3.19 kernel + this patch:
>> https://github.com/jwrdegoede/linux-sunxi/commit/d1b7faa5c69ef1ad52b739aa88cd803e08955360
>> This will also give you video out support while using an upstream kernel.
>
> just tested - and it works :-)
>
> what's missing:
> - touchscreen doesn't work (not sure why)

Likely because the upstream kernel does not yet have a driver for it.

> - dpms / switch lcd off (seems like this is expected with simplefb)

Correct, this is expected with simplefb.

Regards,

Hans

[Jens Thiele]

Hans de Goede <hdeg...@redhat.com> writes:

> On 10-01-15 21:38, Jens Thiele wrote:
>> what's missing:
>> - touchscreen doesn't work (not sure why)
>
> Likely because the upstream kernel does not yet have a driver for it.

thought it is sun4i-ts and that it is already in mainline, but will
have to take a look...

greetings,
jens

[Jens Lucius]

I am also trying to get the touchscreen working (olimex 4.3 Inch display works fine, thanks!)

I tried using the driver in the mainline kernel which I suppose was posted first here:
https://groups.google.com/forum/#!topic/linux-sunxi/DzcsAsvmrcM

Any reason why this should not work (Olimex A20-Micro for me)?

Thanks,

Jens

[Hans de Goede]

Hi,

Ah, sorry I did not look at $subject, and thought we we were talking
about a capacative touchscreen as found on most tablets.

So yes support for a resistive touchscreen with the build-in resistive
touchscreen controller is upstream, and ti should work fine.

I'm pretty sure about that as I wrote the code :)

But to use this you must explicitly enable it in devicetree, iow you
need this change:

--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -155,6 +155,10 @@
};
};

+ rtp: rtp@01c25000 {
+ allwinner,ts-attached;
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;

And then rebuild the dtb, and put it where your boot setup
searches for the dtb.

Then you can run e.g. evemu-record from a text-console and it
should show a touchscreen and report events when you press it.

Then follow this howto:
http://www.dimrobotics.com/2013/06/olinuxino-a13-touchscreen-support-in.html
To get it to work with Xorg

I've not yet tried this with the new simplefb stuff, but it
should work. Let me know if you hit any problems.

Regards,

Hans

[Hans de Goede]

Hi,

On 11-01-15 23:03, Jens Lucius wrote:
> I am also trying to get the touchscreen working (olimex 4.3 Inch display
> works fine, thanks!)
>
> I tried using the driver in the mainline kernel which I suppose was posted
> first here:
> https://groups.google.com/forum/#!topic/linux-sunxi/DzcsAsvmrcM
>
> Any reason why this should not work (Olimex A20-Micro for me)?

Same story as my answer to the other Jens, copy and pasted here for
convenience:

[Jens Thiele]

Hans de Goede <hdeg...@redhat.com> writes:

> Ah, sorry I did not look at $subject, and thought we we were talking
> about a capacative touchscreen as found on most tablets.
>
> So yes support for a resistive touchscreen with the build-in resistive
> touchscreen controller is upstream, and ti should work fine.
>
> I'm pretty sure about that as I wrote the code :)
>
> But to use this you must explicitly enable it in devicetree, iow you
> need this change:
>
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> @@ -155,6 +155,10 @@
> };
> };
>
> + rtp: rtp@01c25000 {
> + allwinner,ts-attached;
> + };
> +
> uart0: serial@01c28000 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pins_a>;
>
> And then rebuild the dtb, and put it where your boot setup
> searches for the dtb.

done

> Then you can run e.g. evemu-record from a text-console and it
> should show a touchscreen and report events when you press it.
>
> Then follow this howto:
> http://www.dimrobotics.com/2013/06/olinuxino-a13-touchscreen-support-in.html
> To get it to work with Xorg

skipped that and just tested with my old (sunxi-3.4) config and it
worked out of the box - yeah :-)

(only had to re-run xinput_calibrator)

thanks very much!
greetings
jens (t)

PS: maybe the sensitivity parameters (TP_SENSITIVE_ADJUST) could use
some tweaking - afair i had "better" results using less sensitivity
(afair high sensitivity caused many jumps heading to 0,0 if touching
only slightly)

[Jens Thiele]

Michal Suchanek <hram...@gmail.com> writes:

> Is this being fixed?
>
> Depending on particular toolchain default ABI just because somebody
> decided to frob compiler options is kind of stupid.

for the archives:
looks like this is fixed in current¹ master (didn't find when/how this
was fixed)?

jens

¹ f411b8f2270bc75113d60f2ad662f25de6242b7d

[Hans de Goede]

Hi,

On 12-01-15 15:57, Jens Thiele wrote:
> Michal Suchanek <hram...@gmail.com> writes:
>
>> Is this being fixed?
>>
>> Depending on particular toolchain default ABI just because somebody
>> decided to frob compiler options is kind of stupid.
>
> for the archives:
> looks like this is fixed in current¹ master (didn't find when/how this
> was fixed)?

The problem was that a commit in my sunxi-wip branch was doing 64 bit
integer math, which causes problems when the toolchain does not have
soft-float support libs even though it is not float related ...

This has been fixed by rewriting the code to do things in a way which
fits into 32 bits integers.

Regards,

Hans

[Jens Thiele]

Hans de Goede <hdeg...@redhat.com> writes:

> The problem was that a commit in my sunxi-wip branch was doing 64 bit
> integer math, which causes problems when the toolchain does not have
> soft-float support libs even though it is not float related ...

scary (browsing through the git log it looks like other arches also had
that problem).

> This has been fixed by rewriting the code to do things in a way which
> fits into 32 bits integers.

I see, thanks. (I likely didn't find the change because you did a git
rebase right?)

Greetings,
jens

[Jens Thiele]

Hans de Goede <hdeg...@redhat.com> writes:

> I've created and attached a defconfig for 20-OLinuXino-MICRO + A13-LCD10TS, can you
> give this a try with my personal git tree, sunxi-wip branch:
>
> https://github.com/jwrdegoede/u-boot-sunxi/tree/sunxi-wip
>

[...]

> CONFIG_SPL=y
> CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI"
> CONFIG_FDTFILE="sun7i-a20-olinuxino-micro.dtb"
> CONFIG_MMC_SUNXI_SLOT_EXTRA=3
> CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:45000,le:150,ri:16,up:21,lo:2,hs:10,vs:2,sync:3,vmode:0"
> CONFIG_VIDEO_LCD_POWER="PH8"
> CONFIG_VIDEO_LCD_BL_EN="PH7"
> CONFIG_VIDEO_LCD_BL_PWM="PB2"
> +S:CONFIG_MMC0_CD_PIN="PH1"
> +S:CONFIG_MMC3_CD_PIN="PH11"
> +S:CONFIG_ARM=y
> +S:CONFIG_ARCH_SUNXI=y
> +S:CONFIG_MACH_SUN7I=y
> +S:CONFIG_TARGET_A20_OLINUXINO_M=y

will you re-add A20-OLinuXino_MICRO-lcd10_defconfig to your sunxi-wip
branch or did you change your mind?

would it be somehow possible to detect connected lcds?
or at least a connected touchscreen?
i think most will either connect the lcd with touchscreen or no lcd all?
this would allow a single u-boot for the board:
lcd connected => use lcd
hdmi connected => use hdmi
otherwise vga?

jens

[Hans de Goede]

Hi,

On 18-01-15 13:42, Jens Thiele wrote:
> Hans de Goede <hdeg...@redhat.com> writes:
>
>> I've created and attached a defconfig for 20-OLinuXino-MICRO + A13-LCD10TS, can you
>> give this a try with my personal git tree, sunxi-wip branch:
>>
>> https://github.com/jwrdegoede/u-boot-sunxi/tree/sunxi-wip
>>
>
> [...]
>
>> CONFIG_SPL=y
>> CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI"
>> CONFIG_FDTFILE="sun7i-a20-olinuxino-micro.dtb"
>> CONFIG_MMC_SUNXI_SLOT_EXTRA=3
>> CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:45000,le:150,ri:16,up:21,lo:2,hs:10,vs:2,sync:3,vmode:0"
>> CONFIG_VIDEO_LCD_POWER="PH8"
>> CONFIG_VIDEO_LCD_BL_EN="PH7"
>> CONFIG_VIDEO_LCD_BL_PWM="PB2"
>> +S:CONFIG_MMC0_CD_PIN="PH1"
>> +S:CONFIG_MMC3_CD_PIN="PH11"
>> +S:CONFIG_ARM=y
>> +S:CONFIG_ARCH_SUNXI=y
>> +S:CONFIG_MACH_SUN7I=y
>> +S:CONFIG_TARGET_A20_OLINUXINO_M=y
>
> will you re-add A20-OLinuXino_MICRO-lcd10_defconfig to your sunxi-wip
> branch or did you change your mind?

We've decided to not carry defconfig-s for board + addon combos upstream as
that simply leads to a too large explosion of defconfig-s, instead for
LCD-s we've created this page where the necessary info can be found:
http://linux-sunxi.org/LCD

> would it be somehow possible to detect connected lcds?

No.

> or at least a connected touchscreen?

A resistive touchscreen can only be differentiated from not-connected
pins when it is actually pressed, so no.

> i think most will either connect the lcd with touchscreen or no lcd all?

Olimex has sold both versions with and without the touchscreen for
various lcd displays.

Regards,

Hans

[Ezaul Zillmer]

Hello

How could run u-boot with lcd with
Cubieboard2 + DVK-521 using Kernke 3.19rc3
u-boot-wip with HDMI is already running
not get to do the LCD picture

Configuration it would be LCD e toud

fex

[disp_init]
disp_init_enable = 1
disp_mode = 0
screen0_output_type = 1
screen0_output_mode = 4
screen1_output_type = 0
screen1_output_mode = 4
fb0_width = 1024
fb0_height = 768
fb0_framebuffer_num = 2
fb0_format = 10
fb0_pixel_sequence = 0
fb0_scaler_mode_enable = 0
fb1_width = 1024
fb1_height = 768
fb1_framebuffer_num = 2
fb1_format = 10
fb1_pixel_sequence = 0
fb1_scaler_mode_enable = 0
lcd0_backlight = 197
lcd1_backlight = 197
lcd0_bright = 50
lcd0_contrast = 50
lcd0_saturation = 57
lcd0_hue = 50
lcd1_bright = 50
lcd1_contrast = 50
lcd1_saturation = 57
lcd1_hue = 50


[lcd0_para]
lcd_used = 1
lcd_x = 800
lcd_y = 480
lcd_dclk_freq = 33
lcd_pwm_not_used = 0
lcd_pwm_ch = 0
lcd_pwm_freq = 10000
lcd_pwm_pol = 0
lcd_max_bright = 240
lcd_min_bright = 64
lcd_if = 0
lcd_hbp = 215
lcd_ht = 1055
lcd_vbp = 34
lcd_vt = 1050
lcd_vspw = 3
lcd_hspw = 20
lcd_hv_if = 0
lcd_hv_smode = 0
lcd_hv_s888_if = 0
lcd_hv_syuv_if = 0
lcd_lvds_ch = 0
lcd_lvds_mode = 0
lcd_lvds_bitwidth = 0
lcd_lvds_io_cross = 0
lcd_cpu_if = 0
lcd_frm = 1
lcd_io_cfg0 = 0
lcd_gamma_correction_en = 0
lcd_gamma_tbl_0 = 0x0
lcd_gamma_tbl_1 = 0x10101
lcd_gamma_tbl_255 = 0xffffff
lcd_bl_en_used = 1
lcd_bl_en = port:PH07<1><0><default><1>
lcd_power_used = 1
lcd_power = port:PH08<1><0><default><1>
lcd_pwm_used = 1
lcd_pwm = port:PB02<2><0><default><default>
lcd_gpio_0 = port:PH15<0><0><default><default>
lcd_gpio_1 =
lcd_gpio_2 =
lcd_gpio_3 =
lcdd0 = port:PD00<2><0><default><default>
lcdd1 = port:PD01<2><0><default><default>
lcdd2 = port:PD02<2><0><default><default>
lcdd3 = port:PD03<2><0><default><default>
lcdd4 = port:PD04<2><0><default><default>
lcdd5 = port:PD05<2><0><default><default>
lcdd6 = port:PD06<2><0><default><default>
lcdd7 = port:PD07<2><0><default><default>
lcdd8 = port:PD08<2><0><default><default>
lcdd9 = port:PD09<2><0><default><default>
lcdd10 = port:PD10<2><0><default><default>
lcdd11 = port:PD11<2><0><default><default>
lcdd12 = port:PD12<2><0><default><default>
lcdd13 = port:PD13<2><0><default><default>
lcdd14 = port:PD14<2><0><default><default>
lcdd15 = port:PD15<2><0><default><default>
lcdd16 = port:PD16<2><0><default><default>
lcdd17 = port:PD17<2><0><default><default>
lcdd18 = port:PD18<2><0><default><default>
lcdd19 = port:PD19<2><0><default><default>
lcdd20 = port:PD20<2><0><default><default>
lcdd21 = port:PD21<2><0><default><default>
lcdd22 = port:PD22<2><0><default><default>
lcdd23 = port:PD23<2><0><default><default>
lcdclk = port:PD24<2><0><default><default>
lcdde = port:PD25<2><0><default><default>
lcdhsync = port:PD26<2><0><default><default>
lcdvsync = port:PD27<2><0><default><default>


[ctp_para]

ctp_used = 1
ctp_name = "ft5x_ts"
ctp_twi_id = 1
ctp_twi_addr = 0x38
ctp_screen_max_x = 800
ctp_screen_max_y = 480
ctp_revert_x_flag = 0
ctp_revert_y_flag = 1
ctp_exchange_x_y_flag = 0
ctp_firm = 1
ctp_wakeup = port:PB13<1><default><default><1>

[ctp_list_para]
ctp_det_used = 1
ft5x_ts = 1
gt82x = 0
gslX680 = 0
gt9xx_ts = 0
gt811 = 0

[gpio_para]
gpio_pin_3 = port:PH07<6><default><default><default>

[Siarhei Siamashka]

On Sun, 18 Jan 2015 11:38:06 -0800 (PST)
Ezaul Zillmer <ezaulz...@gmail.com> wrote:

> Hello
>
> How could run u-boot with lcd with
> Cubieboard2 + DVK-521 using Kernke 3.19rc3
> u-boot-wip with HDMI is already running
> not get to do the LCD picture
>
> Configuration it would be LCD e toud
>
> fex

[...]

There are several options:

1. If you can ensure that your fex file is available in the sunxi-boards
repository, then you will get your LCD settings available on the
http://linux-sunxi.org/LCD wiki page after the next round of automatic
conversion.

2. If you are really impatient, then you can go to
http://linux-sunxi.org/LCD#Script_for_automated_conversion
Then copy/paste this script into some file with *.rb extension
and run it on your fex file to get the CONFIG_VIDEO_LCD_MODE line
for your board.

This is currently work in progress and will definitely change in the
near future. There is no reason why we can't get complete u-boot
defconfigs (not just LCD settings alone) generated from fex files
automatically. Along with dts/dtb files for the kernel. Stay tuned.

[Jens Thiele]

Hans de Goede <hdeg...@redhat.com> writes:

> Hi,
>
> On 18-01-15 13:42, Jens Thiele wrote:
>> will you re-add A20-OLinuXino_MICRO-lcd10_defconfig to your sunxi-wip
>> branch or did you change your mind?
>
> We've decided to not carry defconfig-s for board + addon combos upstream as
> that simply leads to a too large explosion of defconfig-s, instead for
> LCD-s we've created this page where the necessary info can be found:
> http://linux-sunxi.org/LCD

i see, thanks!

>> would it be somehow possible to detect connected lcds?
>
> No.
>
>> or at least a connected touchscreen?
>
> A resistive touchscreen can only be differentiated from not-connected
> pins when it is actually pressed, so no.

:(

>> i think most will either connect the lcd with touchscreen or no lcd all?
>
> Olimex has sold both versions with and without the touchscreen for
> various lcd displays.

thanks, again
jens

[Peter Mattern]

Hi.

While testing your instructions I happened to see that
u-boot-sunxi-with-spl.bin's size is exactly the same with or without
"Enable workarounds for booting old kernels" set as described in your mail.
This got me wonder about the effects of the said option. Am I correct by
supposing as of now the only effect is setting "Boot in secure mode by
default" or is there anything else?

The reason to ask is that this in turn made me wonder whether it may be
feasible to boot linux-sunxi and mainline kernel alternately on one
device by using only one U-Boot binary (u-boot-sunxi-with-spl.bin) and
changing e. g. boot.scr. only.

Regards,

Peter Mattern

[Hans de Goede]

Hi,

Setting "Enable workarounds for booting old kernels" also changes a divider
in pll5, as older linux-sunxi kernels have the divider hardcoded rather then
looking at what the bootloader actually programmed. Other then that it indeed
only changes "Boot in secure mode by default" which can be changed by setting
the "bootm_boot_mode" env variable to either "sec" or "nonsec" before calling
bootm.

Note that the latest sunxi-3.4/next kernels do not suffer from the PLL5
divider issue, and you can boot a new kernel just fine with the slightly
less optimal pll5 div chosen when building with "Enable workarounds for booting
old kernels"

So yes you can boot both kernels with a single u-boot binary.

Regards,

Hans

[Peter Mattern]

Am 19.01.2015 um 15:55 schrieb Hans de Goede:
> Setting "Enable workarounds for booting old kernels" also changes a
> divider
> in pll5, as older linux-sunxi kernels have the divider hardcoded
> rather then
> looking at what the bootloader actually programmed. Other then that it
> indeed
> only changes "Boot in secure mode by default" which can be changed by
> setting
> the "bootm_boot_mode" env variable to either "sec" or "nonsec" before
> calling
> bootm.
>
> Note that the latest sunxi-3.4/next kernels do not suffer from the PLL5
> divider issue, and you can boot a new kernel just fine with the slightly
> less optimal pll5 div chosen when building with "Enable workarounds
> for booting
> old kernels"
>
> So yes you can boot both kernels with a single u-boot binary.
>
> Regards,
>
> Hans
>

That's exactly the kind of information I was hoping to get. Thanks a lot.

Regards,

Peter Mattern

[Iain Paton]

On 19/01/15 14:55, Hans de Goede wrote:

> only changes "Boot in secure mode by default" which can be changed by setting
> the "bootm_boot_mode" env variable to either "sec" or "nonsec" before calling
> bootm.

Question, how can I do that when only using extlinux.conf ?

It would be really nice to be able to easily boot between different kernel
versions from an extlinux.conf boot menu, and this works fine for mainline.
Booting older 3.4.x this way seems challenging wrt to things like setting this
variable, loading fex files etc.

[Hans de Goede]

Hi,

On 20-01-15 18:02, Iain Paton wrote:
> On 19/01/15 14:55, Hans de Goede wrote:
>
>> only changes "Boot in secure mode by default" which can be changed by setting
>> the "bootm_boot_mode" env variable to either "sec" or "nonsec" before calling
>> bootm.
>
> Question, how can I do that when only using extlinux.conf ?

I'm afraid the answer to that it is not possible.

Regards,

Hans

[Andrey Tarasov]

Hi

I have an A10S based board which successfully running legacy u-boot and Linux kernels built for mk802_a10s. Except for reported DRAM size is 512 MB instead of 1024 MB. But when i try to run mainline u-boot compiled for the same target (mk802_a10s_config) the board does not boot. Nothing happens, no output on console, TX pin is in tri-state.
Whether it is possible to build fail-safe version of mainline u-boot with minimum dependency from hardware environment?

Thanks
Andrey