Am Dienstag, 29. November 2016, 14:40:49 schrieb Simon Glass: > 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? 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 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?
