Hi Ryan,
Thanks for the patch system and I will follow the
same methodology.
BR,
Steve
On 4 June 2013 10:50, Ryan Harkin <ryan.harkin(a)linaro.org> wrote:
> Hi Steve,
>
> Further to our phone call, I pushed out my patch system git repo:
>
> ssh://
> linaro-private.git.linaro.org/srv/linaro-private.git.linaro.org/uefi/patche…
>
> Hope it helps!
>
> Cheers,
> Ryan.
>
> On 3 June 2013 16:23, Steven Kinney <steven.kinney(a)linaro.org> wrote:
> > Hi Ryan,
> >
> > I am focusing on maintainer tasks today and tomorrow;
> > before I start on 64-bit SCT integration. I talked to Grant on my
> one-on-one
> > Friday and he suggested applying the patches within a local repository,
> > maybe within my git.linaro.org folder, and working with you regarding
> > merging and other GIT tasks. Of course, if you have ant suggestions to
> > start getting me up so that I can be more of use to you, please let me
> know.
> > Also, Grant wanted me to start giving suggestions regarding the coding,
> and
> > I see some areas that can be commented on, but I would like to make sure
> we
> > are in sync before I start yammering on commented out code blocks and
> such.
> >
> > Anyway, I look forward to learning about this area and
> > will ping you from time to time over the next few days to get some
> specific
> > advice. Thanks for you patience and help!
> >
> > BR,
> >
> > Steve
>
[cc'ing the boot architecture list; this conversation should be in public]
On Wed, May 29, 2013 at 11:19 AM, Leif Lindholm
<leif.lindholm(a)linaro.org> wrote:
> Hi Yi,
>
> On 28 May 2013 15:52, Li Yi <yi.li(a)linaro.org> wrote:
>> just modify linux loader , add SMBIOS address information into fdt. then
>> I will modify the dmidecode to parse the /dev/devicetree to find SMBIOS
>> table pointer. Maybe this way can skip grub and kernel's modification.
>
> Ok, yes, that should work.
>
>> the only problem I care about is the address wrote into fdt ,it is a
>> real physical address, does dmidecode (tool) can read this address ,and do
>> the right thing? it need to be proved.
>
> Yes - UEFI is guaranteed to run with a 1:1 mapping, so the address you see it
> at in the UEFI linux loader is the physical address.
>
>> Grant: if kernel will use the SMBIOS's region memory, can I reserve the
>> 64M memory from the top total ,then kernel will know it's reserved ,will not
>> use the region again ,right?
>
> That should be enough.
Yes, but you shouldn't even need to do that. I just looked at the
LinuxLoader code, in particular the UEFI FDT code, and I've noticed
that the reserved regions should already be set up. Look in
ArmPkg/Library/BdsLib/BdsLinuxFdt.c, about line 420. The function
PrepareFdt() retrieves the UEFI memory map and calls fdt_add_mem_rsv()
for each region.
It does use the function IsLinuxReservedRegion() to filter the
regions, so if SMBIOS uses a different region type then you'll need to
add that type to the list.
So, if I'm correct, it should be sufficient to merely enable SMBIOS
support in UEFI and the kernel will automatically mark the SMBIOS
region as reserved. You can verify this by adding "memblock=debug" to
the kernel command line and looking at the kernel boot output. You'll
see something like this:
memblock_reserve: [0x00000000008400-0x0000000042e98c]
arm_memblock_init+0x4c/0x150
memblock_reserve: [0x00000004000000-0x0000000452f400]
arm_memblock_init+0xcc/0x150
memblock_reserve: [0x00000000004000-0x00000000008000]
arm_memblock_init+0xf0/0x150
memblock_reserve: [0x00000004530000-0x00000004537350]
arm_dt_memblock_reserve+0x30/0xb0
MEMBLOCK configuration:
memory size = 0x8000000 reserved size = 0x960cdc
memory.cnt = 0x1
memory[0x0] [0x00000000000000-0x00000007ffffff], 0x8000000 bytes
reserved.cnt = 0x4
reserved[0x0] [0x00000000004000-0x00000000007fff], 0x4000 bytes
reserved[0x1] [0x00000000008400-0x0000000042e98b], 0x42658c bytes
reserved[0x2] [0x00000004000000-0x0000000452f3ff], 0x52f400 bytes
reserved[0x3] [0x00000004530000-0x0000000453734f], 0x7350 bytes
Memory policy: ECC disabled, Data cache writeback
memblock_reserve: [0x00000007fff000-0x00000008000000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffe000-0x00000007fff000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffdf10-0x00000007ffe000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffc000-0x00000007ffd000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffb000-0x00000007ffc000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffa000-0x00000007ffb000]
memblock_alloc_base_nid+0x68/0x84
Note: this only works with the UEFI LinuxLoader. The GRUB code doesn't
currently add the UEFI reserved regions to the FDT reserved map.
g.
Hi Roy,
Here are some very quick notes on what I found on writing UEFI applications.
I found a library called "gnuefi" which allows building EFI
applications apart from the Tianocore build tree. It looks
interesting, but has not been ported to ARM. I don't yet know if it is
worthwhile pursuing.
http://gnu-efi.sourceforge.net/
As mentioned, the Linux kernel has an EFI stub already. I could tell
you which files to look at, but really just doing a "git grep
EFI_STUB" in the kernel tree will show you all the files that you need
to care about. :-)
You'll need to figure out how to get a UEFI PE-COFF header into the
LInux kernel zImage wrapper. It shouldn't be too hard. You'll need to
look at the startup code in arch/arm/boot/compressed/head.S. The
PE-COFF header will need to go somewhere after the start: label. You
should be able to see the existing LInux kernel "header" (not much of
a header, more of a magic number) about 10 lines down from the start
label.
That's all I can write at the moment. We can talk more tomorrow.
g.
Terse information, more engineering notes than documentation, and
links to sources can be found at:
https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/RuntimeServices
Contains a few known bugs, and will need some fundamental
discussions/reengineering, but lets us start experimenting.
/
Leif
To boot linux kernel using TFTP in Arndale.
Following is the steps:
1. Apply the patches 13.03 branch. (on top of Olivers Ethernet
patches,If Olivier's patches doesn't apply, then do it manually)
2. Compile and boot as usual.
3. Wait till USB initialization and then do as shown below:
The default boot selection will start in 1 seconds
UsbEnumeratePort: Device Connect/Disconnect Normally
UsbEnumeratePort: Device Connect/Disconnect Normally
UsbEnumeratePort: Device Connect/Disconnect Normally
EhcExecTransfer: transfer failed with 8
EhcControlTransfer: error - Device Error, transfer - 8
0x9F6BDA90: Allocate pNicDevice, 792 bytes
0x9F4DCD10: Allocated timer
Installed: gEfiCallerIdGuid on 0x9F4DE390
Installed: gEfiSimpleNetworkProtocolGuid on 0x9F4DE390
MnpSyncSendPacket: No network cable detected.
MnpSyncSendPacket: No network cable detected.
MnpSyncSendPacket: No network cable detected.
MnpSyncSendPacket: No network cable detected.
ERROR: Did not find Linux kernel.
[1] SD-MMC Booting
-
PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/IPv4(192.168.1.1)/uImage
- Arguments: root=/dev/mmcblk1p2 rw rootwait
console=ttySAC2,115200n8 init --no-log
- LoaderType: Linux kernel with global FDT
-----------------------
Global FDT Config
-
VenHw(3A02E7FE-0649-4FB4-BE4F-A862CA1872A9)/HD(2,MBR,0x000039F9,0x2000,0x1A000)/exynos5250-arndale.dtb
-----------------------
[a] Boot Manager
[b] Shell
Start: a
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Update FDT path
[5] Return to main menu
Choice: 1
Installed Fat filesystem on 9E63E190
[1] boot (51 MB)
-
VenHw(3A02E7FE-0649-4FB4-BE4F-A862CA1872A9)/HD(2,MBR,0x000039F9,0x2000,0x1A000)
[2] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)
[3] PXE on MAC Address: 00:40:5C:26:0A:5B
- PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)
[4] TFTP on MAC Address: 00:40:5C:26:0A:5B
- PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)
Select the Boot Device: 4
Get the IP address from DHCP: [y/n] y
Get the TFTP server IP address: 192.168.1.1
File path of the EFI Application or the kernel : uImage
Is an EFI Application? [y/n] n
Boot Type: [a] ATAGS, [g] Global FDT or [l] Local FDT? [a/g/l] g
Add an initrd: [y/n] n
Arguments to pass to the binary: root=/dev/mmcblk1p2 rw rootwait
console=ttySAC2,115200n8 init --no-log
Description for this new Entry: tftp
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Update FDT path
[5] Return to main menu
Choice: 5
[1] SD-MMC Booting
-
PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/IPv4(192.168.1.1)/uImage
- Arguments: root=/dev/mmcblk1p2 rw rootwait
console=ttySAC2,115200n8 init --no-log
- LoaderType: Linux kernel with global FDT
[2] tftp
-
PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/IPv4(192.168.1.1)/uImage
- Arguments: root=/dev/mmcblk1p2 rw rootwait
console=ttySAC2,115200n8 init --no-log
- LoaderType: Linux kernel with global FDT
-----------------------
Global FDT Config
-
VenHw(3A02E7FE-0649-4FB4-BE4F-A862CA1872A9)/HD(2,MBR,0x000039F9,0x2000,0x1A000)/exynos5250-arndale.dtb
-----------------------
[a] Boot Manager
[b] Shell
Start: 2
Hello.
I'm trying to boot Ubuntu using PXE from U-Boot on the Samsung
XE303C12-A01US Chromebook. I would like to understand better the point 5 of
the tutorial here :
https://wiki.linaro.org/Boards/Arndale/Setup/PXEBoot
it says : "At the u-boot prompt, set the environmental variables "serverip"
and "ipaddr" as per the board and host PC configuration. Now set the
following environmental variables as mentioned..."
the problem is that the Samsung XE303C12-A01US does not have a serial port
and I can't stop the u-boot booting and set the enviromental variables
manually. I would like to know how can I embed them inside u-boot. Also
because there is not a configuration file like boot.cmd/boot.scr like there
is on the pandaboard that can be used to pass the parameters. Thanks.
--
Mario.
This is to let you know that the migration of lists.linaro.org has been
successfully completed.
As per the email I sent on Wednesday, it may take some time for the new
address of the server to be seen by your computer. You can check this by
trying to connect to the web site:
http://lists.linaro.org/
If you are able to connect and you do not get an error, this means you are
connecting to the new server and you can send email to the lists.
If you experience any problems after the weekend and you find that you
still cannot connect to the server, please reply to this email to let us
know.
Regards
Philip
IT Services Manager
Linaro
Hi,
First of all I'm not sure if this is the right list to post this, but
I thought boot-architecture might be the best list to post.
Currently we have one hwpack for PandaBoard4430 and PandaBoardES 4460
which means that when we install the hwpack on PandaBoardES the kernel
thinks it is running on PandaBoard 4430.
However there is a HW difference between the two boards:
Audio routing is different (for capture path).
Also the hdmi pin muxing need to be different (according to the DTS files).
I can see two ways of dealing with the different versions:
1. create separate hwpacks for the revisions where only the included
DTB file is different:
PandaBoard 4430: omap4-panda.dtb
PandaBoardES: omap4-panda-es.dtb
2. Or to have single hwpack for Panda:
With the included patch in u-boot
Include both omap4-panda.dtb and omap4-panda-es.dtb files to the boot partition.
Modify the boot.txt to load different dtb based on the board:
if is_pandaES; then
setenv bootcmd "fatload mmc 0:1 0x80200000 uImage; fatload mmc 0:1
0x81600000 uInitrd; fatload mmc 0:1 0x815f0000 omap4-panda-es.dtb;
bootm 0x80200000 0x81600000 0x815f0000";
else
setenv bootcmd "fatload mmc 0:1 0x80200000 uImage; fatload mmc 0:1
0x81600000 uInitrd; fatload mmc 0:1 0x815f0000 omap4-panda.dtb; bootm
0x80200000 0x81600000 0x815f0000";
fi;
For audio we need to tell the difference between the two revision and
this is done via different DTB blob.
Thank you,
Péter