Re: [U-Boot] [PATCHv1] mx53ppd: Change UART clock divider for high baudrate
Hi Fabio, First a disclaimer. I no longer work for the client that had me make this change. I also no longer have any iMX53 hardware to do any kind of tests. But I'm happy to help out with this email. > Hi Rick and Sebastian, > > On Thu, Feb 15, 2018 at 2:15 PM, Sebastian Reichel > <sebastian.reic...@collabora.co.uk> wrote: > > From: Rick Bronson <r...@efn.org> > > > > Allow higher UART baud rates for communications to ACHC at 13.5 MBaud > > What does ACHC mean? ACHC is an product acronym, probably should change that sentence to: Allow higher UART baud rates for communications up to 13.5 MBaud > > Done in u-boot since it changes a divider common to all UARTs, including > > the console. If it were done in Linux we would get garbled characters > > during the handoff from u-boot to the kernel. > > It would be nice to explain a bit how you achieve the higher baud rates. Background: PLL2 runs at 400 MHz, PLL3 runs at 216 MHz. One of these PLL's are fed to a UART divider, the output of which sets the maximum UART baud rates that are based on these rates divided by 16. Before patch: PLL3 (400 MHz) for UART's, divide by 6, get 66.66 MHz from it. Max baud rate is 4.166 MBaud. After patch: PLL2 (216 MHz), divide by 1, get 216 MHz from it. Max baud rate is 13.5 MBaud. The last I saw this code was 2014 so it's a little fuzzy. Not sure why I didn't keep PLL3 and just change the divider from 6 to 3, that would have allowed a max of 8.33 MBaud and at the time, I was just looking for at least 8 MBaud. > > Looks like you don't use PLL2 as the UART clock anyomore. That's correct, see above. > > Please expland a bit further on the new UART clock sheme. > > > > > Signed-off-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk> > > --- > > arch/arm/mach-imx/mx5/lowlevel_init.S | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/arch/arm/mach-imx/mx5/lowlevel_init.S b/arch/arm/mach-imx/mx5/lowlevel_init.S > > index f5bc6728b7c2..ee4c3afd2fed 100644 > > --- a/arch/arm/mach-imx/mx5/lowlevel_init.S > > +++ b/arch/arm/mach-imx/mx5/lowlevel_init.S > > @@ -319,11 +319,13 @@ setup_pll_func: > > ldr r1, =0x00016154 > > str r1, [r0, #CLKCTL_CBCMR] > > > > +#if !defined(CONFIG_TARGET_MX53PPD) > > It would be better if this option could be a generic one, something > like CONFIG_MX53_SERIAL_HIGHBAUD, so that other boads could use it if > needed. Yes it probably would. Cheers, Rick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockchip RK3288 boot trouble
Hi Kever and Simon, Thanks very much for the help. Really appreciate it. > I didn't see your detail steps for getting u-boot-dtb.bin, does it > include SPL here? I'm using this method: > 2. with "CONFIG_ROCKCHIP_SPL_BACK_TO_BROM", which is default setting ... > I'm confusing with this incorrect DRAM size, could you share the console > output > during you flash the image, there should have correct DRAM size info. > I'm not sure if the DRAM on your board is symmetric or not, or any else > special. See below for the output. I noticed that I only have "Channel b" and not "Channel a". On my other board that boots, I have both a and b. I wonder if one bank of DDR3 went bad on this board. What do you think? Thanks again. Rick DDR Version 1.00 20160217 In Channel b: DDR3 200MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=8 Size=1024MB Memory OK OUT usb boot ver:20160218 ChipType = 8 ...FlashInit enter... FtlMallocOffset = 8040 8000 FtlMallocOffset = 10040 8000 FtlMallocOffset = 11040 1000 FtlMallocOffset = 19040 8000 FtlMallocOffset = 1a040 1000 1:0 0 7f7f05 22 ...NandcInit enter... 0:1200 0 7f7f05 22 FtlMallocOffset = 23040 9000 gNandcVer = 6 SDC_BusRequest: CMD=8 SDC_RESP_TIMEOUT 1815 SDC_BusRequest: CMD=8 SDC_RESP_TIMEOUT 1815 SDC_BusRequest: CMD=8 SDC_RESP_TIMEOUT 1815 SDC_BusRequest: CMD=5 SDC_RESP_TIMEOUT 1815 SDC_BusRequest: CMD=5 SDC_RESP_TIMEOUT 1815 SDC_BusRequest: CMD=5 SDC_RESP_TIMEOUT 1815 SDC_BusRequest: CMD=55 SDC_RESP_TIMEOUT 1815 SDC_BusRequest: CMD=55 SDC_RESP_TIMEOUT 1815 SDC_BusRequest: CMD=55 SDC_RESP_TIMEOUT 1815 mmc Ext_csd, ret=0 , Ext[226]=20, bootSize=2000, Ext[215]=1, Ext[214]=d5, Ext[213]=a0, Ext[212]=0,cap =1d5a000 R EL=1f SdmmcInit=2 0 BootCapSize=2000 UserCapSize=1d5a000 FwPartOffset=2000 , 2000 UsbHook 622396 powerOn 623080 DDR Version 1.00 20160217 In SRX Channel b: DDR3 200MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=8 Size=1024MB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Rockchip RK3288 boot trouble
Hi All,
I updated one of my two RK3288 boards (Viewsonic) with newer Android
factory firmware (using Windows) and now it won't boot mainline u-boot
when I use the same exact recipe that worked previously:
sudo ${UPGD} db rkbin/rk32/rk3288_boot.bin
sudo ${UPGD} wl 0x40 tftpboot/u-boot-dtb.bin
Been trying to figure out what's wrong. My theory is that the newer
firmware enabled one of the "boot areas" of the eMMC and the "wl 0x40"
command above only writes to the user area of the eMMC.
I can still load and run one of the Android u-boots using the
boot_merger method:
./tools/boot_merger --subfix ".10.bin" ./tools/rk_tools/RKBOOT/RK3288.ini
then flashing via:
sudo ${UPGD} ul u-boot-android/RK3288UbootLoader_V2.30.10.bin
But these u-boot's are virtually useless since they striped of
useful commands (like mmc commands).
I tried using the above boot_merger command on mainline u-boot but
it only boots this far (I've tried u-boot-dtb.bin and u-boot.bin):
--
U-Boot 2016.11-08467-g05b8ba7-dirty (Jan 15 2017 - 10:40:37 -0800)
Model: SCT36-RK3288
DRAM: 128 MiB
--
Note the incorrect DRAM size. My normal boot looks like:
--
U-Boot SPL 2016.11-08467-g05b8ba7-dirty (Dec 18 2016 - 11:00:14)
U-Boot 2016.11-08467-g05b8ba7-dirty (Dec 18 2016 - 11:00:14 -0800)
Model: SCT36-RK3288
DRAM: 2 GiB
MMC: dwmmc@ff0c: 0, dwmmc@ff0f: 1
...
--
Note that this runs SPL, then normal u-boot whereas the previous one
didn't run SPL.
Any ideas how I can get mainline u-boot running on this board?
Thanks much,
Rick
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rockchip RK3288 regulator device table problem
Hi Simon,
I'm not sure what to do about (in drivers/power/regulator/rk808.c):
static const struct rk808_reg_info rk808_ldo[] = {
{ 100, 10, LDO1_ON_VSEL, 5, },
...
I had to change this table as my LDO values are different for this
board. I'd like to fix it to take values from the device tree but
couldn't find an example. Maybe you can point me to one.
Thanks,
Rick
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rockchip RK3288 regulator device table problem
Hi Simon,
>
> On 9 December 2016 at 18:12, Rick Bronson <r...@efn.org> wrote:
> > Hi All,
> >
> > How do I enable a particular regulator upon boot? I have two
> > identically set LDO entries:
> >
> > vccio_en: LDO_REG1 {
> > regulator-always-on;
> > regulator-boot-on;
> > regulator-min-microvolt = <330>;
> > regulator-max-microvolt = <330>;
> > regulator-name = "vccio_en";
> > regulator-state-mem {
> > regulator-on-in-suspend;
> > regulator-suspend-microvolt =
<330>;
> > };
> > };
> >
> > vcc33_mic: LDO_REG2 {
> > regulator-always-on;
> > regulator-boot-on;
> > regulator-min-microvolt = <330>;
> > regulator-max-microvolt = <330>;
> > regulator-name = "vcc33_mic";
> > regulator-state-mem {
> > regulator-on-in-suspend;
> > regulator-suspend-microvolt =
<330>;
> > };
> > };
> >
> > Yet one is enabled, the other disabled, any idea why?:
> >
> > => regulator status
> > Name EnableduV mA Mode
> > ...
> > vccio_en enabled 330 - -
> > vcc33_micdisabled 330 - -
> >
> > And oddly, the uV values actually don't come from the DT but from
> > the rk808_ldo table in drivers/power/regulator/rk808.c
>
> Do you think this is happening by PMIC settings (in the device) rather
> than through U-Boot?
Think I found the reason for this, it's this way because of the way
BOOT0, BOOT1 are strapped on the RK808.
>
> >
> > Any ideas?
> >
> > Thanks for any help.
> >
>
> There is a function called regulators_enable_boot_on() which enables
> all boot-on regulators that have a fixed voltage, but I don't think
> that is called with rockchip.
>
> Now that I look at it, I cannot see why I put the voltage values in
> the driver. They should come form DT.
Do you think the right way to solve this is (from common/board_r.c):
__weak int power_init_board(void)
{
regulators_enable_boot_on(false);
return 0;
}
Tried this but it seems to introduce a race condition because often, it
hangs.
Cheers,
Rick
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Rockchip RK3288 regulator device table problem
Hi All,
How do I enable a particular regulator upon boot? I have two
identically set LDO entries:
vccio_en: LDO_REG1 {
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vccio_en";
regulator-state-mem {
regulator-on-in-suspend;
regulator-suspend-microvolt = <330>;
};
};
vcc33_mic: LDO_REG2 {
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vcc33_mic";
regulator-state-mem {
regulator-on-in-suspend;
regulator-suspend-microvolt = <330>;
};
};
Yet one is enabled, the other disabled, any idea why?:
=> regulator status
Name EnableduV mA Mode
...
vccio_en enabled 330 - -
vcc33_micdisabled 330 - -
And oddly, the uV values actually don't come from the DT but from
the rk808_ldo table in drivers/power/regulator/rk808.c
Any ideas?
Thanks for any help.
Rick
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
Hi Heiko, Thanks again for the help. Been testing the RK3288 Ethernet and it works pretty good. One thing I was wondering about was that I seemed to have to have: CONFIG_NET_RANDOM_ETHADDR=y or I get: Error: ethernet@ff29 address not set. Is there a better way? Another issue we were having is when attached to a Gigabit switch/router it seemed to have a lot of trouble negociating and would fail often. So, for the time being, I've hooked it to a 100MBit router. Haven't seen any problems with that. Just wondered if you have observed this behavior? Thanks, Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
Hi Heiko,
Thanks very much for the link. I got it, went to the branch,
applied my patches from main denx u-boot and got it to work!
The only odd thing is, I have to do this:
regulator dev vcc_lan
regulator enable
Or else I can't use the networking.
When I boot up I see:
=> regulator status
Name EnableduV mA Mode
...
vcc_lan disabled- - -
I've studied all of the various rk3288*.dts* examples but have no
idea why the vcc_lan does not start up upon boot. My dtsi file is
below. Thanks for any help.
Cheers,
Rick
#include "rk3288.dtsi"
/ {
memory {
device_type = "memory";
reg = <0x0 0x8000>;
};
ext_gmac: external-gmac-clock {
compatible = "fixed-clock";
clock-frequency = <12500>;
clock-output-names = "ext_gmac";
#clock-cells = <0>;
};
gpio-keys {
compatible = "gpio-keys";
#address-cells = <1>;
#size-cells = <0>;
autorepeat;
pinctrl-names = "default";
pinctrl-0 = <>;
button@0 {
gpios = < 5 GPIO_ACTIVE_LOW>;
label = "GPIO Key Power";
linux,input-type = <1>;
gpio-key,wakeup = <1>;
debounce-interval = <100>;
};
};
leds {
u-boot,dm-pre-reloc;
compatible = "gpio-leds";
power {
u-boot,dm-pre-reloc;
gpios = < 11 GPIO_ACTIVE_HIGH>;
label = "sct36:blue:power";
linux,default-trigger = "default-on";
pinctrl-names = "default";
pinctrl-0 = <_led>;
default-state = "on";
};
work {
u-boot,dm-pre-reloc;
gpios = < 0 GPIO_ACTIVE_HIGH>;
label = "sct36:amber:user";
linux,default-trigger = "rc-feedback";
pinctrl-names = "default";
pinctrl-0 = <_led>;
};
};
vcc_sys: vsys-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-always-on;
regulator-boot-on;
};
/*
*
*/
vcc_sd: sdmmc-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_sd";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
startup-delay-us = <10>;
vin-supply = <_io>;
};
};
{
cpu0-supply = <_cpu>;
};
{
broken-cd;
bus-width = <8>;
cap-mmc-highspeed;
disable-wp;
non-removable;
num-slots = <1>;
pinctrl-names = "default";
pinctrl-0 = <_clk>, <_cmd>, <_pwr>, <_bus8>;
vmmc-supply = <_io>;
vqmmc-supply = <_sd>;
status = "okay";
};
{
bus-width = <4>;
cap-mmc-highspeed;
cap-sd-highspeed;
card-detect-delay = <200>;
disable-wp; /* wp not hooked up */
num-slots = <1>;
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _cd _bus4>;
supports-sd;
vmmc-supply = <_sd>;
vqmmc-supply = <_sd>;
status = "okay";
};
{
mali-supply = <_gpu>;
status = "okay";
};
{
assigned-clocks = < SCLK_MAC>;
assigned-clock-parents = <_gmac>;
clock_in_out = "input";
pinctrl-names = "default";
pinctrl-0 = <_pins>, <_rst>, <_pmeb>, <_int>;
phy-supply = <_lan>;
phy-mode = "rgmii";
snps,reset-active-low;
snps,reset-delays-us = <0 1 100>;
snps,reset-gpio = < 8 GPIO_ACTIVE_LOW>;
tx_delay = <0x30>;
rx_delay = <0x10>;
status = "okay";
};
{
ddc-i2c-bus = <>;
status = "okay";
};
{
status = "okay";
clock-frequency = <40>;
rk808: pmic@1b {
compatible = "rockchip,rk808";
reg = <0x1b>;
interrupt-parent = <>;
interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <_int _pwroff>;
rockchip,system-power-controller;
wakeup-source;
#clock-cells = <1>;
clock-output-names = "xin32k", "rk808-clkout2";
vcc1-supply = <_sys>;
vcc2-supply =
Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
Hi Heiko, > I'm currently testing Simon's network patches and this option works > quite nicely. Speaking of networking, I noticed that rk3288 networking is not quite merged yet. I would very much like to have networking so if you could point me to any rk3288 networking patches, I'd appreciate it. Thanks much. Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
Hi Heiko and Simon,
Again, thank you both for your help, I really appreciate it!
The good news is that I finally got it to boot fully into mainline
u-boot. I switched gears and tried miniarm-rk3288_defconfig which
doesn't use the CONFIG_SPL_OF_PLATDATA option. So now my build looks
like:
u-boot-denx:
cd $@; make miniarm-rk3288_defconfig CROSS_COMPILE="${CROSS_COMPILE}"
cd $@; make ${MK_PAR} all CROSS_COMPILE="${CROSS_COMPILE}"
$@/tools/mkimage -n rk3288 -T rksd -d $@/spl/u-boot-spl-dtb.bin
tftpboot/u-boot-dtb.bin; cat $@/u-boot-dtb.bin >> tftpboot/u-boot-dtb.bin
and my flash looks like:
UPGD=./Linux_Upgrade_Tool_v1.21/upgrade_tool
sudo ${UPGD} db rkbin/rk32/rk3288_boot.bin
sleep 1
sudo ${UPGD} wl 64 tftpboot/u-boot-dtb.bin
sudo ${UPGD} rd
So I'm pretty excited :)
The strange thing is I still don't have emmc or my LED turning on
from the device tree entry in rk3288-miniarm.dtsi (which I modified
for my LED [ on GPIO0_B3]):
pwr-led {
gpios = < 11 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "default-on";
};
Below is what I see when I boot.
Cheers,
Rick
U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 29 2016 - 14:19:08)
U-Boot 2016.11-00138-g136179b-dirty (Nov 29 2016 - 14:19:08 -0800)
Model: Miniarm-RK3288
DRAM: 2 GiB
MMC: dwmmc@ff0c: 0
Card did not respond to voltage select!
*** Warning - MMC init failed, using default environment
In:serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
=> md 0xFF75 4
ff75:
=> md 0xFF79 4
ff79:
=>
> Hi Rick,
>
> On 29 November 2016 at 11:22, Rick Bronson wrote:
> > Hi Heiko and Simon,
> >
> > Thank you both for your help, I really appreciate it.
> >
> > No, I do not have the Linux mainline running yet as I was focusing
> > on getting the mainline u-boot running since I saw some references
> > that implied I may need that to use the mainline Linux. I did try the
> > mainline kernel with the vendor-fork u-boot but got nothing pas the
> > "Loading Linux" line from u-boot.
> >
> > I think what I will probably do is take the easy way out and use the
> > vendor-fork u-boot since that boots on this hardware.
> >
> > But since I've invested some amount of time in the mainline u-boot
> > and it's drinving me mad that I can't seem to figure out what's wrong,
> > I do have one last question (hopefully).
>
> It would certainly make sense to invest in getting this running if you can.
>
> >
> > I've got mainline u-boot getting this far (I added debug to show
> > what GPIO0 and 2 are outputting).
> >
> >
> > U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 28 2016 - 13:29:59)
> > Trying to boot from MMC1
> > Card did not respond to voltage select! GPIO0=0x0 GPIO2=0x0
> > ...
> >
> >
> > I've modified rk3288-firefly.dts (the closest thing to hardware I
> > have) to set the eMMC reset line high but as you see above, nothing is
> > set on any GPIO. This leads me to believe that I do not understand
> > how the device tree is loaded/used in SPL. Can anyone point me to
> > help on whether I should use u-boot-spl-nodtb or u-boot-spl-dtb (I've
> > tried both) or how to debug if I am in fact even reading my dtb.
>
> You should be able to use 'gpio status' to see the GPIO state once you
> get to U-Boot.
>
> But if your board is booting SPL from MMC how can it possibly fail to
> load U-Boot from MMC? The MMC GPIO must already work for you to get
> this far. Or are you loading SPL from something other than MMC?
>
> You want u-boot-spl.bin (which includes the device tree).
>
> >
> > Thanks again,
> >
> > Rick
> >
> > PS. My Makefile is here if you are so inclined:
> > http://members.efn.org/~rick/pub/Makefile See the targets u-boot-denx
> > and uboot_new_flash to see what I've tried.
>
> You could push your tree somewhere or a patch showing what changes you
> have made.
>
> Regards,
> Simon
>
> >>
> >> From heiko at sntech.de Tue Nov 29 08:45:02 2016
> >> To: u-boot at lists.denx.de
> >> Cc: Simon Glass , Rick Bronson ,
> > "eddie.cai" ,
> > linux-rockchip at lists.infradead.org
> >> Subject: Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
> >> Date: Tue, 29 Nov 2016 11:20:52 +0100
> >>
> >> Hi R
Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
Hi Heiko and Simon,
Thank you both for your help, I really appreciate it.
No, I do not have the Linux mainline running yet as I was focusing
on getting the mainline u-boot running since I saw some references
that implied I may need that to use the mainline Linux. I did try the
mainline kernel with the vendor-fork u-boot but got nothing pas the
"Loading Linux" line from u-boot.
I think what I will probably do is take the easy way out and use the
vendor-fork u-boot since that boots on this hardware.
But since I've invested some amount of time in the mainline u-boot
and it's drinving me mad that I can't seem to figure out what's wrong,
I do have one last question (hopefully).
I've got mainline u-boot getting this far (I added debug to show
what GPIO0 and 2 are outputting).
U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 28 2016 - 13:29:59)
Trying to boot from MMC1
Card did not respond to voltage select! GPIO0=0x0 GPIO2=0x0
...
I've modified rk3288-firefly.dts (the closest thing to hardware I
have) to set the eMMC reset line high but as you see above, nothing is
set on any GPIO. This leads me to believe that I do not understand
how the device tree is loaded/used in SPL. Can anyone point me to
help on whether I should use u-boot-spl-nodtb or u-boot-spl-dtb (I've
tried both) or how to debug if I am in fact even reading my dtb.
Thanks again,
Rick
PS. My Makefile is here if you are so inclined:
http://members.efn.org/~rick/pub/Makefile See the targets u-boot-denx
and uboot_new_flash to see what I've tried.
>
> From he...@sntech.de Tue Nov 29 08:45:02 2016
> To: u-boot@lists.denx.de
> Cc: Simon Glass <s...@chromium.org>, Rick Bronson <r...@efn.org>,
"eddie.cai" <eddie@rock-chips.com>,
linux-rockc...@lists.infradead.org
> Subject: Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
> Date: Tue, 29 Nov 2016 11:20:52 +0100
>
> Hi Rick,
>
> Am Montag, 28. November 2016, 15:09:05 schrieb Simon Glass:
> > + A few rockchip people and linux-rockchip
> >
> > Hi Rick,
> >
> > On 25 November 2016 at 11:20, Rick Bronson <r...@efn.org> wrote:
> > > Hi All,
> > >
> > > I've got unsupported RK3288 hardware running the latest git u-boot to
> > >
> > > SPL as explained in
> > > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip. My goal
> > > is to run the mainline (ie. not Android) Linux kernel on this hardware
> > >
> > > and wondered:
> > > - Do I need to get the latest git u-boot to run before I can run the
> > >
> > > mainline kernel? Or can I use
> > > github.com/linux-rockchip/u-boot-rockchip.git, which I have running
> > > u-boot fully.
> >
> > It's up to you - obviously mainline is where the development should
> > be, but there is no requirement that I know of.
>
> correct, the (mainline-)kernel runs just fine on both the vendor-fork of
uboot
> as well as on mainline.
>
>
> > Does mainline run on your board?
> >
> > > - The device tree seems to be in two places, once via:
> > > resource_tool --image=resource2.img --pack linux/logo.bmp
> > > ${DTS}.dtb
> > >
> > > that gets put into the resource file and then again at the end of the
> > >
> > > kernel via CONFIG_ARM_APPENDED_DTB. Do I need both? When I do both
> > > I get things like:
> >
> > > Unknow param: MACHINE_MODEL:rk30sdk!
> > > Unknow param: MACHINE_ID:007!
>
> ARM_APPEND_DTB is meant for boards where the bootloader cannot load the
> devicetree (to old or so) and also cannot be reasonably exchanged. So the
> append-mechanism was invented to allow bundling the devicetree with the
actual
> kernel image, so that to the bootloader it looks like just any other kernel
> image.
>
> So you essentially only need one or the other. Also at least mainline uboot
> also supports the FIT image type, where you can bundle the devicetree in a
> more generalized way.
>
> For your message I would guess the kernel didn't find a usable devicetree
> somehow and was falling back to ATAGS-based board selection?
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Rockchip RK3288 u-boot with mainline kernel
Hi All,
I've got unsupported RK3288 hardware running the latest git u-boot to
SPL as explained in
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip. My goal
is to run the mainline (ie. not Android) Linux kernel on this hardware
and wondered:
- Do I need to get the latest git u-boot to run before I can run the
mainline kernel? Or can I use
github.com/linux-rockchip/u-boot-rockchip.git, which I have running
u-boot fully.
- The device tree seems to be in two places, once via:
resource_tool --image=resource2.img --pack linux/logo.bmp ${DTS}.dtb
that gets put into the resource file and then again at the end of the
kernel via CONFIG_ARM_APPENDED_DTB. Do I need both? When I do both
I get things like:
Unknow param: MACHINE_MODEL:rk30sdk!
Unknow param: MACHINE_ID:007!
Thanks much for any help.
Rick Bronson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
Hi All,
I've got nsupported RK3288 hardware running the latest git u-boot to SPL
as explained in
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip. My goal
is to run the mainline (ie. not Android) Linux kernel on this hardware
and wondered:
- Do I need to get the latest git u-boot to run before I can run the
mainline kernel? Or can I use
github.com/linux-rockchip/u-boot-rockchip.git, which I have running
u-boot fully.
- The device tree seems to be in two places, once via:
resource_tool --image=resource2.img --pack linux/logo.bmp ${DTS}.dtb
that gets put into the resource file and then again at the end of the
kernel via CONFIG_ARM_APPENDED_DTB. Do I need both? When I do both
I get things like:
Unknow param: MACHINE_MODEL:rk30sdk!
Unknow param: MACHINE_ID:007!
Thanks much.
Rick
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91rm9200dk broken/patches?
Hi Reinhard, Did you ever get the email below? I never heard back from anyone on this. Cheers, Rick From rick Tue Jan 18 22:32:15 -0800 2011 To: Reinhard Meyer u-b...@emk-elektronik.de CC: alb...@aribaud.net, reinhard.me...@emk-elektronik.de In-reply-to: 4d34a61f.1030...@emk-elektronik.de (message from Reinhard Meyer on Mon, 17 Jan 2011 21:27:11 +0100) Subject: Re: U-Boot support for board(s) AT91RM9200DK References: 20101127215901.95380220235C@lilith e1pn7fz-0002qa...@amazonia.comcast.net 4cf3e933.8070...@aribaud.net e1pn8no-0002gi...@amazonia.comcast.net 4d32ae6e.1070...@aribaud.net e1peqrc-0001iz...@amazonia.comcast.net 4d34627a.7080...@aribaud.net e1pesxv-0005eg...@amazonia.comcast.net 4d348052.4020...@aribaud.net 4d34a61f.1030...@emk-elektronik.de Hi All, Here is what I've done so far: git clone git://git.denx.de/u-boot-atmel.git cd u-boot-atmel git checkout -b rework101229 - used CodeSourcery/Sourcery_G++_Lite: /u-boot-atmel /opt/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 Hopefully this compiler is okay, please tell me if it's not. - looked at: commit 0693923cd240f5d401be0a53cddcf0fb1d9ad9d3 in the current u-boot - Make a bunch of changes but still have 2 warnings (see http://www.efn.org/~rick/pub/build.log): cpu.c:37: warning: #warning Your board is using legacy AT91RM9200 SoC access. Please update! at91_emac.c:487: warning: dereferencing type-punned pointer will break strict-aliasing rules What should I do about these? I made a patch file, please check it over. http://www.efn.org/~rick/pub/uboot.diff I'll try it on the board soon Thanks, Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91rm9200dk broken/patches?
Hi Reinhard, Okay, it may be awhile before I get to this... Kinda busy at the moment. Cheers, Rick Dear Rick Bronson, Am 03.08.2011 18:10, schrieb Rick Bronson: Hi Reinhard, Did you ever get the email below? I never heard back from anyone on this. Sorry, did not see this mail. From rick Tue Jan 18 22:32:15 -0800 2011 To: Reinhard Meyer u-b...@emk-elektronik.de CC: alb...@aribaud.net, reinhard.me...@emk-elektronik.de In-reply-to: 4d34a61f.1030...@emk-elektronik.de (message from Reinhard Meyer on Mon, 17 Jan 2011 21:27:11 +0100) Subject: Re: U-Boot support for board(s) AT91RM9200DK References: 20101127215901.95380220235C@lilith e1pn7fz-0002qa...@amazonia.comcast.net 4cf3e933.8070...@aribaud.net e1pn8no-0002gi...@amazonia.comcast.net 4d32ae6e.1070...@aribaud.net e1peqrc-0001iz...@amazonia.comcast.net 4d34627a.7080...@aribaud.net e1pesxv-0005eg...@amazonia.comcast.net 4d348052.4020...@aribaud.net 4d34a61f.1030...@emk-elektronik.de Hi All, Here is what I've done so far: git clone git://git.denx.de/u-boot-atmel.git cd u-boot-atmel git checkout -b rework101229 - used CodeSourcery/Sourcery_G++_Lite: /u-boot-atmel /opt/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 Hopefully this compiler is okay, please tell me if it's not. should work. Maybe you run into trouble cause of missing armv4 support in the toolchain. There are workarounds, just let u-boot build its own libgcc stuff - 'USE_PRIVATE_LIBGCC'. - looked at: commit 0693923cd240f5d401be0a53cddcf0fb1d9ad9d3 in the current u-boot - Make a bunch of changes but still have 2 warnings (see http://www.efn.org/~rick/pub/build.log): cpu.c:37: warning: #warning Your board is using legacy AT91RM9200 SoC access. Please update! Well, please update this board to use the new arm920t/at91 SoC code, see at91rm9200ek for example. at91_emac.c:487: warning: dereferencing type-punned pointer will break strict-aliasing rules fixed in 2321bfe425385494da8739d7d7e9dd3a5ca18a84 What should I do about these? I made a patch file, please check it over. http://www.efn.org/~rick/pub/uboot.diff At least these steps are missing: - configure to use arm920t/at91, not arm920t/at91rm9200 (- boards.cfg) - set correct USART in config - adopt includes in board file best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix hang when entering udelay after GPTIMER2 overflows (about 22 minutes on AM37x)
Hi Igor, Yes, I agree. John's patch is better. I'll try to test it this weekend. If you don't hear from me, ping me on Monday. Thanks, Rick Hi Rick, I've been browsing through the mailing list and found a similar patch [1] sent about a half a year ago by: John Rigby john.ri...@linaro.org It has neither been accepted, nor rejected. It looks like John's patch is a bit cleaner and has a more complete commit message. I can test it on DM3730/AM3703/OMAP3530 and some time later on AM3517. Can you please, also test it on your available hardware? Sandeep, can you please, take a look at this? [1] http://patchwork.ozlabs.org/patch/76803/ On 06/16/11 22:52, Rick Bronson wrote: Hi Igor, Yes, I have tested this on the AM3715 but not on any other parts. Cheers, Rick On 05/17/11 00:52, r...@efn.org wrote: Signed-off-by: Rick Bronson r...@efn.org --- arch/arm/cpu/armv7/omap-common/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/timer.c b/arch/arm/cpu/armv7/omap-common/timer.c index 9beebb1..3c9d488 100644 --- a/arch/arm/cpu/armv7/omap-common/timer.c +++ b/arch/arm/cpu/armv7/omap-common/timer.c @@ -44,7 +44,7 @@ static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE; */ #define TIMER_CLOCK (V_SCLK / (2 CONFIG_SYS_PTV)) -#define TIMER_LOAD_VAL 0x +#define TIMER_LOAD_VAL 0 /* counter starts from 0 on reload */ Has this been tested? If yes, then on what hardware (board)? Is it only AM SoCs or DM too? -- Regards, Igor. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix hang when entering udelay after GPTIMER2 overflows (about 22 minutes on AM37x)
Hi Igor, Yes, I have tested this on the AM3715 but not on any other parts. Cheers, Rick On 05/17/11 00:52, r...@efn.org wrote: Signed-off-by: Rick Bronson r...@efn.org --- arch/arm/cpu/armv7/omap-common/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/timer.c b/arch/arm/cpu/armv7/omap-common/timer.c index 9beebb1..3c9d488 100644 --- a/arch/arm/cpu/armv7/omap-common/timer.c +++ b/arch/arm/cpu/armv7/omap-common/timer.c @@ -44,7 +44,7 @@ static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE; */ #define TIMER_CLOCK(V_SCLK / (2 CONFIG_SYS_PTV)) -#define TIMER_LOAD_VAL 0x +#define TIMER_LOAD_VAL 0 /* counter starts from 0 on reload */ Has this been tested? If yes, then on what hardware (board)? Is it only AM SoCs or DM too? -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USBNET in OMAP (beagleboard)
Hi Alexander, But I need to be able to do it right inside u-boot. That is, I want to run USBNET within u-boot itself and not the kernel. Thanks, Rick Am 25.02.2011 00:06, schrieb Rick Bronson: I've searched the mailing list archives and couldn't come up with an answer so I thought I'd try here: Anyone know of any implementations of USBNET in u-boot for OMAP? This feature allows the OMAP, as a USB device (gadget), to do networking over a USB connection with a USB host. Just load a kernel to do that. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USBNET in OMAP (beagleboard)
Hi All, I've searched the mailing list archives and couldn't come up with an answer so I thought I'd try here: Anyone know of any implementations of USBNET in u-boot for OMAP? This feature allows the OMAP, as a USB device (gadget), to do networking over a USB connection with a USB host. Thanks much for any help. Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MX51 Eval board Rev 2.5, CPU Rev 3 Ethernet working, sort of
Hi, The good news is that MX51 Eval board Rev 2.5, CPU Rev 3 Ethernet is working. The bad news is that it's not based on the latest u-boot git. Hopefully that will change soon. Here's how to get it going: wget ftp://ftp.denx.de/pub/u-boot/u-boot-2009.08.tar.bz2 wget http://www.efn.org/~rick/pub/u-boot-v2009.08-imx_09.12.00.tar.bz2 tar jxf u-boot-2009.08.tar.bz2 # expand u-boot tar jxf u-boot-v2009.08-imx_09.12.00.tar.bz2 # expand patches mv patches u-boot-2009.08 # move patches to righ spot cd u-boot-2009.08 ./patches/patch-uboot.sh # install u-boot patches make mx51_bbg_config; make # CAUTION: the following command destroy's SD partition table: sudo dd if=u-boot.bin of=$(SD_CARD) seek=0 bs=512 # then format your SD card with a filesystem Cheers, Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx51 u-boot
Hi Stefano, With git clone git://git.denx.de/u-boot I get: /u-boot cat ~/tlc/dqp1130/u-boot.imx51.1.patch | patch -p1 --dry-run ERROR patching file Makefile Reversed (or previously applied) patch detected! Assume -R? [n] ^C /u-boot cat ~/tlc/dqp1130/u-boot.imx51.2.patch | patch -p1 --dry-run CLEAN /u-boot cat ~/tlc/dqp1130/u-boot.imx51.3.patch | patch -p1 --dry-run CLEAN /u-boot cat ~/tlc/dqp1130/u-boot.imx51.4.patch | patch -p1 --dry-run CLEAN /u-boot cat ~/tlc/dqp1130/u-boot.imx51.5.patch | patch -p1 --dry-run CLEAN /u-boot cat ~/tlc/dqp1130/u-boot.imx51.6.patch | patch -p1 --dry-run CLEAN /u-boot cat ~/tlc/dqp1130/u-boot.imx51.7.patch | patch -p1 --dry-run CLEAN /u-boot cat ~/tlc/dqp1130/u-boot.imx51.8.patch | patch -p1 --dry-run CLEAN /u-boot cat ~/tlc/dqp1130/u-boot.imx51.9.patch | patch -p1 --dry-run CLEAN /u-boot cat ~/tlc/dqp1130/u-boot.imx51.10.patch | patch -p1 --dry-run ERROR can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff --git a/cpu/arm_cortexa8/mx51/Makefile b/cpu/arm_cortexa8/mx51/Makefile |index 4d82293..7cfaa2c 100644 |--- a/cpu/arm_cortexa8/mx51/Makefile |+++ b/cpu/arm_cortexa8/mx51/Makefile -- /u-boot cat ~/tlc/dqp1130/u-boot.imx51.11.patch | patch -p1 --dry-run ERROR patching file MAINTAINERS Hunk #1 FAILED at 151. 1 out of 1 hunk FAILED -- saving rejects to file MAINTAINERS.rej ... Then with git clone git://git.denx.de/u-boot-imx I get: /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.1.patch | patch -p1 --dry-run ERROR /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.2.patch | patch -p1 --dry-run CLEAN /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.3.patch | patch -p1 --dry-run CLEAN /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.4.patch | patch -p1 --dry-run CLEAN /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.5.patch | patch -p1 --dry-run CLEAN /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.6.patch | patch -p1 --dry-run CLEAN /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.7.patch | patch -p1 --dry-run FUZZ /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.8.patch | patch -p1 --dry-run CLEAN /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.9.patch | patch -p1 --dry-run CLEAN /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.10.patch | patch -p1 --dry-run ERROR /u-boot-imx cat ~/tlc/dqp1130/u-boot.imx51.11.patch | patch -p1 --dry-run ERROR Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx51 u-boot
You cannot expect that patch works if you runs the previous ones with dry-run and the current patch modifies files already patched in the previous ones. Very true ;-) Number 10 still fails :( /u-boot cat ~/tlc/dqp1130/u-boot.imx51.10.patch | patch -p1 patching file cpu/arm_cortexa8/mx51/Makefile patching file cpu/arm_cortexa8/mx51/speed.c patching file drivers/mmc/fsl_esdhc.c patching file include/asm-arm/global_data.h patching file include/fsl_esdhc.h Hunk #1 FAILED at 32. 1 out of 2 hunks FAILED -- saving rejects to file include/fsl_esdhc.h.rej patching file lib_arm/board.c Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx51 u-boot
You must take a look at the reason. However, I see a recent commit for this file that changed SYSCTL_CLOCK_MASK, as I did, too. Because I changed (in the same way) this mask, the patch cannot directly applied. However, you can easy fix it adding the defines I needed. There are still comments about using IO accessors function, so I will rebase it before sending again). Got it fixed, thanks, Built it and ran it but the FEC seems unhealthy: MX51EVK U-Boot dhcp FEC_MXC: Autonegotiation timeout BOOTP broadcast 1 Maybe I can help you fix it? Any ideas? Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx51 u-boot
Hi Stefano, Not sure if this will help, but here is my startup with #define DEBUG in drivers/net/fec_mxc.c http://www.efn.org/~rick/pub/minicom.cap Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx51 u-boot
Hi Stefano, Please send your questions to u-boot ML. It is the right place where we can exchange experience on u-boot. Okay. If this is the u-boot you find in the ltib, the command could be correct. It depends how u-boot is built. The MX51 processor reads automatically the SD card starting from address 0x400. At this address, the processor must find the DCD table. In the patches I sent, I follow another approach: u-boot is build independently from the device where you will store the bootloader. You have to generate u-boot.imx (with make u-boot.imx), that adds the DCD table and then you must store it at the correct offset. On a SD card, this means with: dd if=u-boot.imx of=$(SD_CARD) bs=512 seek=2 Okay, thanks much for the info. Do you try the patches I sent to the ML ? And which is the version of your processor (TO1, TO2 or TO3) and of the board ? Not sure what patches these are or where to find them. Also not sure what source to apply these patches to. Is it the latest on denx.de or the ltib sources? Not sure what rev of the processor I have, my bootup log is here http://www.efn.org/~rick/pub/imx51.log although I don't see any T01, T02, etc printing. I gues it would be nice if there were some instructions for getting up to date on the latest u-boot for the iMX51 eval board. I'd be happy to help put together a set. Thanks very much for the help. Rick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
