* Re: Rockchip RK3288 u-boot with mainline kernel
[not found] <476576ec2671ff75030249e453491add.squirrel@webmail.efn.org>
@ 2016-11-28 22:09 ` Simon Glass
0 siblings, 0 replies; 5+ messages in thread
From: Simon Glass @ 2016-11-28 22:09 UTC (permalink / raw)
To: Rick Bronson; +Cc: U-Boot Mailing List, eddie.cai, linux-rockchip
+ A few rockchip people and linux-rockchip
Hi Rick,
On 25 November 2016 at 11:20, Rick Bronson <rick@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.
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!
I don't know much about that. Hopefully someone on the linux-rockchip
list knows. But for mainline U-Boot I'm not sure why you would need
this?
> ....
>
> Thanks much for any help.
>
> Rick Bronson
>
>
Regards,
Simon
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Rockchip RK3288 u-boot with mainline kernel
@ 2016-11-29 18:22 Rick Bronson
2016-11-29 21:40 ` Simon Glass
0 siblings, 1 reply; 5+ messages in thread
From: Rick Bronson @ 2016-11-29 18:22 UTC (permalink / raw)
To: u-boot; +Cc: linux-rockchip, eddie.cai
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 heiko@sntech.de Tue Nov 29 08:45:02 2016
> To: u-boot@lists.denx.de
> Cc: Simon Glass <sjg@chromium.org>, Rick Bronson <rick@efn.org>,
"eddie.cai" <eddie.cai@rock-chips.com>,
linux-rockchip@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 <rick@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?
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Rockchip RK3288 u-boot with mainline kernel
2016-11-29 18:22 Rockchip RK3288 u-boot with mainline kernel Rick Bronson
@ 2016-11-29 21:40 ` Simon Glass
2016-11-29 22:11 ` Heiko Stübner
0 siblings, 1 reply; 5+ messages in thread
From: Simon Glass @ 2016-11-29 21:40 UTC (permalink / raw)
To: Rick Bronson; +Cc: U-Boot Mailing List, eddie.cai, linux-rockchip
Hi Rick,
On 29 November 2016 at 11:22, Rick Bronson <rick@efn.org> 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@sntech.de Tue Nov 29 08:45:02 2016
>> To: u-boot@lists.denx.de
>> Cc: Simon Glass <sjg@chromium.org>, Rick Bronson <rick@efn.org>,
> "eddie.cai" <eddie.cai@rock-chips.com>,
> linux-rockchip@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 <rick@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?
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Rockchip RK3288 u-boot with mainline kernel
2016-11-29 21:40 ` Simon Glass
@ 2016-11-29 22:11 ` Heiko Stübner
0 siblings, 0 replies; 5+ messages in thread
From: Heiko Stübner @ 2016-11-29 22:11 UTC (permalink / raw)
To: Simon Glass; +Cc: U-Boot Mailing List, eddie.cai, Rick Bronson, linux-rockchip
Am Dienstag, 29. November 2016, 14:40:49 schrieb Simon Glass:
> Hi Rick,
>
> On 29 November 2016 at 11:22, Rick Bronson <rick@efn.org> 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?
Or you can try enabling the
CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y
option, which will simply let the on-chip rom also load the 2nd stage uboot
seemingly using the same method as for the spl.
I'm currently testing Simon's network patches and this option works quite
nicely.
Heiko
> 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@sntech.de Tue Nov 29 08:45:02 2016
> >> To: u-boot@lists.denx.de
> >> Cc: Simon Glass <sjg@chromium.org>, Rick Bronson <rick@efn.org>,
> >
> > "eddie.cai" <eddie.cai@rock-chips.com>,
> > linux-rockchip@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 <rick@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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Rockchip RK3288 u-boot with mainline kernel
@ 2016-11-29 22:50 Rick Bronson
0 siblings, 0 replies; 5+ messages in thread
From: Rick Bronson @ 2016-11-29 22:50 UTC (permalink / raw)
To: u-boot; +Cc: linux-rockchip, eddie.cai
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 = <&gpio0 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@ff0c0000: 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 0xFF750000 4
ff750000: 00000000 00000000 00000000 00000000 ................
=> md 0xFF790000 4
ff790000: 00000000 00000000 00000000 00000000 ................
=>
> Hi Rick,
>
> On 29 November 2016 at 11:22, Rick Bronson <rick at efn.org> 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 <sjg at chromium.org>, Rick Bronson <rick at efn.org>,
> > "eddie.cai" <eddie.cai at rock-chips.com>,
> > 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 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 <rick at 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?
> >>
> >>
> >
> >
> >
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-11-29 22:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-29 18:22 Rockchip RK3288 u-boot with mainline kernel Rick Bronson
2016-11-29 21:40 ` Simon Glass
2016-11-29 22:11 ` Heiko Stübner
-- strict thread matches above, loose matches on Subject: below --
2016-11-29 22:50 Rick Bronson
[not found] <476576ec2671ff75030249e453491add.squirrel@webmail.efn.org>
2016-11-28 22:09 ` Simon Glass
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox