On Wed, Jul 15, 2015 at 7:41 PM, Peter Griffin <peter.grif...@linaro.org> wrote: > Hi Rob, > > On Fri, 10 Jul 2015, Rob Herring wrote: > >> On Wed, Jul 8, 2015 at 10:57 AM, Peter Griffin <peter.grif...@linaro.org> >> wrote: >> > HiKey is the first 96boards consumer edition compliant board. It features >> > a hi6220 >> > SoC which has eight ARM A53 cpu's. >> >
[...] >> > +#define CONFIG_BAUDRATE 115200 >> > +#define CONFIG_SYS_SERIAL0 0xF8015000 >> >> Just do: >> >> #define CONFIG_PL01x_PORTS {(void *)0xf8015000} > > Ok, fixed in V3 > >> >> You are probably going to want to setup multiple serial consoles >> (debug + LS header). That can come later, but I've figured out how to >> enable that if you are interested. > > Yes I'm interested, please do let me know :) See this commit: https://git.linaro.org/people/rob.herring/u-boot.git/commitdiff/f1d0aef06ae7fe09793d46589bd94fa36c45bbc0 This may be 8250 specific and require more work for pl011 driver. The mixture of 0 and 1 based indexing makes it fun too. >> > +#define CONFIG_EXTRA_ENV_SETTINGS \ >> > + "kernel_name=Image\0" \ >> > + "kernel_addr=0x0000000\0" \ >> >> Shouldn't this be 0x80000 to avoid copying from 0x0 to 0x80000. > > I've updated this. Kernel boot time is much reduced with this and also the > icache being enabled. Also, this should be kernel_addr_r > >> >> > + "fdt_name=hi6220-hikey.dtb\0" \ >> > + "fdt_addr=0x0300000\0" \ and fdt_addr_r >> > + "max_fdt=0x100000\0" \ >> >> I don't think this is needed. > > Removed in V3 >> >> > + "fdt_high=0xffffffffffffffff\0" \ >> > + "initrd_high=0xffffffffffffffff\0" \ >> > + >> > +/* Assume we boot with root on the first partition of a USB stick */ >> > +#define CONFIG_BOOTARGS "console=ttyAMA0,115200n8 >> > /dev/mmcblk0p7 rw " >> >> /dev/mmcblk0p7 doesn't look right. You mean "root=/dev/..."? > > Good spot, yes your right. Plus now you highlight it the comment above also > needs updating. > > Will fix in V3. > >> >> > + >> > +/* Copy the kernel and FDT to DRAM memory and boot */ >> > +#define CONFIG_BOOTCOMMAND "booti $kernel_addr_r - $fdt_addr_r" >> >> Don't you need to set these variables? >> >> Also, don't you need to load the kernel and dtb first? > > Yes, but I'm not sure quite what to make the default here. My personal > workflow is: - > > "usb start; dhcp; tftp $kernel_addr $kernel_name; tftp $fdt_addr $fdt_name; > booti $kernel_addr - $fdt_addr" > > So I could use that unless you have a better idea? Not really as everyone has their own preferences. I have some thing like this: #define CONFIG_BOOTCOMMAND \ "while true; do " \ "mmc read ${fdt_addr_r} 0x10000 0x1000; " \ "fastboot; " \ "mmc read ${fdt_addr_r} 0x10000 0x1000; " \ "mmc read ${kernel_addr_r} 0x8000 0x8000 && " \ "bootm ${kernel_addr_r} ${kernel_addr_r} ${fdt_addr_r};" \ "done" This relies on fastboot doing USB cable detection and it exits if no USB connection. USB ethernet is as good a default as any. Otherwise reading Image and dtb from the 1st or bootable partition (the default) would be reasonable. >> > +/* Preserve enviroment onto sd card */ >> > +#define CONFIG_ENV_IS_IN_MMC >> > +#define CONFIG_SYS_MMC_ENV_DEV 1 >> > +#define CONFIG_SYS_MMC_ENV_PART 0 >> >> Don't you have these reversed? The first MMC device is 0 and I think >> partition numbering starts at 1. > > Having CONFIG_SYS_MMC_ENV_DEV 1 was deliberate, as the first device is eMMC, > and > I don't have a "official" partition to save the u-boot enviroment in. > So as not to corrupt anything folks may have flashed into eMMC from the > official > builds I opted to save the u-boot env to SD card which is device 1. Okay, but don't you have spare space in the partition with u-boot? I have a single bootloader partition 1MB in size and the last 8? KB is the env. > However that seems to have been working by luck with ENC_PART being 0, and it > was > actually corrupting the partition table of the SD card. Looking more closely > I think > what I should of used is > > #define CONFIG_ENV_IS_IN_FAT > #define FAT_ENV_INTERFACE "mmc" > #define FAT_ENV_DEVICE_AND_PART "1:1" > #define FAT_ENV_FILE "uboot.env" > > This then saves the enviroment on a fat formatted SD card with the filename > u-boot.env. This is what I plan on using for v3. > > Maybe I should additionally request some space in the official eMMC parition > table and then we could switch over to using that. > >> >> > +#define CONFIG_ENV_OFFSET 0x0 >> > +#define CONFIG_ENV_SIZE 0x1000 >> > +#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + >> > CONFIG_ENV_SIZE) >> > +#define CONFIG_SYS_REDUNDAND_ENVIRONMENT >> >> Is redundant env necessary? It seems like this was more for raw NAND >> and shouldn't really be needed for MMC. > > README file documents it as being valid for CONFIG_ENV_IS_IN_MMC, and a bunch > of boards > declare it with their CONFIG_ENV_IS_IN_MMC such as omap5_uevm.h, dra7xx_evm.h, > am335x_evm.h. Whilst using managed NAND should be more reliable, I think it > is still used in case there is a power failure whilst issuing 'saveenv'. Perhaps a bunch of cut and paste. I'd guess there are many more platforms that use MMC and don't enable redundant. > Anyways with moving to CONFIG_ENV_IS_IN_FAT I won't need it anymore so it > will be > removed in V3. Storing in FAT probably only increases your chance of failure from power failure. :) Rob _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot