Hi Albert, On Tue, Feb 2, 2016 at 5:53 PM, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Hello Bin and Simon, > > On Tue, 2 Feb 2016 15:25:48 +0800, Bin Meng <bmeng...@gmail.com> wrote: >> Hi Simon, >> >> On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <s...@chromium.org> wrote: >> > +Bin (sorry, meant to copy you before) > >> >>> For non-FSP devices we don't init the RAM until much later - >> >>> dram_init(). That means that a significant portion of the init >> >>> sequence would be 32-bit code. I'm not sure that will work. >> >>> >> >> I believe we can do dram_init() in 64-bit mode as well if MRC is >> written in pure C. > > Bin: not sure what you mean by "if MRC is written in pure C" -- there > is no C construct that can even approach the mrc instruction, which can > only be emitted through an asm statement.
You are exposed as an ARM guy :-) I was talking about an Intel term Memory Reference Code which are a amount of magic codes to initialize system RAM. > >> > I wonder whether we might need to resort to SPL for the 32-bit >> > portion, and jump to a 64-bit U-Boot from there? Tegra does something >> > similar to that. > > Simon: seems like a sensible approach, as it does not mix 32 and 64 > bits in one "build artefact", plus it seems logical in that SPL's > role is to get the platform ready for U-Boot; switching from > power-on32-bit mode to 64-bit mode belongs quite "naturally" in SPL. > >> What's the benefit of doing a 64-bit bootloader? Intel's UEFI BIOS has >> a 32-bit and 64-bit version, and has caused some troubles for the next >> stage loader (bootia32.efi vs. bootx64.efi). I know for PowerPC, a >> 64-bit U-Boot does not exist as 32-bit U-Boot can load 32-bit and >> 64-bit kernel, just like what we have for x86. 64-bit U-Boot was only >> seen on ARMv8, but that's the architecture limitation I believe, and >> we have to do that. > > Some U-Boot users who might want to get rid of x86 32-bit code in > x86 64-bit platforms just like in the past some people must have wanted > to get rid of real-mode 16-bit x86 code in order to run pure 32-bit; the Yep, but unfortunately we still cannot get rid of real-mode 16-bit x86 code even today :( > idea is that if you can do with as well as without a feature, then that > feature is potential dead code, and is candidate for removal, all the > more when that feature partly collides with another feature, as here > where 32-bit and 64-bit support sort of overlap partially. > I wonder if some day these processors (arm, x86, whatever else?) will come out of reset in the 64-bit mode directly. No more any legacy modes. At that time, 64-bit mode bootloader is definitely a must. > Now, we can wait until x86 32-bit is really dead (as in "not used > except in a few legacy projects whose engineers' children are about to > retire") and then scrape dead code parts which no one really understands > any more, or we can try and anticipate and replace code while we still > have a grasp of what it does. I personally like the idea of anticipating > better. > > Just in case, note that I do not mean x86 32-bit support should be > removed from U-Boot now or later. I mean that if we can make x86 64-bit > support in U-Boot less and less dependent on x86 32-bit support, then I > think we should, so that the day we completely drop x86 32-bit support, > x86 64-bit support will be (as) unaffected (as possible). > I agree with the philosophy here. But I sense this might be too anticipating as there are some other tasks to do for U-Boot 32-bit like ACPI and SMM. 32-bit is enough for now, unless we want to access >4GB memory in U-Boot shell? Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot